나는 키보드 하나로 하루 동안 웹을 사용했다

이 기사는 주어진 사용자 인구 통계를 나타내는 다양한 제약 조건에서 웹을 사용하려고 시도하는 시리즈의 일부입니다. 나는 우리가 그들의 필요에 공감하는 방식으로 디자인하고 개발한다면 피할 수 있는 실제 사람들이 직면한 어려움에 대한 프로필을 올리기를 희망합니다. 저번에는 자바스크립트 없이 하루 동안 웹을 사용했습니다. 오늘은 강제로 키보드만 사용하여 웹을 탐색했습니다.

누가 키보드를 사용하여 탐색합니까?

일반적으로 키보드 사용자에는 세 가지 유형이 있습니다.

• 마우스 사용에 어려움을 겪는 거동이 불편한 사용자,
• 페이지에서 클릭 가능한 요소를 볼 수 없는 시각 장애가 있는 사용자,
• 마우스를 사용할 수 있지만 키보드를 더 빨리 사용하는 고급 사용자.

얼마나 많은 사용자가 이야기하고 있습니까?

나는 키보드 사용에 대한 통계를 위해 웹을 뒤졌다. 그리고 나는 아무것도 찾을 수 없었다. 진지하게. 한 연구 아닙니다.

대부분의 키보드 접근성 안내 사이트는 "많은 사용자"가 키보드를 사용하여 이동하는 것을 당연하게 여깁니다. 대략적인 수치를 얻으려는 사람은 대개 "통계는 중요하지 않습니다. 귀하의 사이트에 액세스할 수 있어야 합니다."

네, 비마우스 사용의 척도가 논점인 것은 사실입니다. 단 한 명의 사용자에게도 권한을 부여하는 변경을 할 수 있다면 그것은 가치 있는 변경입니다. 그러나 색맹, 브라우저 사용량, 연결 속도 등과 같은 항목에 대해 사용할 수 있는 통계가 많이 있습니다. 숫자가 사이트에서 제안하는 것만큼 널리 퍼져 있다면, 확실히 숫자가 있으면 더 강력한 비즈니스 사례가 가능하고 이해 관계자가 키보드 액세스를 쉽게 방어할 수 있게 될 것입니다.

내가 찾을 수 있는 숫자에 가장 가까운 것은 PowerMapper의 기사로, 미국, 영국 및 캐나다의 노동 연령 성인의 7%가 "심각한 손재주 어려움"을 겪고 있다고 제안합니다. 이것은 그들이 "마우스를 사용하지 않고 대신 키보드에 의존하게" 만들 것입니다.

심각한 시각 장애가 있는 사용자는 화면의 내용을 합성 음성으로 읽어주는 소프트웨어인 스크린 리더라는 소프트웨어를 사용합니다. 시력이 있는 사용자와 마찬가지로 시력이 없는 사용자는 페이지에서 흥미로운 정보를 검색할 수 있기를 원하므로 화면 판독기에는 제목 및 링크를 통해 탐색할 수 있는 키보드 단축키가 있으며 상호 작용을 위해 키보드에 초점을 맞출 수 있는 요소에 의존합니다.

“맹인들은 완전한 키보드 접근이 필요합니다. 기간."

— David Macdonald, HTML5에서 WAI ARIA 사용의 공동 편집자

이 동일한 사용자는 또한 모바일 장치에 화면 판독기를 가지고 있으며, 여기에서 키보드를 누르는 대신 살짝 밀기 제스처를 사용하여 콘텐츠를 '탭'합니다. 따라서 문자 그대로 키보드를 사용하는 것은 아니지만 스크린 리더 기술이 키보드를 사용하는 것처럼 동일한 탭 순서 및 이벤트 리스너에 연결되기 때문에 사이트에서 키보드에 액세스할 수 있어야 합니다. 화면 판독기 사용자의 약 2/3에서 3/4만이 시각 장애인이며 나머지는 화면 판독기와 확대 기술의 조합을 사용할 수 있음을 의미합니다.

모든 연령대의 미국인 중 2.3%가 시각 장애가 있으며 모든 사람이 화면 판독기의 사용을 보증하는 것은 아닙니다. 2016년 Addy Osmani는 실제 스크린 리더 사용량을 약 1~2%로 추정했습니다. 이러한 사용자를 거동이 불편한 사용자 및 고급 사용자와 함께 고려하면 전 세계 사용자의 상당한 비율이 키보드 사용에 추가됩니다. 따라서 키보드 접근성에 대한 관심은 도덕적으로(그리고 법적으로 많은 국가에서 웹사이트에 법적으로 접근할 수 있도록 요구하고 있음) 올바른 일을 하는 것일 뿐만 아니라 비즈니스 측면에서도 타당합니다.

이 모든 것을 염두에 두고 오늘날 웹의 상태는 어떻습니까? 알아보는 시간!

실험

하루 정도의 위협적인 일이 눈앞에 있을 때 모두는 무엇을 합니까? 미루다! youtube.com으로 이동했습니다. 특정 비디오를 염두에 두고 있었고 기본적으로 페이지 로드에 초점을 맞추기 때문에 기본 검색 상자에 탭할 필요가 없다는 것을 알게 되어 감사했습니다.

autofocus 속성

나는 이것이 창 로드 시 JavaScript로 집중될 것이라고 가정했지만 실제로는 입력 요소에 대한 autofocus 속성을 사용하여 브라우저에서 처리됩니다.

시력 키보드 사용자로서 나는 이것이 매우 유용하다는 것을 알았습니다. 블라인드 스크린 리더 사용자로서 원하는지 아닌지 잘 모르겠습니다. 페이지의 유일한 목적이 양식(예: Google 방문 페이지 또는 사이트 문의 양식)과 상호 작용하는 것인 경우 autofocus 을 신중하게 사용하는 것이 좋다는 데 동의하는 것 같습니다.

기본 초점 스타일

나는 누구의 라인인지 검색했습니다. 어쨌든? 그리고 YouTube가 사용자 정의 :focus 스타일을 정의하지 않았음을 알아차릴 수 없었습니다. 대신 브라우저의 기본 스타일에 의존하여 탭으로 이동한 요소를 시각적으로 표시했습니다.

나는 항상 모든 브라우저가 자신만의 :focus 상태를 정의하는 것은 아니라는 인상을 받아왔습니다. 그래서 당신 은 자신만의 커스텀 스타일을 정의해야 합니다. 나는 이것을 테스트하기로 결정했고 어떤 브라우저가 기본 스타일을 구현하지 않는지 확인했지만 놀랍게도 찾을 수 없었습니다. 내가 테스트한 모든 브라우저에는 스타일이 다양하지만 고유한 :focus 의 고유한 구현이 있습니다.

나는 심지어 아주 먼 과거로 갔다.

더 보고 싶다면 브라우저 기본 상태의 다양한 요소에 대한 포괄적인 스크린샷 모음이 있습니다.

이것이 나에게 말하는 것은 모든 브라우저에 몇 가지 기본적인 :focus 스타일이 제공된다고 합리적으로 가정할 수 있다는 것입니다. 브라우저가 작업을 수행하도록 하는 것이 좋습니다. 당신이 위험에 빠뜨리는 것은 불일치입니다. 모든 브라우저는 요소 스타일을 미묘하게 다르게 지정하고 일부는 너무 미묘하여 시각적으로 액세스할 수 없습니다.

기본 브라우저 포커스 스타일을 비활성화하는 것은 요소에 대해 outline: none 을 설정하여 가능하지만 고유한 스타일 대안을 구현하는 경우에만 이 작업을 수행해야 합니다. Heydon Pickering은 일부 브라우저에서 사용되는 불분명하거나 못생긴 기본값을 인용하여 이 접근 방식을 권장합니다. 자신만의 스타일을 출시하기로 결정했다면 색상 이상을 수정자로 사용하십시오. 색맹 사용자를 지원하기 위해 윤곽선이나 밑줄 또는 기타 시각적 표시기를 추가하십시오.

많은 사이트에서 기본 포커스 스타일을 억제하지만 사용자 지정 스타일을 제공하지 않아 액세스할 수 없는 경험을 하게 됩니다. 사이트에서 Eric Meyer의 CSS 재설정을 사용하는 경우 액세스하지 못할 수 있습니다. 일반적으로 사용되는 이 파일은 기본 :focus 스타일을 재설정하지만 개발자에게 고유한 스타일을 작성하도록 지시하고 많은 사람들이 지침을 찾지 못합니다.

어떤 사람들은 브라우저 기본값을 비활성화하면 사용자가 익숙한 포커스 상태의 시각적 어포던스를 잃고 대신 사이트의 포커스 상태가 어떻게 생겼는지 배워야 하기 때문에 사용자에게 혼란을 줄 수 있다고 주장합니다. 반면에 일부에서는 브라우저 기본값이 보기 흉하거나 키보드가 아닌 사용자에게 혼동을 주기까지 한다고 주장합니다.

왜 혼란스럽습니까? BBC에서 이 애니메이션 회전 목마 형식을 확인하십시오. 두 개의 탐색 버튼(다음 및 이전)이 있으며 설명 전체에 걸쳐 포커스가 유지된다는 것은 키보드 사용자에게 유용합니다. 그러나 마우스 사용자에게는 클릭한 버튼이 커서를 다른 곳으로 이동한 후에도 여전히 '포커스'되어 있다는 것이 상당히 혼란스러울 수 있습니다.

:focus-visible CSS 선택기

두 세계의 장점을 모두 원한다면 컨텍스트에 따라 다른 포커스 스타일을 제공할 수 있는 CSS4 :focus-visible 의사 클래스를 탐색할 수 있습니다. :focus-visible 스타일링은 마우스 클릭이 아닌 키보드로 초점을 맞춘 요소만 대상으로 합니다. 이것은 매우 훌륭하지만 현재는 Firefox에서만 기본적으로 지원됩니다. Chrome에서 '실험적 웹 플랫폼 기능' 플래그를 켜서 활성화할 수 있습니다.

YouTube 동영상 및 키보드 접근성

YouTube는 비디오 플레이어로 훌륭한 작업을 수행합니다. 플레이어의 모든 부분은 키보드로 탐색할 수 있습니다. 나는 음소거 아이콘 위로 마우스를 가져갈 때 슬라이드 아웃하는 것과 대조적으로 음소거 아이콘에서 포커스를 탭할 때 볼륨 컨트롤이 슬라이드 아웃되는 방식을 좋아합니다.

내가 마음에 들지 않는 것은 음소거 아이콘 위로 마우스를 가져갈 때 나타나는 '음소거' 텍스트와 같은 유용한 레이블이 포커스에 표시되지 않는다는 것입니다.

YouTube를 실망시키는 또 다른 영역은 일부 초점 스타일을 억제한다는 것입니다. 여기에서 '더 보기' 버튼을 탭하려고 했습니다.

사용자 지정이든 기본이든 적용되는 :focus 스타일을 볼 수 없기 때문에 실수로 '더 보기' 버튼 바로 옆에 탭했습니다. 나는 기본 스타일이 outline-width 로 재정의되고 있다는 것을 알아 냈습니다.

GitHub 키보드 접근성

알겠습니다. 작업 시간입니다. 코드의 본고장인 github.com보다 일하기 좋은 곳이 어디입니까?

GitHub에 대해 세 가지 사항을 확인했습니다. 하나는 훌륭하고 하나는 합리적이고 다른 하나는 나쁩니다.

첫째, 좋은.

'콘텐츠로 건너뛰기' 링크

GitHub는 기본 메뉴를 건너뛰는 Skip to content 제공합니다.

'콘텐츠로 건너뛰기' 링크에 초점을 맞춘 상태에서 ENTER 를 누르면 페이지 상단의 모든 메뉴 항목을 건너뛰고 콘텐츠의 주요 영역 내에서 탭을 시작할 수 있으므로 탐색 시간을 절약할 수 있습니다. 이것은 키보드와 스크린 리더 사용자 모두에게 매우 유용한 일반적인 접근성 패턴입니다. 스크린 리더 사용자의 약 30%는 건너뛰기 링크를 제공하는 경우 이를 사용합니다.

또는 일부 사이트에서는 탐색 위의 읽기 순서에서 주요 콘텐츠를 먼저 배치하도록 선택합니다. 이 접근 방식은 (탐색이 시각적으로 맨 아래에 나타나지 않는 한) DOM 콘텐츠가 시각적 순서와 일치하도록 하는 지침을 어기므로 유행에서 벗어났습니다. 이 접근 방식은 '네비게이션 건너뛰기' 링크가 전혀 필요하지 않음을 의미하지만 그 자리에 '내비게이션 으로 건너뛰기' 링크를 원할 것입니다.

콘텐츠를 보려면 탭

'비키보드' 버전과 다르게 작동하는 것으로 확인된 기능 중 하나는 코드 분석 표시기였습니다.

마우스를 사용하여 저장소 아래에 있는 색상 막대를 클릭하여 저장소에서 사용되는 다양한 프로그래밍 언어의 비례 분석을 볼 수 있습니다. 키보드를 사용하면 실제로 색상 막대로 이동할 수 없지만 메타 정보의 끝을 탭하면 언어가 자동으로 표시됩니다.

이것은 실제로 필요하지 않은 것 같습니다. 기꺼이 색상 막대를 탭하고 ENTER 를 누르겠습니다. 그러나 이 다른 동작도 해를 입히지 않습니다.

보이지 않는 링크

내가 발견한 문제 중 하나는 오른쪽 상단에서 내 프로필 사진을 탭한 후 "보이지 않는" 링크가 있다는 것입니다. 내 탭 순서는 그림으로 이동한 다음 이 보이지 않는 링크로 이동한 다음 리포지토리의 '보기' 버튼으로 이동합니다(아래 gif 참조). 나는 보이지 않는 링크가 무엇을 했는지 전혀 몰랐기 때문에 내가 그 링크에 있다는 것을 알았을 때 ENTER 키 를 누르고 즉시 로그아웃되었습니다!

자세히 살펴보면 '로그아웃' 기능이 있는 "스크린 리더 전용" 양식( sr-only 는 일반적인 스크린 리더 클래스 이름임)으로 이동한 것 같습니다.

이 로그아웃 링크는 프로필 드롭다운 메뉴의 로그아웃 링크 에 추가 됩니다.

스크린 리더 사용자가 드롭다운을 실행하고 기본 로그아웃 링크로 이동할 수 있어야 하므로 두 개의 별도 HTML 로그아웃 링크가 필요한지 잘 모르겠습니다. 그리고 별도의 링크를 유지하려면 화면 판독기 콘텐츠에 :focus 스타일을 적용하여 눈에 보이는 사용자가 실수로 자신 을 로그아웃하지 않도록 하는 것이 좋습니다.

'콘텐츠로 건너뛰기' 바로 가기를 만드는 방법

그렇다면 '콘텐츠로 건너뛰기' 바로 가기를 다시 만드는 방법은 무엇입니까? 구현하기는 매우 간단하지만 완벽하게 구현하기가 매우 까다로울 수 있습니다. 따라서 여기에서 링크 건너뛰기 솔루션의 성배라고 생각합니다.

'링크 건너뛰기'는 '내비게이션 건너뛰기', '메인 탐색 건너뛰기', '내비게이션 링크 건너뛰기' 또는 '주요 콘텐츠로 건너뛰기'라고도 합니다. '주 콘텐츠로 건너뛰기'는 건너뛰는 대상이 아니라 탐색 중인 위치를 알려 주기 때문에 아마도 가장 명확할 것입니다.

바로 가기 링크는 여는 <body> 태그 바로 뒤에 이상적으로 표시되어야 합니다. 탭 순서의 첫 번째 대화형 요소가 되도록 강제하는 tabindex="1" 속성이 있는 경우 바닥글 뒤에도 DOM에 나중에 나타날 수 있습니다. 그러나 0보다 큰 숫자로 tabindex를 사용하는 것은 일반적으로 나쁜 습관이며 Lighthouse와 같은 유효성 검사 도구를 사용할 때 종종 경고가 표시됩니다.

tabindex="1" 에 대한 링크가 두 개 이상 있을 수 있으므로 tabindex 에 의존하는 것이 안전하지 않습니다. 이 경우 탭 포커스를 먼저 얻는 것은 나중의 링크가 아니라 첫 번째 링크입니다. tabindex 속성 사용에 대한 자세한 내용은 여기를 참조하세요. 그러나 안전을 위해 링크를 DOM의 시작 부분으로 물리적으로 이동하는 것이 항상 더 낫다는 것을 기억하십시오.

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

'주요 콘텐츠로 건너뛰기' 링크는 이미 눈으로 탐색을 건너뛸 수 있는 시력 사용자에게만 사용이 제한되어 있습니다. 따라서 일부 사이트에서는 건너뛰기 링크를 항상 볼 수 있도록 유지하지만 오늘날의 규칙은 탭할 때까지 링크를 숨긴 상태로 유지하는 것입니다. 이때 링크는 포커스에 있고 :focus 의사 선택기에 의해 적용된 스타일을 얻습니다.

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

그래서, 우리는 실제로 무엇을 건너 뛰고 있습니까? #main-content 란 무엇입니까? 정말 무엇이든 될 수 있습니다.

1. 인라인 콘텐츠
   즉, h1 태그의 ID: <h1 id="main-content"> .
2. 컨테이너
   예를 들어 <main id="main-content"> 와 같은 주요 콘텐츠 주변의 컨테이너 ID입니다.
3. 형제 앵커
   기본 콘텐츠 바로 위에 있는 명명된 태그(예: <a name="main-content"></a> )에 연결할 수 있습니다. 이 접근 방식은 일반적으로 이전 자습서에 설명되어 있습니다. 요즘에는 권장하지 않습니다.

모든 화면 판독기에서 최대한의 호환성을 위해 h1 태그에 연결하는 것이 좋습니다. 이는 건너뛰기 링크를 사용하는 즉시 콘텐츠를 읽을 수 있도록 하기 위한 것입니다. 컨테이너에 연결하면 재미있는 동작이 발생할 수 있습니다. 예를 들어 스크린 리더가 컨테이너 내부의 모든 콘텐츠를 읽기 시작합니다.

#main-content 에는 프로그래밍 방식으로 초점을 맞출 수 있도록 tabindex 가 -1 이어야 합니다. 일부 스크린 리더는 건너뛰기 링크를 따르지 않을 수 있습니다.

 <h1 tabindex="-1">This is the title of the page</h1>

마지막 고려 사항: 레거시 브라우저 지원. IE9 이하의 사용자가 충분한 경우 건너뛰기 링크에 작은 JavaScript 수정을 적용하여 초점이 실제로 예상대로 이동하고 사용자가 탐색을 성공적으로 건너뛸 수 있도록 해야 할 수 있습니다.

바퀴를 재발명하는 이유는 무엇입니까?

웹 개발자로서 우리의 모든 사이트에 이 '네비게이션 건너뛰기' 해킹을 원칙적으로 구현해야 한다는 것은 미친 것 같습니다. 당신은 우리가 표준이 작동하도록 할 수 있다고 생각할 것입니다.

HTML5 이후로 <main> , <nav> 및 <header> 와 같은 의미론적 요소가 있었습니다. 그 이전에는 각각 role="main" , role="navigation" 및 role="banner" 와 같은 ARIA 랜드마크가 있었습니다. 웹의 현재 환경에서 모범 사례는 둘 다 필요하다고 지시합니다. 예를 들어 <main role="main"> 은 DRY 원칙을 끔찍하게 위반하는 것입니다.

이 모든 의미론적 풍부함과 함께, 예를 들어 사용자가 웹 페이지의 <main> 섹션으로 바로 탭할 수 있는 키보드 단축키를 노출함으로써 브라우저가 이러한 랜드마크 영역을 통한 탐색을 기본적으로 지원하기 시작하기를 바랍니다. 그런 행운은 없습니다. 현재 기본 지원이 없습니다. 가장 좋은 방법은 Chrome, Opera 또는 Firefox용 키보드 확장을 통해 Landmark Navigation을 사용하는 것입니다.

그러나 스크린 리더 사용자는 이러한 랜드마크 영역으로 직접 탐색을 시작할 수 있습니다 . 예를 들어, Mac의 VoiceOver에서 CTRL + ALT + U 를 눌러 랜드마크 메뉴를 불러오고 '메인' 랜드마크로 이동할 수 있습니다. 물론 이것은 문서를 올바르게 표시하는 사이트에 의존합니다.

랜드마크 영역을 통해 사이트를 탐색할 수 있도록 하려면 다음과 같이 사이트를 시작하는 것이 좋습니다.

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

이 모든 마크업은 목이 마른 작업입니다. 커피를 위한 시간입니다.

팩트커피

나는 pactcoffee.com의 전단지를 본 기억이 납니다... 가서 살펴봅시다!

쿠키 배너

'쿠키 정책' 배너는 여기에서 가장 먼저 눈에 띄는 것 중 하나이며 이를 무시하는 것은 시력을 가진 마우스 사용자에게 거의 본능적인 반사입니다. 일부 스크린 리더 사용자는 그것에 대해 신경 쓰지 않을 수도 있습니다(당신이 시각 장애인이라면 닿을 때까지 그것이 있는지 알지 못할 것입니다). 그러나 시력을 가진 사용자로서 당신은 그것을 보고 죽이고 싶어합니다. 이 사이트를 닫으려면 다른 모든 링크를 탭해야 합니다.

ChromeLens 접근성 확장 프로그램을 사용하여 페이지의 탭 순서를 추적했습니다.

이것은 문서의 상단으로 알림을 이동하거나(CSS를 사용하여 시각적으로 하단에 고정할 수 있음) 확인 버튼에 tabindex="1" 을 추가하여 수정할 수 있습니다. 사용자가 무시하고 싶어할 것으로 예상되는 모든 콘텐츠에 이 수정 사항을 적용하는 것이 좋습니다.

더 많은 보이지 않는 링크

GitHub에서와 마찬가지로 목적이 명확하지 않은 화면 밖의 요소를 탭핑하고 있는 자신을 발견했습니다. '더 보기…' 카드 뒤에 있는 '덜 보기…' 토글로 밝혀졌습니다.

이것은 '숨겨진' 영역이 실제로 숨겨져 있는 것이 아니라 다음을 사용하여 180도 회전했기 때문입니다.

 transform: rotateY(180deg);

...즉, '더 보기...' 버튼은 여전히 ​​탭 순서의 일부입니다. 이것은 응용 프로그램이 회전을 트리거할 준비가 될 때까지 display: none 을 적용하여 수정할 수 있습니다.

주문한 커피. 이제 내 연구를 계속해야 할 때입니다.

IT월드

나는 이 기사를 위해 약간의 조사를 하고 있었고 내 자신과 유사한 실험을 발견했습니다. Kevin Purdy는 7일 동안 키보드만 사용하여 웹을 검색했습니다. 같은 제약 조건에서 그의 기사를 읽을 수 없다는 것이 아이러니합니다!

문제는 "개인 정보 설정 업데이트"를 요구하거나 기본 쿠키 설정을 수락해야 하는 전체 페이지 쿠키 배너였습니다. 탭을 몇 번을 해도 쿠키 배너에 집중할 수 없었고 무시했습니다.

무슨 일이 일어나고 있는지 알아보기 위해 소스 코드를 파헤쳤습니다. 잠시 동안 나는 이것이 우리의 가장 큰 천적, outline CSS 속성일지도 모른다고 생각했습니다.

"개인 정보 설정 업데이트" 링크를 검사하면 내가 의심한 대로 outline: 0 를 볼 수 있습니다. 그래서 아마도 나는 버튼에 초점을 맞추고 있지만 그럴 때 시각적 피드백이 없습니까?

상태를 :hover 로 설정하여 키보드 사용자로서 스타일 지정을 놓치고 있는지 확인했습니다.

확실히, 링크는 호버에서 멋지고 분명한 주황색으로 바뀌었습니다. 초점에 대해 본 적이 없는 것:

헐! 부숴버렸어! 사용자 정의 스타일이 :hover 에만 적용되기 때문에 :focus 상태를 본 적이 없습니다. 나도 모르게 버튼을 지나쳤을 텐데, 그렇죠?

잘못된. CSS를 로컬에서 해킹해도 포커스 스타일을 볼 수 없었습니다. 즉, 쿠키 모달을 탭하는 것까지 할 수 없었습니다. 그런 다음 나는 ... 링크에 href 속성이 없다는 것을 깨달았습니다.

그게 진짜 범인이었다. outline: 0 은 문제가 아니었습니다. 브라우저는 링크가 유효한 링크가 아니기 때문에 해당 링크를 탭하지 않을 것입니다!

HTML 5.2 사양에서:

링크의 대상은 href 속성에 의해 지정되며, 이 속성은 존재해야 하며 공백으로 묶일 수 있는 비어 있지 않은 유효한 URL을 포함해야 합니다. href 속성이 없으면 요소가 링크를 정의하지 않습니다.

링크에 href 속성을 부여하면(단순한 # 일지라도) 유효한 링크가 되고 페이지의 탭 순서에 추가됩니다.

재미있게도 그 날 나중에 PC World에서 읽으라고 한 기사를 받았는데 정확히 같은 문제가 발생했습니다.

두 사이트 모두 동일한 CMP(동의 관리 플랫폼)를 사용하고 있었던 것 같습니다. 나는 약간의 파고를 했고 그것이 같은 회사가 소유한 여러 사이트에 영향을 미치고 있다고 추론했으며 그 이후 제안된 수정 사항으로 직접 연락했습니다.

키네티코

주방 수도꼭지에서 누수가 발생하여 교체하려고 합니다. 나는 kinetico.co.uk에 대한 지역 신문에서 광고를 보았고, 그래서 한 번 봐야겠다고 생각했습니다.

링크가 '소금 및 카트리지' 상위 링크 뒤에 숨겨져 있었기 때문에 '주방 탭' 섹션으로 이동할 수 없었습니다. 사이트가 '콘텐츠로 건너뛰기' 링크(위의 gif에서 간략하게 참조)를 제공할 만큼 충분히 진보적이지만 접근 가능한 메뉴를 만들 수 없다는 점은 흥미롭습니다!

메뉴가 잘못된 부분은 다음과 같습니다. 상위 메뉴 항목 위에 마우스를 올려 놓을 때만 하위 메뉴가 표시됩니다.

그것을 고치는 것은 말보다 쉽습니다. 대부분의 경우 선택기를 "두 배로"하여 포커스에도 적용할 수 있습니다.

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

그러나 <li> 요소는 호버링할 수 있지만 포커스할 수 없기 때문에 이 경우에는 작동하지 않습니다. 초점을 맞출 수 있는 것은 <li> 내부의 링크 입니다. 그러나 하위 메뉴는 링크 내부가 아니라 링크 옆 에 있으므로 링크에 포커스가 있을 때 하위 메뉴를 표시하려면 형제 선택기를 적용해야 합니다.

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

이 조정은 키보드의 상위 메뉴 항목을 탭할 때 하위 메뉴를 볼 수 있음을 의미합니다. 그러나 하위 메뉴로 탭하려고 하면 어떻게 됩니까?

상위 메뉴 항목에서 탭하면 예상대로 하위 메뉴의 첫 번째 링크로 포커스가 이동합니다. 그러나 이렇게 하면 상위 메뉴 링크에서 포커스가 멀어 집니다. 즉, 하위 메뉴가 숨겨지고 하위 메뉴 항목이 탭 순서에서 다시 제거됩니다!

이것은 :focus-within 으로 해결할 수 있는 문제입니다. 이를 통해 부모 요소 또는 자식 요소 에 포커스가 있는 경우 부모 요소에 스타일을 적용할 수 있습니다. 따라서 이 경우에는 다음을 세 배로 늘려야 합니다.

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

메뉴는 이제 순수 CSS를 통해 완전히 키보드로 액세스할 수 있습니다. 저는 창의적인 CSS 솔루션을 좋아하지만 여기에서 경고 한 마디가 있습니다. 키보드 탐색과 관련하여 야생에서 "CSS 전용" 솔루션이 많이 떨어집니다. JavaScript를 피한다고 해서 반드시 사이트에 더 쉽게 접근할 수 있는 것은 아닙니다.

사실, 이 솔루션에 대한 브라우저 지원은 여전히 ​​매우 열악하기 때문에 이 경우에는 JS 기반 메뉴가 더 나을 수 있습니다. :focus-within 은 현재 Chrome, Firefox 및 Safari에서만 사용할 수 있습니다. Chrome에서도 display: none . 대신 opacity: 0 을 설정하여 메뉴 항목을 숨겨야 했습니다.

알겠습니다. 오늘의 일을 마쳤습니다. 이제 약간의 소셜 미디어로 마무리할 때입니다.

페이스북

Facebook은 여기에서 놀라운 일을 하여 키보드 접근성의 마스터 클래스를 제공합니다.

첫 번째 TAB 키 를 누르면 숨겨진 메뉴가 열리고 현재 페이지의 가장 인기 있는 섹션에 대한 바로 가기와 다른 인기 있는 페이지에 대한 링크를 제공합니다.

화살표 키를 사용하여 페이지 섹션을 순환하면 해당 섹션이 시각적으로 강조 표시되어 탭으로 이동할 위치를 볼 수 있습니다.

가장 유용한 기능은 Facebook이 aria-keyshortcuts 속성을 사용하여 언제든지 메뉴로 돌아갈 수 있는 OPT + / (또는 ALT + / ) 단축키를 제공한다는 것입니다.

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

기본 앵커링 기술을 기반으로 구축되고 "정상 작동"하는 '주 콘텐츠로 건너뛰기' 링크와 달리 aria-keyshortcuts 속성은 작성자가 모든 키보드 동작을 구현해야 하므로 일부를 작성해야 합니다. 이것을 사용하려면 사용자 정의 JavaScript를 사용하십시오.

다음은 유용한 시작점인 menubar 영역을 숨기고 표시하는 일부 JS입니다.

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

요약

이 실험은 훌륭한 키보드 경험과 좋지 않은 키보드 경험이 혼합되어 있습니다. 세 가지 주요 사항이 있습니다.

스타일리시하게 유지

지금까지 내가 직면한 가장 일반적인 키보드 접근성 문제는 탭 가능한 요소에 대한 포커스 스타일 지정 부족입니다. 사용자 정의 포커스 스타일을 정의하지 않고 기본 포커스 스타일을 억제하면 페이지에서 현재 위치를 파악하는 것이 매우 어렵고 심지어 불가능합니다. 아웃라인을 제거하는 것은 너무 흔한 실수로 전용 사이트도 있습니다.

기본 또는 사용자 지정 포커스 스타일이 표시되도록 하는 것은 키보드 접근성 영역에서 할 수 있는 가장 영향력 있는 단일 작업이며 종종 가장 쉬운 것 중 하나입니다. 기존 :hover 스타일에 선택기를 두 배로 늘리는 간단한 경우입니다. 이 기사를 읽은 후 한 가지만 수행한다면 CSS에서 outline: 0 및 outline: none 을 검색해야 합니다.

시맨틱이 핵심

현재 창만 리디렉션되도록 새 탭에서 링크를 열려고 몇 번이나 시도했습니까? 그것은 나에게 때때로 발생하고 짜증나는 일이지만 웹을 사용할 때 직면하는 경향이있는 유일한 사용성 문제 중 하나라는 것이 운이 좋습니다. 이러한 문제는 플랫폼을 오용하여 발생합니다.

여기에서 이 코드를 살펴보겠습니다.

 <span>Click here</span>

유능하고 시력이 좋은 사용자는 <span> 을 클릭하고 Google로 리디렉션될 수 있습니다. 그러나 이것은 링크나 버튼이 아니라 <span> 이기 때문에 자동으로 초점을 맞출 수 없으므로 키보드나 스크린 리더는 상호 작용할 방법이 없습니다.

키보드 사용자는 표준에 의존하는 사용자인 반면, 유능하고 시력이 좋은 인구 통계는 부적합에도 불구하고 요소와 상호 작용할 수 있을 만큼 충분히 특권을 가지고 있습니다.

플랫폼의 기본 기능을 사용합니다. 훌륭하고 깨끗한 HTML을 작성하고 https://validator.w3.org와 같은 유효성 검사기를 사용하여 앵커에서 누락된 href 속성과 같은 것을 포착하십시오.

콘텐츠가 핵심

쿠키 알림, 구독 양식, 광고 또는 광고 차단 알림을 표시해야 할 수 있습니다.

이러한 경험을 방해하지 않도록 할 수 있는 일을 하십시오. 눈에 거슬리지 않게 만들 수 없다면 최소한 무시할 수 있게 만드십시오.

사용자는 배너가 아니라 콘텐츠를 보기 위해 존재합니다. 따라서 이러한 닫을 수 있는 요소를 DOM에서 먼저 배치하여 빠르게 닫을 수 있도록 하거나 이동할 수 없는 경우 tabindex="1" 을 사용하도록 대체하십시오.

마지막으로 '주 콘텐츠로 건너뛰기' 링크라는 성배를 구현하여 사용자가 최대한 빨리 콘텐츠에 액세스할 수 있도록 지원합니다.

이 시리즈의 다음 기사에서 하루 동안 스크린 리더를 사용할 때 이러한 기술 중 일부를 구축할 예정이므로 계속 지켜봐 주시기 바랍니다.