키보드 접근성을 염두에 두고 앱을 설계하는 5단계

"보통" 사용자에 대해 생각할 때 우리는 그들이 컴퓨터를 사용할 때 마우스나 트랙패드를 사용한다고 상상하는 경향이 있습니다. 그러나 그들이 선호하거나 유일한 옵션이 키보드를 사용하는 것이라면 어떨까요? 키보드 접근성을 염두에 두고 앱을 설계해 보셨습니까?

누군가가 컴퓨터를 사용하기 위해 마우스나 트랙패드를 작동하기를 원하지 않거나 작동할 수 없는 데는 여러 가지 이유가 있습니다. 그들은 손재주 또는 근육 제어를 제한하는 영구적, 만성 또는 일시적인 상태를 가질 수 있으며, 이로 인해 손목이나 손이 민감해지거나 화면에서 마우스 커서를 따라가기가 어렵습니다. 또한 작업 흐름을 간소화하기 위해 더 많은 지름길을 찾는 "고급 사용자"일 수도 있습니다. 어떤 경우든 키보드는 개인이 기술과 상호 작용하는 데 선호하거나 필요한 수단일 수 있습니다.

이 문서에서는 키보드 액세스 가능성 지침과 앱이 키보드 액세스 가능하도록 앱을 디자인할 때 유의해야 할 5단계에 대해 알아봅니다.

키보드 접근성은 어떻게 작동합니까?

앱에 키보드 액세스가 가능한 경우 사용자가 키보드만 사용하여 제어 요소 를 작동할 수 있는 옵션이 있음을 의미합니다. 컨트롤 요소는 버튼, 링크, 양식 입력, 비디오 및 기타 대화형 콘텐츠와 같은 페이지의 모든 대화형 구성 요소입니다.

키보드 탐색 기본 사항

다음은 키보드 탐색에 사용되는 몇 가지 기본 키입니다.

• 다음 컨트롤 요소로 이동: Tab(또는 관련 라디오 버튼 및 선택 옵션에 대한 오른쪽 또는 아래쪽 화살표 키)
• 이전 컨트롤 요소로 이동: Shift + Tab(또는 관련 라디오 버튼 및 선택 옵션의 경우 왼쪽 또는 위쪽 화살표 키)
• 제어 요소 클릭: Enter 및/또는 스페이스바
• 관련 라디오 버튼 간 이동 또는 옵션 선택: 화살표 키

초점 순서

컨트롤 요소가 키보드 이벤트에 응답할 수 있는 순서를 포커스 순서 라고 합니다. 요소에 포커스가 있으면 특정 키보드 컨트롤을 사용하여 요소와 상호 작용할 수 있습니다. 요소가 초점을 잃으면 흐려집니다. 브라우저는 사용자가 현재 포커스가 있는 요소를 추적할 수 있도록 기본 포커스 상태를 렌더링합니다.

또한 다음을 좋아할 수도 있습니다: 유니버설 디자인: 사이트와 앱의 접근성을 높이는 11가지 실용적인 팁.

키보드 접근성 및 WCAG(웹 콘텐츠 접근성 지침)

WCAG(웹 콘텐츠 접근성 지침)는 전 세계 지역 또는 국가 웹 접근성 법률의 표준으로 채택된 세 가지 규정 준수 수준(레벨 A, 레벨 AA 및 레벨 AAA)을 설명합니다.

키보드 접근성은 레벨 A 규정 준수의 성공 기준 중 하나입니다. 레벨 A 기준은 모든 웹 콘텐츠의 필수 기능을 설명합니다. 또한 구현하기 가장 쉬운 것으로 간주됩니다.

“주의하지 않으면 키보드 접근성도 잘못되기 쉽습니다.”

즉, 주의하지 않으면 키보드 접근성도 잘못되기 쉽습니다. 다음은 웹에서 발견되는 일반적인 키보드 접근성 문제의 예입니다.

• 감지할 수 없는 초점 상태
• 잘못된 초점 순서
• 포커스를 받을 수 없는 상호작용 요소
• 키보드 상호 작용을 선택하지 않는 복잡한 구성 요소

다행스럽게도 키보드 사용자를 염두에 두고 자체 앱에서 이러한 실수를 방지하는 데 사용할 수 있는 기술이 많이 있습니다.

키보드 접근 가능 앱 구축을 위한 5단계

1. 직관적인 상호 작용 디자인

사용자 지정 동작 없이 간단한 컨트롤 요소를 렌더링할 때 일반적으로 내장된 키보드 접근성 기능을 활용할 수 있습니다. 그러나 버튼, 링크 또는 입력과 관련된 표준 키보드 동작을 모르면 실수로 키보드 사용자에게 혼란스러운 경험을 만들 수 있습니다.

"버튼, 링크 또는 입력과 관련된 표준 키보드 동작을 모르면 실수로 키보드 사용자에게 혼란스러운 경험을 만들 수 있습니다."

예를 들어 개발자는 때때로 CSS를 사용하여 더 스타일화된 시각적 개체를 위해 기본 HTML 라디오 버튼을 숨깁니다. 입력이 배후의 라디오 버튼인지는 분명하지 않으므로 키보드 사용자는 관련 옵션 간에 초점을 이동하기 위해 Tab 키가 아닌 화살표 키를 사용해야 한다는 사실을 모를 수 있습니다.

이 문제를 방지하려면 키보드를 사용하여 상호 작용하기를 원하거나 필요로 하는 모든 사람에게 시각적 신호를 제공하기 위해 최소한 기본 HTML 요소와 유사한 것을 표시해야 합니다.

2. 키보드가 마우스가 할 수 있는 모든 것을 할 수 있도록 앱을 빌드합니다.

내장된 키보드 접근성 기능과 함께 제공되지 않는 요소에 유의하십시오. 레이아웃 요소, 목록, 표, 머리글, 단락 및 의미 없는 HTML 태그는 기본적으로 키보드 단축키를 지원하지 않습니다. 그러나 탭, 끌어서 놓기 목록 또는 모달과 같은 보다 복잡한 구성 요소를 빌드하는 데 자주 사용됩니다.

JavaScript를 사용하면 컨트롤이 아닌 요소가 마우스 클릭이나 제스처에 응답하도록 하는 이벤트 리스너를 추가할 수 있습니다. 예를 들어 React에서는 onClick 소품을 사용하여 목록 항목 요소에 상호작용성을 추가할 수 있습니다.

비제어 요소에 상호작용을 추가할 때마다 tabIndex 속성을 0 으로 설정해야 합니다. 이렇게 하면 Tab 키를 누를 때 요소가 올바른 포커스 순서로 포커스를 받을 수 있습니다. 또한 Enter 키 및/또는 스페이스바를 통해 "클릭"을 등록하기 위해 keypress 또는 keydown 이벤트 핸들러를 구현해야 합니다(버튼은 Enter 키만 지원하는 반면 링크는 둘 다 사용하여 클릭할 수 있음).

대신 앵커 태그 또는 버튼 요소와 같은 컨트롤을 사용하여 이러한 추가 작업을 피할 수 있습니다. 항상 CSS를 사용하여 기본 링크 및 버튼 스타일을 재정의하고 대화형 요소가 비대화형 부모의 전체 너비에 걸쳐 있도록 하여 대상 영역을 최대화할 수 있습니다.

기본이 아닌 기능에 제어 요소를 사용하는지 여부에 관계없이 구성 요소를 100으로 만들기 위해 화살표 키(탭 구성 요소의 탭 간 탐색) 또는 Esc 키(오버레이 닫기)에 대한 이벤트 리스너를 추가해야 할 수 있습니다. 퍼센트 키보드 액세스 가능.

보다 복잡한 구성 요소에 대해 비표준 키보드 동작을 구현하는 경우 사용자가 구성 요소와 상호 작용하는 데 사용할 수 있는 키보드 컨트롤을 설명하는 시각적 지침을 제공하는 것이 좋습니다.

3. 기본 포커스 순서를 재정의할 때 추가 작업 수행

포커스 순서는 키보드 접근성과 밀접한 관련이 있는 또 다른 WCAG 요구 사항입니다. 레벨 A 기준을 충족하려면 포커스 순서가 페이지에 있는 대화형 요소의 시각적 순서와 일치해야 합니다. 키보드 사용자는 화면의 컨트롤 요소를 위에서 아래로 그리고 텍스트 콘텐츠와 동일한 가로 방향(왼쪽에서 오른쪽 또는 오른쪽에서 왼쪽)으로 탐색할 수 있어야 합니다.

이 기준을 충족하는 가장 쉬운 방법은 마크업 에서 요소가 배열되는 순서에 따라 결정되는 기본 포커스 순서를 그대로 두는 것입니다. 컨트롤 요소의 시각적 순서와 소스 코드에 배치된 방식 사이에 불일치가 발생하면 이 기준을 충족하지 못할 위험이 있습니다.

Liquid 및 Shopify 를 사용하여 접근 가능한 이동 경로 탐색 구축.

위의 스크린샷을 예로 사용하는 경우 "업데이트 태그" 카드가 더 좁은 표시 영역을 위해 쌓일 때 "업데이트 설명" 카드와 위치를 전환하기를 원한다고 가정해 보겠습니다. 카드가 플렉스 항목으로 렌더링되는 경우 order CSS 속성을 사용하여 특정 중단점에서 순서를 변경하는 것을 고려할 수 있습니다.

order 속성은 플렉스 항목의 시각적 순서에 영향을 주지만 소스 코드에서 배열을 업데이트하지는 않습니다. 결과적으로 사용자가 각 버튼 사이를 이동하기 위해 Tab 키를 누르면 "태그 업데이트" 버튼이 화면에 역순으로 표시되더라도 "설명 업데이트"보다 먼저 포커스를 받습니다. 이로 인해 포커스가 예기치 않게 페이지 위아래로 이동하여 사용자에게 혼란스러운 경험을 제공합니다.

이 문제를 피하는 한 가지 방법은 마크업에서 두 ​​가지 버전의 카드를 렌더링하는 것입니다. 하나는 더 넓은 뷰포트 너비에 대해 예상되는 순서대로, 다른 하나는 더 좁은 뷰포트 너비에 대해 원하는 순서대로 렌더링됩니다. display 속성을 사용하여 특정 중단점에서 전환할 수 있습니다.

마크업에서 두 ​​가지 버전을 유지하지 않으려면 JavaScript를 사용하여 카드가 페이지에 쌓일 때 카드의 tabIndex 속성을 업데이트해야 합니다. 우리가 렌더링하는 제어 요소의 수에 따라 이 접근 방식은 마크업에서 다른 버전의 카드를 유지하는 것보다 제대로 하기가 더 어려울 수 있습니다.

4. 포커스 상태를 사용자 정의할 때 가장 필요한 사용자를 위한 디자인

브라우저는 outline CSS 속성을 사용하여 요소에 포커스가 있음을 시각적으로 표시합니다. 포커스 상태는 사용자가 키보드로 페이지를 탐색할 때 키보드 이벤트를 등록할 요소를 식별하는 데 도움을 주기 위한 것입니다.

디자이너와 개발자가 브라우저에서 렌더링하는 기본 포커스 상태를 바꾸는 것은 매우 일반적입니다. 여기에는 기본 outline 을 업데이트하거나 완전히 제거하고 background , border , box-shadow , color 또는 transform 과 같은 다른 CSS 속성으로 대체하는 것이 포함될 수 있습니다.

당신은 또한 좋아할지도 모릅니다 : Liquid로 접근 가능한 페이지 매김 만들기.

그러나 우리는 앱에서 사용자 지정 포커스 상태를 렌더링하기로 결정했으며 다음 접근성 요구 사항을 충족하는지 확인해야 합니다.

• 충분한 색상 대비: 시각 장애가 있는 사용자가 현재 초점이 맞춰진 요소를 쉽게 추적할 수 있도록 초점 상태와 주변 색상 사이에 충분한 대비가 있어야 합니다.
• 색상 변경은 다른 시각적 표시기와 짝을 이룹니다 . 요소의 테두리, 글꼴 또는 배경 색상 변경은 색맹인 사용자에게 눈에 띄지 않을 수 있습니다. 사용자가 색상을 구분할 수 있도록 요구하지 않는 다른 시각적 변경 사항과 함께 사용해야 합니다. 이는 색상 변경과 관련된 가리키기 및 오류 상태에도 적용됩니다.
• 고대비 테마에서 표시: background 및 box-shadow 를 포함한 일부 CSS 속성은 Windows 장치에서 고대비 모드가 활성화된 경우 무시됩니다. 색상의 변화도 등록되지 않을 수 있으므로 배경색과 전경색 사이에 더 많은 대비가 필요한 사람들이 인지할 수 있는 추가 표시기에 의존하는 것이 두 배로 중요합니다.

기본 outline 속성을 재정의하는 것은 허용되지만 교체를 제공하지 않고 기본 포커스 상태를 제거하지 마십시오.

5. 키보드 사용자를 위한 단축키 제공

누군가 마우스를 사용하여 웹 페이지를 탐색하는 경우 페이지가 로드될 때 관련 없는 헤더 콘텐츠를 스크롤하여 찾고 있는 정보에 도달할 수 있습니다. 이 프로세스는 여러 탐색 링크 또는 페이지의 기본 콘텐츠 앞에 오는 다른 제어 요소를 통해 탭해야 할 수 있는 키보드 사용자에게는 능률적이지 않습니다.

개발자로서 우리는 앱의 각 페이지 상단에 "건너뛰기 링크"를 제공하여 키보드 사용자가 페이지의 주요 콘텐츠 앞에 있는 제어 요소를 우회할 수 있습니다. 건너뛰기 링크는 일반적으로 포커스를 받을 때까지 보기에서 숨겨집니다. 앱과 상호작용하기 위해 마우스를 사용하는 사람들에게는 보이지 않지만 키보드를 사용하는 사람들에게는 포커스를 받는 첫 번째 요소가 될 것입니다.

링크를 클릭하면 포커스가 기본 콘텐츠 컨테이너로 이동하고 키보드 사용자는 즉시 페이지의 주요 제어 요소를 통해 탭 이동을 시작할 수 있습니다.

건너뛰기 링크는 편리한 바로가기 그 이상입니다. 레벨 A WCAG 표준을 충족하는 데 필요한 바이패스 블록의 예입니다.

직접 키보드 사용자가 되어 앱을 자주 테스트하십시오.

키보드 접근성 테스트는 보조 기술이나 장치 사용에 익숙하지 않은 사람들의 학습 곡선이 상대적으로 낮습니다. 필요한 것은 키보드에 대한 액세스, 표준 키보드 동작에 대한 친숙함, Windows 고대비 모드에 대한 액세스(Windows 장치 획득 또는 가상 머신 설치)뿐입니다.

다음은 키보드 접근성을 위해 앱을 테스트할 때 염두에 두어야 할 몇 가지 질문입니다.

• 키보드를 사용하여 마우스 클릭 및 제스처에 반응하는 모든 것과 상호 작용할 수 있습니까?
• 이 요소가 포커스를 받을 때 누군가가 이 요소와 상호 작용하는 방법을 알고 있습니까?
• 포커스 순서가 페이지에 있는 대화형 요소의 시각적 순서와 일치합니까?
• 더 높은 색상 대비가 필요한 경우에도 현재 어떤 요소에 초점이 맞춰져 있는지 추적할 수 있습니까?
• 페이지의 주요 콘텐츠로 쉽게 이동할 수 있습니까?

이러한 모든 질문에 "예"라고 대답하는 것은 많은 노력이 필요하지 않으며 모든 상황에서 사용자에게 긍정적인 영향을 미칠 수 있습니다. 신체적 장애가 있거나, 시간을 절약할 방법을 찾고 있거나, 한 손으로 컴퓨터.

접근성 테스트는 앱 개발의 중요한 구성 요소입니다. 특히 키보드 접근성은 스크린 리더를 사용하는 사람들에게 대체 텍스트를 제공하거나 오디오 콘텐츠를 들을 수 없는 사람들에게 캡션을 제공하는 것만큼이나 중요합니다. 결국 앱에 완전히 액세스하려면 앱을 사용하는 데 마우스 사용 기능이 필요하지 않아야 합니다.