2.5 입력 양식
키보드가 아닌 다양한 입력을 통해 기능을 보다 쉽게 조작 할 수 있도록 만들어야 합니다.
2.5.1 포인터 제스처 (A)
멀티 포인트 또는 패스 기반 제스처(gesture)를 사용하는 모든 기능은 멀티 포인트 또는 패스 기반 제스처가 필수적인 경우가 아니면 패스 기반 제스처 없이 싱글 포인터로 작동 할 수 있어야 합니다.
이 가이드라인은 포인터 작업을 해석하는 웹 콘텐츠에 적용됩니다. (즉, 사용자 에이전트(예: 브라우저) 또는 보조 기술을 작동하는데 필요한 작업에는 적용되지 않습니다)
해설
이 지침은 필수적인 경우를 제외하고는 단 한 번의 터치 만으로 모든 기능을 사용할 수 있어야 함을 명시합니다. 두 손가락이나 복잡한 움직임이 필요한 제스처는 손 떨림이나 움직임이 제한적인 사람들은 조작하기 어렵습니다.
한 번의 터치 만으로 조작할 수 있으면 마우스 스틱, 입으로 들이키거나 부는 동작 또는 헤드 마우스와 같은 대체 입력 장치를 사용하는 사용자에게 도움이 됩니다. 인지 기능 장애가 있는 사람 또한 기억하고 사용하기 쉬운 간단한 제스처는 도움이 됩니다. 웹 사이트나 애플리케이션은 멀티 터치 제스처를 사용하는 경우, 이를 대체하는 간단한 인터페이스 또한 제공해야 합니다.
치아에 박힌 작은 자석을 추적하는 치과 센서장치를 통해 수신한 신호를 명령어로 만들어 휠체어에 전달하는 입 천장의 혀 작동 시스템(Tongue Drive System)을 이용하는 사용자 또한 멀티 포인트와 같은 복잡한 제스처는 사용을 어렵게 만듭니다. ("혀로 컴퓨터와 휠체어를 움직인다" 기사 참고)
운영체제(OS)의 기본 제스처, 보조 기술의 제스처는 이 성공기준이 적용되지 않습니다.
예시
아래 예는 날씨 정보를 확인하기 위해 손가락으로 밀어대는 동작을 대체하는 버튼을 제공하는 것을 보여줍니다.
아래 예는 I SEOUL U 생활지도 검색 서비스로 대부분의 기능(확대, 축소 모드 변경 등)을 싱글 포인트로 제어할 수 있지만, 지도를 이동 시키는 기능을 제공되지 않습니다. 일반적으로 포인트를 사용해 밀거나 끄는 동작으로 지도를 이동 시키지만, 이를 대체하는 수단을 제공하고 있지 않습니다.
반면 미국의 TopoView 지도 뷰어 애플리케이션 예는 터치 & 드래그로 지도 위치를 이동하는 기능을 대체하는 화살표 버튼을 제공합니다. 복잡한 제스처를 사용할 수 없는 사용자는 이를 통해 지도를 탐색할 수 있습니다.
Google Map 서비스의 경우 화살표 버튼을 제공하고 있지는 않지만, 키보드의 화살표 키를 사용하여 화면을 이동할 수 있습니다. 시각적으로 이동하는 방향을 하단 텍스트로 정보를 제공합니다.
성공기준 이해하기 2.5.1을 보면 보다 상세한 디자인 가이드를 볼 수 있습니다.
2.5.2 포인터 취소 (A)
싱글 포인터를 사용하여 작동할 수 있는 기능의 경우 다음 중 하나 이상이 충족 되어야 합니다.
down이벤트 사용 X (No Down-Event) 포인터의down이벤트는 함수 일부를 실행하는데 사용하지 않습니다.중단(Abort) 또는 실행 취소(Undo) 함수의 완료는
up이벤트에 있고 완료 전에 함수를 중단하거나, 완료 후 함수를 실행 취소하는 방법을 제공합니다.up이벤트를 통한 취소(Reversal)up이벤트는 이전down이벤트의 결과를 뒤집을 수 있습니다.필수(Essential)적인 상황은 예외
down이벤트에서 필수적으로 작동해야 하는 경우는 예외입니다.
키보드 또는 숫자 키패드 키를 에뮬레이션 하는 기능은 필수적인 것으로 간주됩니다.
이 가이드라인은 포인터 작업을 해석하는 웹 콘텐츠에 적용됩니다. (즉, 사용자 에이전트 또는 보조 기술을 작동하는데 필요한 작업에는 적용되지 않습니다)
해설
이 지침은 실수로 잘못된 위치를 만지거나 클릭 할 수 있는 손 떨림, 운동 장애가 있는 사람들을 돕습니다. 실수로 인해 의도하지 않은 동작이 발생했을 때 취소할 수 있는 기능을 제공합니다. 인지 장애가 있는 사람들에게도 도움이 됩니다. 우연히 컨트롤을 활성화 했기 때문에 예기치 않은 일이 발생하면 혼란스러워질 수 있기 때문입니다. 뿐만 아니라 일반 사용자 또한 실행 취소 기능을 추가하면 도움이 됩니다.
down 이벤트에 함수를 연결하지 않습니다.
down 이벤트는 마우스 버튼을 누르거나, 터치 또는 키를 누른 순간 즉시 기능을 활성화 합니다. 그렇기 때문에 잘못된 위치를 클릭 하거나, 터치할 경우 실수로 인한 실행을 취소할 수 없습니다. down 이벤트에서 즉시 실행되도록 연결하지 않으면 실수를 범할 확률을 줄일 수 있습니다.
중단 또는 실행 취소할 수 있어야 합니다.
up 이벤트는 누른 마우스에서 손가락을 떼거나, 손가락 또는 포인터를 올리거나 키를 놓는 것을 말합니다. up 이벤트에서 작업이 실행하도록 만들면, 손가락 또는 포인터가 올바른 위치에 있는지 사전에 확인할 수 있습니다. 실행될 기능을 취소하기 위해 사용자는 목표 밖으로 이동하여 손가락 또는 포인터를 놓을 수 있습니다. 이처럼 개발자는 실행될 작업을 취소할 수 있는 기능을 제공해야 합니다.
up 이벤트를 통해 취소할 수 있습니다.
사용자가 잘못된 위치를 터치 했을 때, 손가락이나 포인터를 들어 올리기 전에 손가락이나 포인터를 그 위치에서 벗어나게 하여 의도하지 않은 작업을 취소할 수 있습니다.
필수 불가결한 경우, down 이벤트를 사용할 수 있습니다.
피아노나 드럼 연주를 시뮬레이션 하는 애플리케이션은 down 이벤트를 통해 즉시 실행되어야 합니다. 피아노 건반의 소리가 키를 누른 순간이 아닌, 손가락을 땔 때 난다면 이상 하겠죠? 두더지 게임에서 망치로 두더지를 때린 순간이 아닌, 망치를 땐 순간 두더지를 때린 것으로 스코어가 올라간다면 매우 어색할 겁니다.
예시
기부금(donation)을 전달하는 신청 방법은 다양하게 제공할 수 있습니다.
기부 금액이 표시된 버튼을 클릭해 기부합니다. 클릭한 상태에서 버튼 밖으로 이동하면 기부를 취소합니다.
Drag & Drop을 사용해 동전을 클릭한 후, 기부 상자로 끌어 놓아 기부합니다. 기부 상자 밖에서 포인터를 놓으면 기부를 취소합니다.
Drag & Drop 예에서는 사용자가 동전을 기부 상자에 놓았을 경우, 기부를 수락할 것인지 확인해야 합니다. 물론 성공기준 2.1.1에 따라 키보드 만으로도 기부가 가능해야 합니다.
아래 예는 기부할 금액 박스를 돼지 저금통으로 Drag & Drop 하여 기부하거나, 취소하는 동작을 보여줍니다.
첫 번째 동작은 $25 박스를 돼지 저금통 영역 위로 끌어 가다 잘못된 위치에서 놓을 경우 기부 동작을 취소합니다.
두 번째 동작은 $50 박스를 첫 번째 동작과 마찬가지로 취소 했다가, 다시 시도하여 올바른 위치에 놓으면 오른쪽 하단에 컨펌 메시지 링크(Confirm $50 Donation...)가 표시됩니다. 메시지 링크를 클릭하면 기부에 성공 했음을 알려주는 다이얼로그가 화면에 표시(Donation successful) 됩니다.
마지막 동작은 실수로 확인 버튼을 누른 경우, 버튼을 누른 상태로 포인터를 움직여 버튼 클릭을 취소합니다.
성공기준 이해하기 2.5.2을 보면 보다 상세한 디자인 가이드를 볼 수 있습니다.
2.5.3 레이블과 접근 가능한 이름 (A)
텍스트 또는 이미지 텍스트를 포함하는 레이블이 있는 UI 컴포넌트의 경우, 이름에 시각적으로 표시되는 텍스트가 포함되어야 합니다.
가장 좋은 방법은 레이블 텍스트를 이름의 시작 부분에 두는 것입니다.
해설
이 성공기준은 음성 명령을 사용하는 사용자에게 접근성을 향상시켜줍니다. 사용자는 음성 입력 소프트웨어가 활성화 할 컴포넌트를 식별할 수 있도록 컴포넌트에 접근 가능한 이름을 말해야 합니다. 접근 가능한 이름이 레이블 이름과 일치하지 않거나, 레이블 이름으로 시작하지 않을 경우 사용자는 혼란에 빠질 수 있습니다.
먼저 이 성공기준을 이해하려면 레이블과 이름의 차이점을 알아야 합니다.
레이블(label)
레이블은 컨트롤을 식별하기 위한 이름으로 일반적으로 화면에 표시되는 텍스트를 말합니다. 레이블의 예로 폼 컨트롤 또는 링크 텍스트를 들 수 있습니다. 아래 예에서 보이는 것처럼 폼 컨트롤은 레이블을 가집니다.
접근 가능한 이름(name)
이름은 보조 기술이 사용자가 컨트롤을 식별하는데 사용되는 이름입니다. 즉, 프로그래밍 방식으로 결정될 수 있으며 접근 가능 이름이라고도 합니다.
접근 가능한 이름은 다음의 경우를 말합니다.
보조 기술(예: 스크린리더) 사용자에게 들리는 텍스트
음성 인식 소프트웨어 사용자가 말하는 음성 명령 실행
접근 가능한 이름은 HTML 입력 요소의 name 속성과 관련이 없습니다.
컨트롤은 접근 가능한 이름과 레이블이 모두 있을 수 있고, 이름은 레이블과 동일할 수 있습니다. 보조 기술 사용자가 아니면 접근 가능한 이름을 알지 못할 수도 있습니다. 접근 가능한 이름은 alt, aria-label, aria-labelledby 속성 등을 사용해 설정합니다. 아래 이미지는 "무당벌레 처럼 큰 검은 점 무늬가 있는 빨간 커피 잔" 텍스트를 alt 값으로 설정할 수 있습니다. 대체 텍스트는 스크린 리더가 말할 수있는 접근 가능한 이름입니다.
예시
간단한 예로 제품을 선택하는 버튼 레이블은 "선택" 입니다. 음성 입력 사용자는 화면을 보고 "선택" 이라고 말하지만, 음성 소프트웨어는 해당 레이블을 접근성 있는 이름으로 인식하지 못합니다. 음성 소프트웨어가 식별 가능한 접근성 있는 이름은 "iPhone Xs 선택" 입니다. 하지만 사용자는 이러한 접근 가능한 이름을 볼 수 없어 알지 못합니다.
이 문제를 해결하려면 화면에 표시되는 레이블과 접근 가능한 이름을 동일하게 만들어야 합니다. 이를 수행할 수 없는 경우라면 접근 가능한 이름이 화면에 버튼과 함께 표시되어 사용자로 하여금 접근 가능한 이름을 올바르게 유추할 수 있게 해주어야 합니다. 아래 예에서는 사용자가 버튼의 레이블을 읽고, 올바른 음성 명령을 실행시킬 수 있습니다.
성공기준 이해하기 2.5.3을 보면 보다 상세한 디자인 가이드를 볼 수 있습니다.
2.5.4 동작(모션) 실행 (A)
기기 동작이나, 사용자 동작으로 작동 할 수 있는 기능은 UI 컴포넌트에 의해 작동 할 수 있으며 다음과 같은 경우를 제외하고 우발적인 동작을 방지하기 위해 동작에 대한 응답을 비활성화 할 수 있습니다.
접근성 지원 인터페이스 모션(동작)은 접근성 지원 인터페이스를 통해 기능을 조작하는데 사용됩니다.
필수 상황 모션 기능이 필수적인 경우는 예외로 합니다.
해설
제한된 이동성을 가진 사람들은 장치를 정확하게 이동하거나 제스처를 수행하지 못할 수 있습니다. 일부 사용자는 장치를 고정된 위치에 고정시킨채 이동할 수 없습니다. 손 떨림이 있는 사람들은 실수로 장치를 움직여 의도치 않은 동작이 작동될 수 있습니다. 그리고 자동차나 버스에 타는 것과 같이 불안정한 환경에 있는 사람들은 움직임이나 몸짓을 사용하지 못할 수 있습니다.
접근성 지원 인터페이스
접근성 지원 인터페이스는 동작에 의존하는 보조 기술을 말합니다. 카메라를 사용해 시선의 움직임을 감지하여 커서를 움직이는 시선 추적 소프트웨어가 대표적인 예입니다.
필수 상황 (예외)
동작(모션)은 악기를 시뮬레이션 하는 수 많은 게임이나 애플리케이션에 필수적으로 사용됩니다. 마라카스로 연주하기 위해서 스마트폰을 흔드는 것은 장치의 동작(모션)을 필요로 합니다.
이 성공기준은 특정 동작을 실행하기 위해 요구되는 의도적인 움직임(장치 이동, 센서를 사용해 사용자 동작 감지)에 대한 것을 말합니다. 하지만 지구 표면 전체의 움직임을 결정하는 지리적 위치 또는 기타 센서는 여기에 해당하지 않습니다.
동작을 실행하기 위해 요구되는 모션의 예는 다음과 같습니다.
모든 경우에 사용자는 동작을 완료하기 위해 동작 사용을 해제 할 수 있어야 합니다. 그리고 개발자는 장치 이동이 필요없는 작업을 수행하는 또 다른 방법을 제공해야 합니다.
예시
일반적인 예는 장치를 흔들어 목록에서 항목을 삭제하거나, 취소하는 것입니다. 애플리케이션은 흔들기를 통한 삭제, 취소 기능을 끌 수 있거나, 실행된 작동을 되돌려 복구할 수 있는 방법(예: 복구 버튼)을 제공해야 합니다. 또는 삭제된 항목을 찾아 복원하는 방법을 제공 할 수도 있습니다.
카메라를 통해 시선 추적을 사용하는 책 읽기 애플리케이션이 또 다른 예입니다. 애플리케이션은 사용자가 페이지를 읽기 완료하면 다음 페이지로 자동 넘깁니다. 애플리케이션은 사용자가 이전 페이지로 넘기는 대체 수단과 시선 추척 기능을 해제할 수 있는 방법을 제공해야 합니다.
정리하면 필수적으로 동작(모션)이 작동을 위해 필요한 경우가 아니라면 동작에 의존하지 않는 것이 좋습니다만, 동작을 통한 기능 수행이 필요한 경우 대체 인터페이스를 제공하고, 해당 기능을 끌 수 있도록 해야 합니다.
동작(모션) 실행 기능에 대한 대체 인터페이스를 제공해야 합니다.
사용자가 동작(모션) 실행 기능을 끌 수 있도록 해야 합니다.
성공기준 이해하기 2.5.4을 보면 보다 상세한 디자인 가이드를 볼 수 있습니다.
2.5.5 실행 영역 (AAA)
포인터 또는 터치에 의한 실행 영역은 다음 경우를 제외하고는 44×44 CSS 픽셀 이상이어야 합니다.
동등한 기능 존재 동일한 페이지에서 실행 영역이
44×44CSS 픽셀 이상인 동일한 링크 또는 컨트롤이 존재하는 경우인라인 실행 영역이 문장 또는 문장 블록인 경우
사용자 에이전트 컨트롤 실행 영역이 개발자가 작성한 마크업이 아닌, 사용자 에이전트(예: 브라우저)에 의해 결정되는 경우
필수 실행 영역을 시각적으로 표시하는 것이 정보 전달 필수적일 때
해설
컨트롤을 정확히 터치 하기 힘든 사람들에게 도움이 되는 지침입니다. 터치가 어려운 사람들은 마우스 스틱과 같은 대체 포인터를 사용하는 사람들, 또는 손가락이 마우스 포인터 만큼 정확하지 않은 사람들을 말합니다.
이 성공기준은 모바일 장치와 사용자가 인터랙션 할 때 발생하는 문제를 해결합니다. 요구되는 목표는 버튼과 같은 컨트롤을 사용자가 보고 터치 할 수 있을 정도로 크게 만드는 것입니다. 요구사항을 준수하면 손 떨림이나 운동 장애가 있는 사람들이 컨트롤 하는데 도움이 됩니다.
44×44 CSS 픽셀 크기는 일반적으로 모바일 장치의 9mm 크기에 해당합니다. 이 크기는 대부분의 사람들이 손가락이나 다른 포인팅 장치를 사용하여 보고 터치할 수 있을 만큼 충분히 큽니다. 이 크기는 Apple iOS 및 Android 사용자 인터페이스 가이드라인과 유사합니다.
44×44 CSS 픽셀 크기 보다 작은 크기로 컨트롤을 구성할 수도 있습니다. 다만 이 경우 동일한 기능을 수행하는 44×44 CSS 픽셀 크기의 또 다른 컨트롤이 있어야 합니다.
링크는 컨트롤에 해당하지만, 한 문장 내에서 링크 글자만 크게 만들 수는 없으므로 지침 성공기준에서 예외입니다. 문장 끝에 위치한 각주, 도움말 링크 또한 예외입니다. 아래 예는 44×44 CSS 픽셀 크기에 맞춰 링크 텍스트를 확대한 단락 입니다. 링크 글자 크기가 주변 텍스트에 비해 커짐에 따라 글을 읽기가 매우 어려워 집니다. 뿐만 아니라 화면을 확대할 경우 화면 크기가 조정 되면서 리플로우에 영향을 미칠 수 있습니다.
그리고 <button>, <select>, <input type="radio">와 요소와 같은 표준 HTML 컨트롤은 개발자가 임의로 스타일을 조정하지 않을 경우 이 성공기준에서 예외 처리됩니다.
마지막으로 컨트롤의 크기가 정보를 표시하는데 필요한 경우, 44×44 CSS 픽셀 크기 보다 작을 수도 있습니다. 예를 들어 사용자가 목표(target) 크기를 줄여 선택 정확도를 높이는데 도움이 되는 애플리케이션의 경우 그러합니다.
예시
아래 예는 카카오 페이지 웹 사이트의 캐러셀 인터페이스로 왼쪽 하단에 배치된 작은 크기의 내비게이션 컨트롤을 사용해 캐러셀 아이템을 탐색할 수 있습니다. 해당 컨트롤의 크기는 성공기준에 한참 부족한 10×16 CSS 픽셀 입니다. 게다가 <img> 요소가 컨트롤 역할을 수행하고 있어 성공기준 2.1.1 키보드 (A) 접근성도 갖춰지지 않습니다.
아래 예는 전자 책(E-Book) 리더의 페이지를 전환하는 2가지 방법을 보여줍니다. 페이지 오른쪽 하단에 아주 작은 페이지 넘기기 아이콘이 있습니다. 이 아이콘 컨트롤의 크기는 44×44 CSS 픽셀 보다 작아 성공 기준을 충족하지 못합니다. 하지만 오른쪽에 표시된 다음 페이지 넘김 컨트롤의 크기는 성공기준이 요구하는 크기보다 큽니다. 이처럼 동일한 기능을 수행하는 컨트롤 중 하나만 성공기준에 충족할 경우 접근성이 보장됩니다.
성공기준 이해하기 2.5.5을 보면 보다 상세한 디자인 가이드를 볼 수 있습니다.
2.5.6 동시 입력 메커니즘 (AAA)
웹 콘텐츠는 제한이 필수적인 경우, 예를 들면 콘텐츠 보안 보장 또는 사용자 설정을 침해하면 안되는 경우를 제외하고 플랫폼에서 사용할 수 있는 입력 방식을 제한하지 않습니다.
해설
사용자는 콘텐츠 작업 중에 다른 입력 장치로 전환해 사용할 수 있습니다. 음성 입력을 사용할 수도 있고, 키보드를 연결해 사용할 수도 있습니다. 예를 들어 음성 입력 사용자는 개인 정보 보호를 위해 암호를 입력 할 때는 키보드로 전환하는 것을 선호 할 수 있습니다. 그리고 많은 수의 노트북, 컴퓨터는 키보드와 터치 스크린을 제공하며 사용자는 하나의 화면에서 다른 화면으로 전환해 사용 할 수도 있습니다.
그렇기 때문에 개발자는 사용자가 터치 또는 마우스만 사용한다고 가정하여 개발 해서는 안됩니다. 사용자가 입력하는 다양한 방식을 고려하고 연구하여 개발해야 합니다. 개발 시 다음 성공기준을 염두에 두고 만들어야 합니다.
하지만 특정 애플리케이션은 작업을 수행하기 위해 특정 입력 장치를 사용해야 할 수 있습니다. 예를 들어 기타 코드의 손가락 위치를 가르치는 모바일 애플리케이션은 터치 인터페이스가 필수적으로 필요합니다. 이처럼 필수적으로 제한이 필요한 경우는 성공기준에 해당되지 않습니다.
성공기준 이해하기 2.5.6을 보면 보다 상세한 디자인 가이드를 볼 수 있습니다.
Last updated
