(Level A)
성공 기준(SC)
만약 콘텐츠에서 구현된 키보드 단축키가 문자(대소문자 포함, 구두점, 숫자, 또는 기호 문자)만으로 구성되어 있다면, 다음 중 하나 이상을 만족해야 한다.
이 성공 기준의 목적은 키보드 단축키의 의도하지 않은 활성화를 줄이는 것이다. 문자 키 단축키는 많은 키보드 사용자에게 유용하게 작동한다. 그러나 음성 입력 사용자의 경우, 음성 입력이 문자 입력으로 인식되기 때문에 적절하지 않거나 불편할 수 있다. 그리고 키를 잘못 누르기 쉬운 키보드 사용자에게도 문제가 될 수 있다. 이 문제를 해결하기 위해, 저작자는 문자 키만으로 이루어진 단축키를 사용자가 끄거나 재지정 할 수 있도록 해야 한다.
참고
이 성공 기준은 문자 키를 대상으로 하지만, 단축키가 하나의 물리적 키로 실행되느냐 혹은 여러 키를 조합해서 눌러야 하느냐는 중요하지 않다는 점에 유의해야 한다. 예를 들어, 대부분의 미국이나 영국식 풀 배열 키보드에서 ? (물음표) 기호는 Shift + / (오른쪽 Shift 키 옆 슬래시 키) 를 눌러 입력한다. 또한 영국식 키보드에서는 Windows 환경에서 é (악센트가 있는 소문자 e)를 입력하려면 AltGr + e 조합을 사용해야 한다. 이처럼 특별한 문자를 입력하기 위한 키 조합은 사용자의 키보드 배열에 따라 달라질 수 있다. 그러나 이러한 문자를 사용하는 단축키 역시 이 성공 기준의 적용 대상에 포함된다. 중요한 것은 단축키가 출력 가능한 문자(문자, 구두점, 숫자, 기호 등)에 의존 하는가 이지, 그 문자를 입력하기 위해 몇 개의 키를 눌러야 하느냐는 문제점이 아니다.
참고
이 성공기준은 문자 키의 순서(sequence)를 기반으로 한 단축키에도 적용된다. 예를들어 G를 누른 후 빠르게 A를 눌러 특정 동작을 실행하는 경우가 있다. 각각의 문자키 입력은 즉시 동작을 실행하지 않더라도, 전체적으로 이런 유형의 단축키는 문자키의 연속에 의존한다.
이 성공기준은 목록 상자나 드롭다운 메뉴와 같은 구성요소에는 영향을 미치지 않는다. 이러한 구성요소는 문자 키로 선택할 수 있는 단어를 포함하더라도, 그 구성요소가 초점이 있을 때 만 단축키가 활성화 되기 때문이다. 메뉴와 같은 다른 구성요소는 항목을 선택하기 전에 Alt 또는 Alt + F 단일 문자가 아닌 단축키로 먼저 접근하거나 열 수 있다. 이 경우 메뉴를 호출하는 전체 경로는 출력되지 않는 키를 포함한 2단계 단축키가 된다. 또한 액세스키(accesskey) 는 일반적으로 사용자 에이전트에 따라 다르지만 수식키와 함께 눌러야 활성화되므로, 이 기준의 적용 대상이 아니다.
음성 입력 사용자는 일반적으로 받아쓰기와 음성명령을 함께 사용할 수 있는 단일 모드를 사용한다. 사용자가 명령 전후 잠시 멈추었다 쓰는 방법을 알고 명령이 최소 두 단어 이상으로 구성되어 있어 잘 동작한다. 예를들어 사용자는 “the small boat”라고 받아쓰기를 말한 다음 잠시 멈추고 “Delete Line” 이라고 말을 하면, 해당 문장을 삭제하는 명령으로 인식한다. 반대로 “the small boat delete line” 이라고 두 문구를 쉬지 않고 같이 말하면 전체 문장이 받아쓰기 내용으로 나타난다. 일부 음성 입력프로그램은 받아쓰기 또는 명령만 듣기 모드를 제공하지만 대부분의 음성 사용자는 모든 입력을 인식하는 통합 모드를 사용한다. 모드를 전환하면 명령을 내릴 때 효율이 크게 떨어지기 때문이다.
음성 명령 사용자는 “press Control Foxtrot” 와 같은 구문으로 대부분의 키보드 명령어를 실행 할 수 있다. 웹 사이트 또는 앱이 키보드 입력을 지원한다면, Ctrl+P 키보드 명령을 “인쇄 하기”로 호출 하는 음성 매크로를 작성 할 수도 있다.
단일 키 단축키는 예외이다. 단일 문자키를 조작용도로 사용하는것은 많은 키보드 사용자에게 적합할 수 있으나 음성 사용자에게는 심각한 재앙이다. 그 이유는 단일키로 명령이 실행 되는 경우, 사용자가 말할 때 초점이 잘못 가 있으면 말을 한 단어가 각 글자의 단축키로 인식되여 명령이 연속적으로 실행될 수 있기 때문이다.
예를 들어 “Kim” 이라는 음성-입력 사용자가 웹 메일 앱의 창에 포커스를 두고 작업을 할 때, 앱은 보통 (k)로 이동, (y)로 보관 (m)으로 메세지를 뮤트하는 단축키를 사용한다. 회사 동료 Mike 가 “Hey Kim” 이라고 인사하면 마이크가 이를 포착해 다음과 같은 일이 일어난다. “hey”의 Y가 메세지를 보관하고, “kim”의 K이 다음 메세지로 이동하고, “kim”의 M이 메세지를 뮤트한다. 그리고 Kim 이 회사동료 Mike 를 보고 마이크를 끄지않고 “Hey Mike” 라고 인사하면, 똑같은 세 동작이 다른 순서로 반복 실행된다.
단일 문자 단축키를 사용하지 않는 웹 페이지나 웹 앱에서는 이러한 상호작용 문제가 발생하지 않는다. 수식키가 필요한 경우, 음성 명령 프로그램이 문자열을 단축키로 인식하지 않기 때문이다. 물론 음성 입력 중 실수로 문장을 인식하면 문자 입력 필드에 불필요한 문자가 입력될 수 있으나, 쉽게 보고 되돌릴 수 있다. 이 페이지의 참고자료에 이런 종류의 문제를 시연하는 영상 링크들이 있다.
사용자가 문자 단축키를 비활성화할 수 있는 메커니즘을 제공해야 한다. 문자 단축키가 명령을 수행하는 유일한 방법이 아니어야 한다. 음성 입력 사용자는 이러한 단축키를 꺼서, 마이크로 인식된 단어가 단일 문자 단축키를 의도치 않게 실행하는걸 막을 수 있다.
키보드만 사용하는 사용자가 긴 이슈 타래(thread)를 읽고 있다. 타래를 읽는 도중 실수로 S키를 눌러 문서 상단에 있는 검색창에 초점이 이동되었다. 이로 인해 사용자가 읽던 위치와 생각의 흐름을 놓칠 수 있다. 하지만 사용자에게 단일 문자 단축키를 바꿀 수 있는 메커니즘을 제공한다. 사용자는 단축키를 다른 키와 같이 누르도록 바꿔서, 이후에 이러한 문제를 방지할 수 있다.
자료는 정보 제공 목적으로만 제공되며 보증을 암시하지 않는다.
문자 키 단축키를 사용하고 사용자가 이러한 단축키를 비활성화 및/또는 변경할 수 있도록 허용하는 웹 앱:
단일 문자 키 단축키 관련 음성 사용자 문제에 대한 비디오:
이 섹션의 각 번호가 매겨진 항목은 접근성 지침 실무 그룹이 이 성공 기준을 충족하기에 충분하다고 판단하는 기법 또는 기법의 조합을 나타낸다. 기법은 기준의 최소 요구 사항을 넘어설 수 있다. 이러한 기법에서 포괄하지 않은 기준 충족의 다른 방법이 있을 수 있다. 다른 기법 사용에 대한 정보는 WCAG 성공 기준에 대한 기법 이해, 특히 “기타 기법” 섹션을 참조하라.
다음은 접근성 지침 실무 그룹에서 이 성공 기준의 실패로 간주하는 일반적인 실수이다.
다음은 이 성공 기준의 특정 측면에 대한 점검 규칙이다. WCAG 준수 여부를 확인하기 위해 이러한 특정 점검 규칙을 사용할 필요는 없지만 이것은 정의되고 승인된 검사 방법이다. 점검 규칙 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 점검 규칙 이해를 참고하라.
