나는 스크린 리더를 사용하여 하루 동안 웹을 사용했습니다

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

스크린 리더 란 무엇입니까?

화면 판독기는 화면의 내용(텍스트, 이미지, 링크 등)을 해석하고 시각 장애가 있는 사람들이 소비하고 상호 작용할 수 있는 형식으로 변환하는 소프트웨어 응용 프로그램입니다. 화면 판독기 사용자의 2/3는 화면 판독기 출력으로 음성을 선택하고 화면 판독기 사용자의 1/3은 점자를 선택합니다.

스크린 리더는 워드 프로세서, 이메일 클라이언트 및 웹 브라우저와 같은 프로그램과 함께 사용할 수 있습니다. 애플리케이션의 콘텐츠와 인터페이스를 화면 판독기가 읽을 수 있는 접근성 트리에 매핑하여 작동합니다. 일부 화면 판독기는 특정 프로그램을 트리에 수동으로 매핑해야 하는 반면, 다른 화면 판독기는 더 일반적이고 대부분의 프로그램에서 작동해야 합니다.

Windows에서 가장 인기 있는 스크린 리더는 전체 스크린 리더 시장의 거의 절반을 차지하는 JAWS입니다. 가정용 버전의 경우 약 1,000달러의 비용이 드는 상용 소프트웨어입니다. Windows용 오픈 소스 대안은 NVDA로, 데스크톱의 모든 스크린 리더 사용자 중 3분의 1 미만이 사용합니다.

Microsoft Narrator , System Access , Window-Eyes 및 ZoomText (전체 화면 판독기가 아니라 읽기 기능이 있는 화면 돋보기)를 포함한 다른 대안이 있습니다. 이들의 합은 스크린 리더 사용량의 약 6%에 해당합니다. Linux에서 Orca는 기본적으로 여러 배포판에 번들로 제공됩니다.

macOS, iOS 및 tvOS에 번들로 제공되는 스크린 리더는 VoiceOver 입니다. VoiceOver는 데스크톱 스크린 리더 사용자의 11.7%를 구성하고 모바일에서 스크린 리더 사용자의 69%로 증가합니다. 모바일 공간의 다른 주요 스크린 리더는 Android의 Talkback (29.5%)과 Samsung의 Voice Assistant (5.2%)로, 자체적으로 Talkback을 기반으로 하지만 추가 제스처가 있습니다.

저는 MacBook과 iPhone이 있으므로 이 기사에서는 VoiceOver와 Safari를 사용할 것입니다. Safari는 VoiceOver와 함께 사용하는 것이 권장되는 브라우저입니다. 둘 다 Apple에서 유지 관리하고 함께 잘 작동해야 하기 때문입니다. 다른 브라우저에서 VoiceOver를 사용하면 예기치 않은 동작이 발생할 수 있습니다.

스크린 리더를 활성화하고 사용하는 방법

내 지침은 VoiceOver에 대한 것이지만 선택한 스크린 리더에 해당하는 명령이 있어야 합니다.

데스크탑의 VoiceOver

이전에 스크린 리더를 사용한 적이 없다면 벅찬 경험이 될 수 있습니다. 청각 전용 경험에 가는 것은 큰 문화 충격이며, 소음의 맹공격을 제어하는 ​​방법을 모른다는 것은 불안합니다. 이러한 이유로 가장 먼저 배우고 싶은 것은 끄는 방법입니다.

VoiceOver를 끄는 단축키는 켜는 단축키와 동일합니다. ⌘ + F5 ( ⌘ 는 Cmd 키라고도 함). 터치 바가 있는 최신 Mac에서 단축키는 Command 키를 누른 상태에서 Touch ID 버튼을 세 번 누르는 것입니다. VoiceOver가 너무 빨리 말합니까? VoiceOver 유틸리티를 열고 '음성' 탭을 누르고 그에 따라 속도를 조정하십시오.

켜고 끄는 데 숙달되면 "VoiceOver 키"(실제로는 동시에 두 개의 키를 눌림): Ctrl 및 ⌥ (후자의 키는 "Option"이라고도 함) 사용 방법을 배워야 합니다. " 또는 Alt 키). VO 키를 다른 키와 함께 사용하여 웹을 탐색할 수 있습니다.

예를 들어, VO + A 를 사용하여 현재 위치에서 웹 페이지를 읽을 수 있습니다. 실제로는 Ctrl + ⌥ + A 를 누른 상태를 의미합니다. VO 가 무엇에 해당하는지 기억하는 것은 처음에는 혼동되지만 VO 표기법은 간결함과 일관성을 위한 것입니다. VO 키를 다른 것으로 구성하는 것이 가능하므로 모든 사람이 따를 수 있는 표준 표기법을 갖는 것이 합리적입니다.

VO 및 화살표 키( VO + → 및 VO + ← )를 사용하여 DOM의 각 요소를 순서대로 이동할 수 있습니다. 링크를 발견하면 VO + Space 를 사용하여 클릭할 수 있습니다. 이 키를 사용하여 양식 요소와도 상호 작용할 수 있습니다.

후자! 이제 웹을 탐색하기에 VoiceOver에 대해 충분히 알게 되었습니다.

모바일에서 보이스오버

VoiceOver를 켜는 모바일/태블릿 단축키는 기기에 따라 다르지만 일반적으로 홈 버튼을 '세 번 클릭'합니다(설정에서 단축키 활성화 후).

Two-Finger Swipe Down 명령을 사용하여 현재 위치에서 모든 것을 읽을 수 있으며 Swipe Right or Left 으로 DOM의 각 요소를 순서대로 선택할 수 있습니다.

이제 데스크톱만큼 iOS VoiceOver에 대해 많이 알게 되었습니다!

콘텐츠 유형별 탐색

웹을 시각 사용자로 사용하는 방법에 대해 생각해 보십시오. 모든 단어를 위에서 아래로 순서대로 주의 깊게 읽습니까? 아닙니다. 인간은 원래 게으르게 설계되어 있으며 가능한 한 빨리 흥미로운 정보를 찾기 위해 페이지를 '스캔'하는 법을 배웠습니다.

스크린 리더 사용자는 효율성에 대한 동일한 요구 사항이 있으므로 대부분은 제목, 링크 또는 양식 컨트롤과 같은 콘텐츠 유형별로 페이지를 탐색합니다. 이를 수행하는 한 가지 방법은 VO + U 를 사용하여 바로 가기 메뉴를 열고 ← 및 → 화살표 키로 원하는 콘텐츠 유형으로 이동한 다음 ↑↓ 키로 해당 요소를 탐색하는 것입니다.

이를 수행하는 또 다른 방법은 '빠른 탐색'을 활성화하는 것입니다( ← 와 → 를 동시에 눌러). 빠른 탐색이 활성화되면 ← 또는 → 옆에 ↑ 화살표를 눌러 콘텐츠 유형을 선택할 수 있습니다. iOS에서는 Two-Finger Rotate 이 작업을 수행합니다.

콘텐츠 유형을 선택했으면 ↑↓ 키(iOS에서는 Swipe Up or Down )를 사용하여 각 로터 항목을 건너뛸 수 있습니다. 기억해야 할 것이 많다면 이 매우 편리한 VoiceOver 치트시트를 참조용으로 북마크에 추가할 가치가 있습니다.

콘텐츠 유형을 통해 탐색하는 세 번째 방법은 트랙패드 제스처를 사용하는 것입니다. 이는 iPad/iPhone의 iOS에서 VoiceOver를 사용하는 방법에 더 가까운 경험을 제공합니다. 즉, 한 세트의 스크린 리더 명령만 기억해야 합니다!

OSX에 내장된 교육 프로그램에서 제스처 기반 탐색 및 기타 여러 VoiceOver 기술을 연습할 수 있습니다. 시스템 환경설정 → 접근성 → VoiceOver → VoiceOver 교육 열기를 통해 접근할 수 있습니다.

튜토리얼을 마친 후, 나는 갈 의향이 없었습니다!

사례 연구 1: YouTube

YouTube에서 검색

Safari 도구 모음에서 YouTube 홈페이지로 이동했는데 여기에서 VoiceOver는 Ctrl + ⌥ + Shift + ↓ 를 사용하여 웹 콘텐츠에 "들어가십시오"라고 말했습니다. 포함된 콘텐츠와 일부 양식 컨트롤에 동일한 메커니즘이 적용되기 때문에 곧 웹 콘텐츠를 시작하는 데 익숙해질 것입니다.

Quick Nav를 사용하여 양식 컨트롤을 통해 탐색하여 페이지 상단의 검색 섹션으로 쉽게 건너뛸 수 있었습니다.

다음과 같은 양질의 콘텐츠를 검색했습니다.

그리고 검색 버튼으로 이동했습니다.

그러나 VO + Space 로 버튼을 활성화했을 때 아무 것도 발표되지 않았습니다.

눈을 뜨니 검색이 되었고 페이지는 결과로 채워졌지만 오디오만으로는 알 길이 없었습니다.

의아해하며 devtools를 연 상태에서 내 작업을 재현하고 네트워크 탭을 주시했습니다.

예상대로 YouTube는 "클라이언트 측 렌더링"이라는 성능 기술을 사용하고 있습니다. 즉, JavaScript가 전체 페이지를 다시 칠할 필요가 없도록 양식 제출을 가로채서 검색 결과를 제자리에 렌더링합니다. 검색 결과가 일반 링크처럼 새 페이지에 로드되었다면 VoiceOver가 내가 탐색할 새 페이지를 발표했을 것입니다.

클라이언트 렌더링 응용 프로그램에 대한 액세스 가능성에 대한 전체 기사가 있습니다. 이 경우 YouTube에서 검색 제출이 성공했을 때 알리는 aria-live 지역을 구현하는 것이 좋습니다.

팁 #1: DOM에 대한 클라이언트 측 변경 사항을 알리기 위해 aria-live 영역을 사용하십시오.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

이제 속임수를 쓰고 검색 결과를 볼 수 있다는 것을 알았으므로 눈을 감고 Quick Nav의 "제목" 모드로 전환한 다음 결과를 단계별로 살펴보고 결과의 첫 번째 비디오로 이동했습니다.

YouTube에서 비디오 재생

YouTube 동영상 페이지를 로드하는 즉시 동영상이 자동 재생됩니다. 이것은 내가 일상적인 사용에서 가치 있게 생각하는 것이지만, VoiceOver가 그것에 대해 말하는 것과 혼합될 때 고통스러운 경험이었습니다. 후속 동영상의 자동 재생을 비활성화하는 방법을 찾지 못했습니다. 내가 할 수 있는 일은 다음 비디오를 로드하고 CTRL 을 빠르게 눌러 스크린 리더 발표를 중지하는 것뿐이었습니다.

팁 #2: 항상 자동 재생을 억제하는 방법을 제공하고 사용자의 선택을 기억하십시오.

비디오 자체는 상호 작용하기 위해 들어가야 하는 "그룹"으로 취급됩니다. 비디오 플레이어의 각 옵션을 탐색할 수 있었는데, 매우 놀랐습니다. Flash 시대에는 그랬는지 의심스럽습니다!

그러나 플레이어의 일부 컨트롤에는 레이블이 없었기 때문에 '시네마 모드'는 단순히 "버튼"으로 읽혀졌습니다.

팁 #3: 항상 양식 컨트롤에 레이블을 지정하십시오.

스크린 리더 사용자는 대부분 시각 장애인이지만 약 20%는 "저시력"으로 분류되어 페이지의 일부를 볼 수 있습니다. 따라서 스크린 리더 사용자는 여전히 "시네마 모드"를 활성화할 수 있다는 사실에 감사할 수 있습니다.

이 팁은 중요도 순으로 나열되어 있지 않지만 만약 그렇다면 이것이 제 1순위가 될 것입니다.

팁 #4: 스크린 리더 사용자는 시력 사용자와 기능적으로 동등해야 합니다.

"시네마 모드" 옵션에 레이블을 지정하지 않음으로써 스크린 리더 사용자가 다른 방법으로 사용할 수 있는 기능에서 제외됩니다.

즉, 화면 판독기에 기능 을 적용할 수 없는 경우가 있습니다. 예를 들어, 문맥 없는 숫자의 도깨비처럼 읽히는 상세한 SVG 꺾은선형 차트가 있습니다. 이와 같은 경우 요소에 특수 aria-hidden="true" 속성을 적용하여 화면 판독기에서 모두 무시하도록 할 수 있습니다. 대체 텍스트나 데이터 테이블을 대체 수단으로 제공해야 한다는 점에 유의하십시오.

팁 #5: 스크린 리더 사용자에게 적용되지 않는 콘텐츠를 숨기려면 aria-hidden 을 사용하세요.

일부 콘텐츠를 되감기 위해 재생 위치를 조정하는 방법을 알아내는 데 오랜 시간이 걸렸습니다. 슬라이더( VO + Shift + ↓ )로 "들어가면" ⌥ + ↑↓ 를 눌러 조정합니다. 나에게는 직관적이지 않은 것처럼 보이지만 Apple이 논란의 여지가 있는 키보드 단축키 결정을 내린 것은 이번이 처음이 아닙니다.

YouTube 비디오 끝에서 자동 재생

비디오가 끝나면 자동으로 새 비디오로 리디렉션되어 혼란스러웠습니다. 아무 발표도 없었습니다.

나는 곧 자동 재생 컨트롤로 이동하여 비활성화하는 방법을 배웠습니다.

이것은 비디오 페이지를 로드할 때 비디오가 자동 재생되는 것을 방지하지 않지만 해당 비디오 페이지가 다음 비디오로 자동 리디렉션되는 것을 방지합니다.

사례 연구 2: BBC

뉴스는 특정한 것을 찾는 것보다 수동적으로 소비되는 것이기 때문에 나는 BBC 뉴스를 제목으로 탐색하기로 결정했습니다. 이를 위해 빠른 탐색을 사용할 필요가 없다는 점은 주목할 가치가 있습니다. VoiceOver는 고급 사용자의 시간을 절약할 수 있는 요소 검색 명령을 제공합니다. 이 경우 VO + ⌘ + H 키를 사용하여 제목을 탐색할 수 있습니다.

첫 번째 제목은 쿠키 알림이었고 두 번째 제목은 '접근성 링크'라는 제목의 <h2> 였습니다. 두 번째 제목 아래에 있는 첫 번째 링크는 "콘텐츠로 건너뛰기" 링크로 다른 모든 탐색 항목을 건너뛸 수 있었습니다.

'콘텐츠로 건너뛰기' 링크는 스크린 리더 사용자뿐만 아니라 매우 유용합니다. 이전 기사 "나는 하루 동안 키보드만 사용하여 웹을 사용했습니다"를 참조하십시오.

팁 #6: 키보드 및 스크린 리더 사용자를 위해 '콘텐츠로 건너뛰기' 링크를 제공하세요.

제목으로 탐색하는 것은 좋은 접근 방식이었습니다. 각 뉴스 항목에는 고유한 제목이 있으므로 주어진 기사에 대해 더 읽을지 여부를 결정하기 전에 헤드라인을 들을 수 있습니다. 그리고 제목 자체가 앵커 태그 안에 래핑되어 있기 때문에 클릭하고 싶을 때 탐색 모드를 전환할 필요조차 없었습니다. 현재 기사 선택 항목을 로드하려면 VO + Space 만 사용할 수 있습니다.

홈페이지 콘텐츠로 건너뛰기 바로 가기가 #skip-to-content-link-target 앵커(그런 다음 주요 뉴스 헤드라인을 읽음)에 멋지게 링크된 반면, 기사 페이지 건너뛰기 링크는 깨졌습니다. 다른 ID( #page )로 연결되어 헤드라인을 읽는 대신 기사 내용을 둘러싼 group 으로 이동했습니다.

이 시점에서 VO + A 를 눌러 VoiceOver가 전체 기사를 읽어주도록 했습니다.

트위터 임베딩에 도달할 때까지 꽤 잘 대처했으며, 여기서 상당히 장황해지기 시작했습니다. 어느 순간 "링크: 1068987739478130688"이라고 읽히지 않았습니다.

이것은 트윗의 비디오 임베드 부분에 있는 약간 이상한 마크업으로 보입니다.

VoiceOver는 중첩된 이미지의 alt 속성을 읽지 않고 앵커 내부에 다른 텍스트가 없기 때문에 VoiceOver는 URL 자체의 일부를 읽는 방법을 알고 있는 가장 유용한 작업을 수행합니다.

다른 스크린 리더는 이 마크업으로 잘 작동할 수 있습니다. 마일리지는 다를 수 있습니다. 그러나 더 안전한 구현은 aria-label 이 있는 앵커 태그 또는 대체 텍스트를 전달하기 위해 화면 밖에 시각적으로 숨겨진 텍스트가 될 것입니다. 여기 있는 동안 "포함된 비디오"를 좀 더 유용한 것으로 변경할 수 있습니다(예: "포함된 비디오: 재생하려면 클릭").

링크 문제는 거기에 있지 않았습니다.

주요 트윗 콘텐츠 아래에는 '좋아요' 카운터 역할을 하는 '좋아요' 버튼이 있습니다. 시각적으로는 이해가 되지만 스크린 리더의 관점에서 볼 때 여기에는 컨텍스트가 없습니다. 이 스크린 리더 환경은 다음 두 가지 이유로 좋지 않습니다.

1. "1,887"이 무엇을 의미하는지 모르겠습니다.
2. 링크를 클릭하면 트윗에 좋아요가 표시될지 모르겠습니다.

스크린 리더 사용자는 "1,887명의 사용자가 이 트윗을 좋아했습니다. 좋아요를 눌러주세요.” 이것은 약간의 사려 깊은 오프 스크린 텍스트로 달성할 수 있습니다.

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

팁 #7: 개별적으로 읽을 때 모든 링크가 의미가 있는지 확인하십시오.

나는 BBC에서 '긴 형식' 특집 기사를 포함하여 몇 가지 기사를 더 읽었습니다.

더 긴 기사 읽기

다른 BBC 장편 기사의 다음 스크린샷을 보십시오. 얼마나 많은 다른 이미지를 볼 수 있으며, alt 속성은 무엇이어야 합니까?

먼저 사진 중앙에 있는 하바수 호수 전경을 보겠습니다. 그 아래에 "Lake Havasu는 1938년에 Parker 댐이 완공된 후 만들어졌으며, 이 댐은 콜로라도 강을 막았습니다."

캡션이 제공된 경우에도 alt 속성을 제공하는 것이 가장 좋습니다. alt 텍스트는 이미지를 설명해야 하고 캡션은 컨텍스트를 제공해야 합니다. 이 경우 alt 속성은 "화창한 날에 Havasu 호수의 조감도"와 같을 수 있습니다.

alt 텍스트에 “Image: ” 또는 “Picture of” 또는 이와 유사한 접두사를 붙이면 안 됩니다. 스크린 리더는 이미 alt 텍스트 앞에 "이미지"라는 단어를 표시하여 해당 컨텍스트를 제공합니다. 또한 alt 텍스트를 짧게(16단어 미만) 유지하십시오. 더 긴 alt 텍스트가 필요한 경우(예: 이미지에 복사해야 할 텍스트가 많이 포함되어 있는 경우) longdesc 속성을 살펴보십시오.

팁 #8: 설명적이지만 효율적인 alt 텍스트를 작성하십시오.

의미적으로 스크린샷 예제는 <figure> 및 <figcaption> 요소로 마크업되어야 합니다.

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

이제 해당 스크린샷의 배경 이미지(다양한 술잔 및 장비를 전달하는 이미지)를 살펴보겠습니다. 일반적으로 이와 같은 배경 또는 프리젠테이션 이미지에는 대체 텍스트가 없다는 것을 명시적으로 알리고 이를 읽으려고 시도하지 않도록 VoiceOver에 빈 alt 속성( alt="" )이 있어야 합니다.

비어 있는 alt="" 는 alt 속성이 없는 것과 같지 않으며, 이는 절대 금물입니다. alt 속성이 없으면 스크린 리더가 대신 이미지 파일 이름을 읽어주는데, 이는 그다지 유용하지 않은 경우가 많습니다!

팁 #9: 프레젠테이션 콘텐츠에 빈 alt 속성을 사용하는 것을 두려워하지 마십시오.

사례 연구 3: 페이스북

지금 페이스북에 가보니 예전부터 금단증상이 있어서 좀 더 비실용적인 조커 를 찾아봤습니다.

Facebook은 내가 지금까지 시도한 다른 사이트보다 한두 단계 더 발전했으며 '콘텐츠로 건너뛰기' 링크 대신 각각 페이지 또는 페이지 섹션으로 연결되는 2개 이상의 드롭다운이 있습니다.

Facebook은 또한 페이지의 어느 곳에서나 사용할 수 있는 바로 가기 키로 여러 키를 정의합니다.

나는 이것들을 가지고 놀았고 VoiceOver와 아주 잘 작동합니다. 일단 그들이 있다는 것을 알게 되면. 내가 볼 수있는 유일한 문제는 그들이 독점적이라는 것입니다 (이러한 바로 가기가 Facebook 외부에서 작동 할 것으로 기대할 수는 없습니다). 그러나 Facebook이 여기에서 정말 열심히 노력하고 있다는 것은 좋은 일입니다.

Facebook 접근성에 대한 첫인상은 좋았지만 곧 사이트를 탐색하기 어렵게 만드는 약간의 이상한 점을 발견했습니다.

예를 들어, 제목을 통해 이 페이지를 탐색하려고 할 때 매우 혼란스러워했습니다.

페이지의 맨 처음 제목은 제목 수준 3으로 사이드바에 숨겨져 있습니다. 바로 다음에는 페이지에서 공유한 상태에 해당하는 기본 콘텐츠 열의 제목 수준 6이 옵니다.

이것은 Chrome/Firefox용 웹 개발자 플러그인으로 시각화할 수 있습니다.

일반적으로 1보다 크지 않은 차이가 있는 순차 표제를 사용하는 것이 좋습니다. 그렇지 않은 경우 거래 차단기는 아니지만 스크린 리더의 관점에서 접근하는 것은 확실히 혼란스럽습니다. h1 에서 h6 으로 점프했기 때문에 실수로 중요한 정보를 건너뛰었습니다.

팁 #10: 제목 구조를 확인하십시오.

이제 웹사이트의 핵심인 게시물로 이동합니다. Facebook은 사람들과 계속 연락하고 그들이 무엇을 하는지 확인하는 것입니다. 그러나 우리는 alt 텍스트가 대부분의 사용자에게 알려지지 않은 개념인 세상에 살고 있습니다. 그렇다면 Facebook은 어떻게 그 뻔뻔한 셀카와 강아지 사진을 스크린 리더 청중에게 번역할까요?

Facebook에는 개체 인식 기술을 사용하여 사진에 무엇이(또는 누구)가 있는지 분석하고 이에 대한 텍스트 설명을 생성하는 자동 대체 텍스트 생성기가 있습니다. 얼마나 잘 작동합니까?

이 이미지의 alt 텍스트는 "이미지에 다음이 포함될 수 있음: 하늘, 잔디 및 야외"였습니다. '해질녘의 케임브리지 대성당'을 알아보기에는 한참 멀었지만 올바른 방향으로 나아가는 단계임은 분명합니다.

나는 일부 설명의 정확성에 놀라울 정도로 감명을 받았습니다. 내가 시도한 또 다른 이미지는 "이미지에 다음이 포함될 수 있음: John Smith, Jane Doe 및 Chris Ashton을 포함한 3명, 웃고 있는 사람들, 근접 촬영 및 실내"로 나왔습니다. 매우 설명적이고 절대적으로 맞습니다!

그러나 소셜 미디어에서 널리 퍼진 밈과 농담은 본질적으로 액세스할 수 없다는 점이 마음에 걸립니다. Facebook은 다음을 "이미지에 다음을 포함할 수 있음: 새 및 텍스트"로 취급합니다. 이는 사실이지만 실제 묘사와는 거리가 멉니다!

운 좋게도 사용자는 원하는 경우 자신의 alt 텍스트를 작성할 수 있습니다.

사례 연구 4: 아마존

내가 Facebook에서 발견한 일이 Amazon에서도 발생합니다. DOM에서 검색 입력 필드 앞에 검색 버튼이 나타납니다. 버튼이 입력 필드 뒤에 시각적으로 표시된다는 사실에도 불구하고 말입니다.

귀하의 웹사이트는 시각적으로 논리적인 순서일 수 있습니다. 누군가 무작위로 웹페이지의 일부를 이동하면 어떻게 될까요? 계속해서 말이 될까요?

아마 아닐 것입니다. DOM 구조를 시각적 디자인과 동기화하는 것에 대해 훈련을 받지 않으면 스크린 리더 경험에 이런 일이 발생할 수 있습니다. 때로는 CSS로 콘텐츠를 이동하는 것이 더 쉽지만 일반적으로 DOM에서 콘텐츠를 이동하는 것이 더 좋습니다.

팁 #11: DOM 순서를 시각적 순서와 일치시키십시오.

이 두 유명 사이트가 검색 탐색과 함께 이 모범 사례 지침을 채택하지 않기로 선택한 이유는 저를 당황하게 합니다. 그러나 버튼과 입력 텍스트가 너무 멀리 떨어져 있지 않아 순서가 큰 접근성 문제를 야기합니다.

아마존의 표제

다시 말하지만, Facebook과 마찬가지로 Amazon에는 이상한 제목 순서가 있습니다. 제목을 통해 검색했는데 페이지의 첫 번째 제목이 "아마존의 기타 판매자" 섹션의 제목 수준 5라는 것이 가장 혼란스러웠습니다.

나는 이것이 스크린 리더의 버그임에 틀림없다고 생각하여 확인하기 위해 Amazon의 소스 코드를 파헤쳤습니다.

페이지의 h1은 소스 코드에서 거의 10,000줄 아래 에 나타납니다.

이것은 의미상 열악하고 접근성이 열악할 뿐만 아니라 SEO에도 열악합니다. 열악한 SEO는 더 적은 전환(판매)을 의미합니다. Amazon이 가장 중요하게 생각하는 것입니다!

팁 #12: 접근성과 SEO는 동전의 양면입니다.

스크린 리더 경험을 개선하기 위해 우리가 하는 많은 일들이 SEO도 개선할 것입니다. 의미적으로 유효한 표제와 자세한 alt 텍스트는 검색 엔진 크롤러에 적합합니다. 이는 귀하의 사이트가 검색에서 더 높은 순위를 차지함을 의미하며, 이는 더 많은 청중을 확보할 수 있음을 의미합니다.

접근 가능한 사이트를 만드는 것이 중요하다고 비즈니스 관리자를 설득하는 데 어려움을 겪고 있다면 다른 각도에서 시도하고 대신 SEO의 이점을 지적하세요.

여러 가지 잡다한

하루의 탐색과 경험을 하나의 기사로 압축하기는 어렵습니다. 다음은 컷을 만든 몇 가지 하이라이트와 하이라이트입니다.

느린 사이트를 알 수 있습니다.

화면 판독기는 DOM이 로드될 때까지 페이지를 구문 분석하고 접근성 트리를 만들 수 없습니다. 시력이 있는 사용자는 로드되는 동안 페이지를 스캔하여 가치가 있는지 빠르게 판단하고 그렇지 않은 경우 뒤로 버튼을 누를 수 있습니다. 스크린 리더 사용자는 페이지가 100% 로드될 때까지 기다릴 수 밖에 없습니다.

성능 좋은 웹사이트를 만드는 것이 모두에게 도움이 되지만 특히 스크린 리더 사용자에게 유익하다는 점은 흥미롭습니다.

나는 무엇에 동의합니까?

NatWest의 이와 같은 양식 컨트롤은 관계를 표시하기 위해 공간적 근접성에 크게 의존할 수 있습니다. 스크린 리더의 세계에는 형제 자매와 부모만 있을 뿐 특별한 친밀감이 없습니다. 그리고 '예'에 체크 표시를 하려면 추측이 필요합니다.

면책 조항이 레이블의 일부였다면 내가 동의한 내용을 알았을 것입니다.

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

다음 코드는 악몽입니다

스크린 리더를 사용하여 CSS Tricks에 대한 기술 기사를 읽으려고 했지만 솔직히 말해서, 그 경험을 따라가기가 완전히 불가능하다는 것을 알게 되었습니다. 이것은 CSS Tricks 웹사이트의 잘못이 아닙니다. 기술적 아이디어와 코드 샘플을 완전히 청각적으로 설명하는 것은 엄청나게 복잡하다고 생각합니다. 몇 번이나 파트너와 디버깅을 시도하고 필요한 정확한 구문을 설명하는 대신 복사하여 붙여넣을 무언가를 제공하거나 직접 작성합니까?

기사에서 이 코드 샘플을 얼마나 쉽게 읽을 수 있는지 보십시오.

그러나 다음은 스크린 리더 버전입니다.

슬래시 슬래시 먼저 뷰포트 높이를 구하고 vh 단위에 대한 값을 얻기 위해 1 [일시 중지] 퍼센트를 곱합니다. ] vh 사용자 정의 속성을 문서 문서의 루트 문서 문서 요소 스타일 설정 속성 [일시 중지] vh 달러 왼쪽 중괄호 vh 오른쪽 중괄호 px

사운드 스케이프에서 완전히 읽을 수 없습니다. 우리는 주석에 구두점을 사용하지 않는 경향이 있으며, 이 경우 스크린 리더 영역에서 한 줄이 매끄럽게 다음 줄로 이어집니다. camelCase 텍스트는 마치 문장에 쓰여진 것처럼 별도의 단어로 읽혀집니다. window.innerHeight 와 같은 마침표는 무시되고 "창 내부 높이"로 처리됩니다. 읽을 수 있는 유일한 '코드'는 끝에 있는 중괄호입니다.

코드는 표준 <pre> 및 <code> HTML 요소를 사용하여 마크업되므로 스크린 리더 사용자를 위해 이것이 어떻게 개선될 수 있는지 모르겠습니다. 코딩을 꾸준히 하는 사람이라면 누구나 존경할 만합니다.

그렇지 않으면 내가 찾을 수있는 유일한 결함은 사이트 로고에 홈페이지에 대한 링크가 있지만 alt 텍스트가 없어서 "링크 : 슬래시"만 들었습니다. href="/" 속성이 있는 링크가 있으면 웹사이트 홈페이지로 이동하므로 링크가 무엇을 위한 것인지 알아냈습니다. 하지만 "링크: CSS Tricks 홈페이지"가 ​​더 좋았을 것입니다!

iOS의 VoiceOver는 OSX보다 까다롭습니다

내 전화에서 VoiceOver를 사용하는 것은 경험이었습니다!

나는 트위터 앱을 탐색하고 화면을 끄고 모바일 키보드를 사용하여 트윗을 작성하는 도전을 받았습니다. 생각보다 어려웠고 맞춤법 실수도 많이 했습니다.

내가 일반 스크린 리더 사용자라면 외장 키보드를 사용하고 블루투스 키보드에 투자하는 모바일 스크린 리더 사용자의 41%에 합류해야 한다고 생각합니다. Clara Van Gerven은 2015년 40일 동안 스크린 리더를 사용했을 때 동일한 결론에 도달했습니다.

세 손가락으로 세 번 탭하여 스크린 커튼 모드를 활성화하는 것은 꽤 멋졌습니다. 이렇게 하면 화면은 꺼지지만 휴대전화는 잠금 해제 상태로 유지되어 아무도 보지 않고 계속 휴대전화를 탐색할 수 있었습니다. 이 기능은 자신도 모르게 자신의 암호를 옆에서 지켜보고 있는 시각 장애인 사용자에게 필수적이지만 배터리를 절약할 수 있다는 부수적인 이점도 있습니다.

요약

이것은 흥미롭고 도전적인 경험이었고 지금까지 쓴 시리즈 중 가장 어려운 기사였습니다.

나는 당신이 멈추고 그것에 대해 생각할 때 명백한 작은 것들에 놀랐습니다. 예를 들어, 스크린 리더를 사용할 때 웹 검색과 동시에 음악을 듣는 것은 거의 불가능합니다! 페이지의 컨텍스트를 유지하는 것도 어려울 수 있습니다. 특히 전화 통화 등으로 인해 방해를 받는 경우에는 더욱 그렇습니다. 스크린 리더로 돌아갈 때쯤이면 어느 정도 자리를 잃게 됩니다.

내 가장 큰 교훈은 오디오 전용 경험에 가는 데 큰 문화적 충격이 있다는 것입니다. 그것은 웹을 탐색하는 완전히 다른 방식이며, 그러한 대조가 있기 때문에 '좋은' 또는 '나쁜' 스크린 리더 경험을 구성하는 것이 무엇인지조차 알기 어렵습니다. 상당히 압도적일 수 있으며 많은 개발자가 테스트를 피하는 것도 당연합니다.

하지만 어렵다고 해서 피해서는 안 됩니다. Charlie Owen이 그녀의 강연에서 말했듯이, Dear Developer, Web은 당신에 관한 것이 아닙니다 : 이것입니다. 이다. 당신의. 직업 . Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.