모든 것을 고치다

아직 모르셨다면 your CSS can influence screen readers . 나에게 가장 놀라운 점 중 하나는 ul가 적용될 때 VoiceOver가 ol 및 list-style-type: none에서 목록 의미 체계를 제거한다는 사실을 알게 된 것입니다.

결과적으로 이것은 실제로 의도된 동작입니다.

This [not announcing a list for a groups of links when list-style is set to none] was a purposeful change due to rampant "list"-itis by web developers…Basically, if you remove all default visible indication of the list, there is no indication to a sighted user or screen reader user that the content is a list…

—James Craig, Webkit Bugzilla

이것은 분명히 접근 가능한 기술 사용자를 성가시게 하는 개발자에게 잘못된 것처럼 보일 수 있는 흥미로운 것들 중 하나입니다. James는 이 문제를 해결하는 가장 쉬운 방법은 목록에서 목록 역할을 명시적으로 정의하는 것이라고 말합니다.

<ul role="list">
    <!-- list content here -->
</ul>

불행히도 Scott O'Hara가 그의 fantastic write up on this issue 에서 우리에게 상기시키듯이 first rule of ARIA은 이미 필요한 역할이 있는 기존 HTML 요소가 있을 때 사용하지 않는 것입니다. Scott은 CSS-only fix이 게시하고 Gerard Cohen이 리트윗한 niceSara Soueidan를 언급합니다.

.list li {
    list-style-type: none; /* remove bullets */
}

.list li::before {
    content: "\200B"; /* add zero-width space */
}

하지만 Scott의 기사에서 가장 큰 시사점은 다음과 같은 "버그"를 그대로 두는 것이 가장 좋다는 것입니다.

While this behavior can be unwelcome in some situations, let’s also not spend too much effort over correcting an over correction which was in response to an over use of unnecessary semantics.

VoiceOver 사용자는 기술이 제공하는 단점에 익숙합니다. 일관된 경험을 강요하면 상황이 악화될 수 있습니다. 웹 개발의 다른 모든 것과 마찬가지로 실제 사람들과 테스트해야 합니다.

접근성에 대한 학습 여정을 시작했을 때 저는 코드에서 찾을 수 있는 모든 것을 열정적으로 "고쳤습니다". 일반적으로 마크업을 지나치게 복잡하게 만들고 사람들의 상황을 악화시켰습니다. 더 자주, 단순하게 유지하는 것이 좋습니다.

내가 과거에 어떻게 일을 지나치게 복잡하게 만들었는지에 대해 더 듣고 싶다면 이것을 확인하거나letter to my younger self, 내가 작성한 것으로 알려진 모든 핫 가비지 코드에 대해 물어볼 수 있습니다. 어쩌면 당신은 나의 (많은) 과거 실수로부터 배울 수 있습니다.