팀의 업무 프로세스에 접근성을 통합하는 방법
사이트의 접근성을 높이는 것은 쉬운 일이 아닙니다. 접근성에 처음 접근하는 경우 이 주제의 범위가 너무 넓어서 어디서부터 시작해야 할지 막막할 수 있습니다. 결국 다양한 능력을 수용하기 위해 노력한다는 것은 그에 따라 고려해야 할 문제도 다양하다는 것을 의미합니다.
접근성은 팀의 노력이 필요합니다. 모든 사람에게는 각자의 역할이 있습니다. 이 문서에서는 접근성 권장사항을 프로세스에 통합할 수 있도록 각 주요 분야 (프로젝트 관리자, UX 디자이너, 개발자)의 기준을 설명합니다.
프로젝트 관리자
모든 프로젝트 관리자의 우선 목표는 모든 마일스톤에 접근성 작업을 포함하려고 노력하여 성능 및 사용자 환경과 같은 다른 주제만큼 우선순위가 높은지 확인하는 것입니다. 다음은 프로세스를 진행할 때 유의해야 할 몇 가지 체크리스트 항목입니다.
- 팀에 접근성 교육을 제공합니다.
- 사이트 또는 애플리케이션의 중요한 사용자 여정을 파악합니다.
- 접근성 체크리스트를 팀 프로세스에 통합해 보세요.
- 가능한 경우 사용자 연구를 통해 사이트 또는 애플리케이션을 평가합니다.
접근성 교육
웹 접근성에 대해 알아볼 수 있는 훌륭한 무료 리소스가 많이 있습니다. 팀이 주제를 연구하는 시간을 따로 할애하면 프로세스 초기에 접근성을 더 쉽게 포함할 수 있습니다.
Google에서 제공하는 리소스는 다음과 같습니다.
Google의 웹 접근성 - 몇 주 동안 진행되는 대화형 교육 과정입니다.
접근성 기초 - 접근성 가이드 및 권장사항 작성.
머티리얼 가이드라인: 접근성 - 포용적인 디자인을 위한 UX 권장사항 모음입니다.
중요한 사용자 여정 식별
모든 애플리케이션에는 사용자가 수행해야 하는 몇 가지 기본 작업이 있습니다. 예를 들어 전자상거래 앱을 개발하는 경우 모든 사용자가 장바구니에 항목을 추가할 수 있어야 합니다.
일부 작업은 보조적으로 중요할 수 있으며 가끔만 수행될 수 있습니다. 예를 들어 아바타 사진 변경은 좋은 기능이지만 모든 환경에서 중요한 것은 아닙니다.
애플리케이션의 기본 작업과 보조 작업을 식별하면 향후 접근성 작업의 우선순위를 지정하는 데 도움이 됩니다. 나중에 이러한 작업을 접근성 체크리스트와 결합하여 진행 상황을 추적하고 회귀를 방지할 수 있습니다.
접근성 체크리스트 통합
접근성의 주제는 상당히 광범위하므로 고려해야 할 중요한 영역의 체크리스트를 마련해 두면 기본 영역을 모두 포괄하는 데 도움이 됩니다.
접근성 체크리스트에는 여러 가지가 있으며 업계의 몇 가지 예를 들면 다음과 같습니다.
WebAIM WCAG 체크리스트 Vox 접근성 가이드라인
체크리스트를 사용하면 기본 작업과 보조 작업을 살펴보고 완료해야 하는 작업을 분류할 수 있습니다. 이 프로세스에 대해 상당한 전술을 얻을 수 있으며 기본 및 보조 작업의 행렬을 만들고 이러한 프로세스의 각 단계에서 누락된 접근성 비트가 있는지 확인할 수도 있습니다.
사용자 연구로 평가
실제 사용자가 앱을 사용하려 할 때 이러한 사용자를 관찰하는 것만큼 좋은 일도 없습니다. 접근성을 기존 환경에 맞게 재구성하는 경우 이 프로세스를 통해 개선이 필요한 영역을 빠르게 파악할 수 있습니다. 또한 새 프로젝트를 시작하는 경우 초기 사용자 연구를 통해 사용하기 어려운 기능을 개발하는 데 너무 많은 시간을 소비하지 않도록 할 수 있습니다.
가능한 한 다양한 사용자 집단의 의견을 통합하는 것을 목표로 합니다. 주로 키보드를 사용하여 탐색하거나 스크린 리더 또는 화면 돋보기와 같은 보조 기술을 사용하는 사용자를 고려합니다.
UX 디자이너
사람들은 자신의 편향을 사용하여 디자인하는 경향이 있으므로 장애가 없고 장애가 있는 동료가 없다면 의도치 않게 일부 사용자만을 대상으로 설계할 수 있습니다. 작업하면서 '이 설계를 사용할 수 있는 모든 사용자 유형은 무엇인가?'라고 자문해 보세요. 다음은 프로세스의 포괄성을 높이기 위해 시도할 수 있는 몇 가지 방법입니다.
- 콘텐츠의 색상 대비가 충분합니다.
- 탭 순서가 정의됩니다.
- 컨트롤에 액세스 가능한 라벨이 있습니다.
- UI와 상호작용하는 방법은 여러 가지가 있습니다.
콘텐츠의 색상 대비가 좋음
대부분의 사이트의 기본 목표는 텍스트나 이미지를 통해 사용자에게 정보를 전달하는 것입니다. 하지만 이 콘텐츠의 대비가 낮으면 일부 사용자 (특히 시각 장애가 있는 사용자)가 읽기 어려울 수 있습니다. 이는 사용자 환경에 부정적인 영향을 미칠 수 있습니다. 이 문제를 해결하려면 모든 텍스트와 이미지가 충분한 색상 대비를 갖도록 해야 합니다.
대비는 전경 색상과 배경 색상의 휘도를 비교하여 측정됩니다. 작은 텍스트 (18pt 또는 14pt 굵게 미만)의 경우 최소 비율은 4.5:1이 좋습니다. 더 큰 텍스트의 경우 이 비율을 3:1로 조정할 수 있습니다.
아래 이미지에서 왼쪽 텍스트는 이러한 대비 최솟값을 충족하지만 오른쪽 텍스트는 낮은 대비입니다.
Google의 머티리얼 색상 도구, Lea Verou의 대비율 앱, Deque의 aXe 등 색상 대비를 측정하는 다양한 도구가 있습니다.
탭 순서가 정의됨
탭 순서는 사용자가 탭 키를 누를 때 요소가 포커스를 받는 순서입니다. 주로 키보드로 탐색하는 사용자의 경우 Tab 키는 화면의 모든 항목에 접근할 수 있는 주요 수단입니다. 마우스 커서라고 생각하면 됩니다.
탭 순서는 읽기 순서를 따르고 페이지 상단에서 하단으로 흐르는 것이 좋으며 중요한 항목은 높은 순서로 표시되어야 합니다. 이렇게 하면 키보드를 사용하는 모든 사용자가 더 효율적으로 이러한 항목에 빠르게 액세스할 수 있습니다.
위의 모의 인터페이스에는 탭 순서를 표시하도록 번호가 매겨져 있습니다. 이와 같은 모의 실험을 만들면 의도한 탭 순서를 식별하는 데 도움이 될 수 있습니다. 그런 다음 개발자 및 QA 테스터와 공유하여 제대로 구현되고 테스트되었는지 확인할 수 있습니다.
컨트롤에 액세스 가능한 라벨이 있습니다.
스크린 리더와 같은 보조 기술 사용자에게 라벨은 시각적만 제공할 수 있는 정보를 제공합니다. 예를 들어 돋보기 아이콘일 뿐인 검색 버튼에는 누락된 시각적 어포던스를 채우는 데 도움이 되는 액세스 가능한 '검색' 라벨이 있을 수 있습니다.
다음은 액세스 가능한 라벨을 설계할 때 따라야 할 몇 가지 간단한 제안사항입니다.
- 간결하게 작성하세요. 긴 설명을 듣는 것은 지루할 수 있습니다.
- 컨트롤 유형이나 상태를 포함하지 마세요. 컨트롤이 올바르게 코딩되면 스크린 리더가 자동으로 이를 알려줍니다.
- 행동 동사에 집중: '돋보기'가 아닌 '검색'을 사용하세요.
모든 컨트롤에 라벨이 지정된 모의 광고를 만드는 것이 좋습니다. 이 정보는 구현과 테스트를 위해 개발팀 및 QA팀과 공유할 수 있습니다.
UI와 상호작용하고 UI를 이해하는 다양한 방법
모든 사용자가 주로 마우스를 사용하여 페이지와 상호작용한다고 가정하기 쉽습니다. 설계할 때는 다른 사람이 키보드를 사용하여 컨트롤과 어떻게 상호작용하는지 고려하세요.
집중 상태 계획 즉, 사용자가 Tab 키로 포커스를 맞추거나 화살표 키를 누를 때 컨트롤의 모양을 결정합니다. 이러한 상태를 나중에 설계에 넣기보다는 미리 계획하는 것이 좋습니다.
마지막으로 상호작용 지점에서 사용자가 여러 가지 방법으로 콘텐츠를 이해할 수 있는지 확인해야 합니다. 색각 이상이 있는 사용자는 이러한 미묘한 신호를 놓칠 수 있으므로 색상만 사용하여 정보를 전달하지 마세요. 대표적인 예는 잘못된 텍스트 필드입니다. 문제를 나타내는 빨간색 밑줄 대신 도움말 텍스트를 추가해 보세요. 이렇게 하면 더 많은 기반을 다루고 사용자가 문제를 알아차릴 가능성을 높일 수 있습니다.
개발자
개발자의 역할은 포커스 관리와 의미 체계가 결합되어 강력한 사용자 환경을 형성하는 것입니다. 다음은 개발자가 사이트 또는 애플리케이션을 작업할 때 염두에 두어야 할 몇 가지 사항입니다.
- 탭 순서는 논리적입니다.
- 초점이 적절하게 관리되고 표시됩니다.
- 대화형 요소에는 키보드가 지원됩니다.
- ARIA 역할 및 속성은 필요에 따라 적용됩니다.
- 요소에 라벨이 제대로 지정됩니다.
- 테스트는 자동화되어 있습니다.
논리 탭 순서
input, button, select와 같은 네이티브 요소는 무료로 탭 순서를 선택할 수 있으며 키보드로 자동으로 포커스를 설정할 수 있습니다. 하지만 모든 요소에 동일한 동작이 발생하는 것은 아닙니다. 특히 div 및 span와 같은 일반 요소는 탭 순서에 선택되지 않습니다. 즉, div를 사용하여 대화형 컨트롤을 만드는 경우 키보드에 액세스할 수 있도록 추가 작업을 실행해야 합니다.
두 가지 옵션은 다음과 같습니다.
- 컨트롤에
tabindex="0"를 부여합니다. 이렇게 하면 최소한 포커스 가능하게 만들 수 있지만 키 누름 지원을 추가하기 위해 추가 작업을 해야 할 수 있습니다. - 가능하면 버튼과 같은 컨트롤에
div또는span대신button를 사용하는 것이 좋습니다. 네이티브button요소는 스타일을 지정하기 매우 쉽고 키보드 지원을 무료로 받습니다.
포커스 관리
페이지의 콘텐츠를 변경할 때 포커스를 이동하여 사용자의 관심을 유도하는 것이 중요합니다. 이 기법이 유용한 일반적인 예로는 모달 대화상자를 열 때가 있습니다. 키보드를 사용하는 사용자가 버튼을 눌러 대화상자를 열었지만 포커스가 대화상자 요소로 이동하지 않는 경우 사용자는 최종적으로 새 컨트롤을 찾을 때까지 전체 사이트를 탭하며 이동하는 것입니다. 새로운 콘텐츠가 표시되는 즉시 초점을 맞추면 사용자 환경의 효율성을 높일 수 있습니다.
대화형 요소를 위한 키보드 지원
캐러셀이나 드롭다운과 같은 맞춤 컨트롤을 빌드하는 경우 키보드 지원을 추가하기 위해 몇 가지 추가 작업을 실행해야 합니다. ARIA 작성 연습 가이드는 다양한 UI 패턴과 이러한 패턴이 지원할 것으로 예상되는 키보드 작업의 종류를 식별하는 유용한 리소스입니다.
요소에 키보드 지원을 추가하는 방법에 관한 자세한 내용은 Google 접근성 기초 문서의 tabindex 이동 섹션을 참고하세요.
ARIA 역할 및 속성이 필요에 따라 적용됨
맞춤 컨트롤에는 적절한 키보드 지원이 필요할 뿐만 아니라 적절한 시맨틱도 필요합니다. 결과적으로 div는 의미론적으로 일반 그룹화 컨테이너일 뿐입니다. div를 드롭다운 메뉴의 기반으로 사용하는 경우 컨트롤 유형을 보조 기술에 전달할 수 있도록 ARIA를 사용하여 추가 의미 체계를 레이어링해야 합니다. 여기서도 ARIA 작성 방법 가이드가 사용해야 하는 역할, 상태, 속성을 식별하는 데 도움이 될 수 있습니다.
추가 보너스로 ARIA 가이드의 많은 설명이 샘플 코드와 함께 제공됩니다.
요소 라벨 지정
네이티브 입력에 라벨을 지정하는 경우 MDN에 설명된 대로 내장된 <label> 요소를 사용할 수 있습니다. 이렇게 하면 화면에 시각적 어포던스를 만들 수 있을 뿐만 아니라 접근성 트리에서 입력에 액세스 가능한 이름을 제공할 수도 있습니다. 그러면 이 이름이 보조 기술 (예: 스크린 리더)에서 인식되어 사용자에게 표시됩니다.
안타깝게도 <label>는 맞춤 요소 또는 간단한 div 및 스팬에서 만든 컨트롤과 같이 맞춤 컨트롤에 액세스 가능한 이름을 지정하는 것을 지원하지 않습니다. 이러한 종류의 컨트롤에는 aria-label 및 aria-labelledby 속성을 사용해야 합니다.
자동 테스트
테스트를 할 때는 게으른 편이 바람직할 수 있습니다. 가능하면 모든 작업을 수동으로 할 필요가 없도록 접근성 테스트를 자동화하는 것이 좋습니다. 일반적인 접근성 문제를 쉽고 빠르게 확인할 수 있는 훌륭한 업계 테스트 도구가 현재 다양하게 마련되어 있습니다.
Deque 시스템에서 만든 aXe는 Chrome 확장 프로그램 및 노드 모듈 (지속적 통합 환경에 적합)으로 사용할 수 있습니다. 이 짧은 A11ycast에서는 aXe를 개발 프로세스에 통합하는 몇 가지 방법을 설명합니다.
Lighthouse는 프로그레시브 웹 앱의 성능을 감사하는 Google의 오픈소스 프로젝트입니다. Lighthouse는 PWA에서 서비스 워커 및 웹 앱 매니페스트와 같은 기능을 지원하는지 확인할 뿐만 아니라 접근성 문제 테스트를 포함한 일련의 권장사항 테스트도 실행합니다.
결론
접근성은 팀 전체의 노력입니다. 모두가 각자의 역할이 있습니다. 이 가이드에서는 각 팀원이 주제를 빠르게 파악하고 전반적인 앱 환경을 개선하는 데 사용할 수 있는 몇 가지 주요 항목을 제시했습니다.
접근성에 대해 자세히 알아보려면 무료 Udacity 과정을 확인하고 web.dev에서 사용할 수 있는 접근성 문서를 살펴보세요.