스포일러 블러가 스크린 리더와 호환되지 않음에서 이어지는 토론입니다:
VoiceOver 사용자로부터 새로운 스포일러 코드가 작동하지 않는다는 보고를 받았습니다:
스크린 리더를 사용하는 다른 분들 중 포럼의 업데이트된 스포일러 기능으로 인해 어려움을 겪고 계신 분이 계신가요? 적어도 업데이트가 있었을 거라고 추정합니다. 이전에는 스포일러 텍스트가 아무런 표시 없이 정상적으로 읽혔는데, 이는 물론 이상한 상황이었습니다. 이번 업데이트는 내용을 접을 수 있는 영역 뒤에 배치하고 "숨겨진 내용 보기"라고 라벨을 붙임으로써 이 문제를 해결한 것으로 보입니다. 하지만 어떤 이유인지 버튼을 눌러 확장/공개할 때 텍스트가 인식되지 않습니다. 참고로 저는 Apple의 기본 스크린 리더인 VoiceOver를 사용 중이며, iOS와 Mac OS 양쪽에서 이 문제를 확인했습니다.
다른 누군가는 이렇게 말했습니다.
Windows에서 NVDA를 사용할 때 동일한 문제가 발생합니다.
세 번째 사람도 이에 동의했습니다.
죄송하지만, 현재 코드가 제대로 작동하지 않는 것 같습니다. 오히려 기존 코드로 되돌리는 것이 더 나을 수도 있습니다.
포럼을 업그레이드했지만, 스크린리더 사용자는 아무 변화가 없다고 보고하고 있습니다.
플러그인이 최신 버전으로 업그레이드되었는지 확인하셨나요? (커밋 0ee68da)
저는 Meta에서 VoiceOver와 함께 잘 작동하는 것을 확인했습니다. 또한 이 기능을 위해 aria-live를 polite로 설정하고 있어, 스크린 리더가 너무 공격적이거나 방해가 되지 않습니다. 대신 사용자가 유휴 상태가 될 때까지 기다렸다가 내용을 읽어줍니다.
이것을 테스트하면 읽혀집니다
네, 스포일러 플러그인은 0ee68da1에 있습니다.
Keegan, 이 테스트를 어떻게 진행 중인지 조금 더 자세히 설명해 주실 수 있나요? 첨부된 스크린샷은 데스크톱 브라우저로 보입니다. macOS VoiceOver를 사용 중이신가요? (어떤 브라우저에서 사용 중이신가요?)
macOS VoiceOver는 iOS VoiceOver와 매우 다른 제품입니다. macOS VoiceOver에만 있고 iOS VoiceOver에는 없는 버그가 있는 경우가 흔하며, 그 반대도 마찬가지입니다. (여러 가지 이유로 인해 시각 장애 사용자 사이에서는 iOS VoiceOver가 macOS VoiceOver보다 훨씬 더 널리 사용됩니다.)
방금 iOS Safari 16.3.1에서 Keegan의 게시글 https://meta.discourse.org/t/spoiler-issues-with-voiceover/257450/8?u=dfabulich을 테스트해 보았을 때, 다음과 같은 상황이 확인되었습니다:
다음은 영상 자막입니다:
intfiction.org 포럼의 사용자들로부터 NVDA에서도 스포일러 흐림 처리가 제대로 작동하지 않는다는 보고를 받고 있습니다. 이 부분도 귀하 측에서 테스트해 볼 가치가 있을 수 있습니다.
Hey @dfabulich, 세부 정보를 공유해 주셔서 감사합니다. 네, 주로 Chrome에서 테스트를 진행했습니다 (macOS VoiceOver 및 Windows 11 내레이션).
iOS, NVDA 및 기타 주요 기기에서 문제를 해결하는 패치를 조속히 배포할 수 있도록 추가 조사와 테스트를 진행해 보겠습니다.
감사합니다!
네, 그 둘 모두 인기가 없는 스크린 리더이므로, 테스트를 위한 주요 플랫폼으로 사용해서는 안 됩니다.
다음은 WebAIM에서 실시한 스크린 리더 사용자 대상 주요 산업 설문조사입니다.
https://webaim.org/projects/screenreadersurvey9/ (이 설문조사는 몇 년에 한 번씩 다시 진행되며, 이 결과는 2021년 것입니다)
이 설문조사를 주의 깊게 읽어야 합니다. 왜냐하면 먼저 데스크톱 브라우저에 대해 다루고 있으며, “Primary Screen Reader” https://webaim.org/projects/screenreadersurvey9/#primary라는 차트가 있지만, 이는 특정하게 "데스크톱/노트북"용 주요 스크린 리더를 가리키고 있기 때문입니다.
해당 차트에 따르면 "VoiceOver"는 인기가 많지 않은 것으로 보이지만, 그 섹션에서는 macOS VoiceOver를 가리키고 있습니다. (“Operating Systems” 섹션으로 스크롤을 내리면, macOS 자체가 스크린 리더 사용자들 사이에서 매우 인기가 많지 않다는 것을 볼 수 있습니다.)
Windows용 JAWS가 선두를 달리고 있으며, 그 뒤를 Windows용 NVDA가 잇고 있습니다. macOS VoiceOver는 멀찌감치 3위입니다. Windows 내비게이터(Narrator)의 사용률은 0.5%에 불과합니다!
JAWS는 비용을 수반하며(그 라이선스 체계도 까다롭습니다), NVDA는 무료라는 점에 유의하십시오. 또한 NVDA는 JAWS보다 버그가 더 많은 경향이 있습니다. 제 경험상, NVDA에서 동작하는 것은 JAWS에서도 항상 동작합니다.
나중에 “Mobile Screen Readers Used” https://webaim.org/projects/screenreadersurvey9/#mobilescreenreaders에 대해 다루고 있습니다.
해당 차트에서는 OS 내장 스크린 리더가 지배적인 것으로 나타나며, iOS VoiceOver(71.5%)와 Android TalkBack(29.1%)입니다. (일부 사용자가 둘 다 사용하기 때문에 이 비율의 합이 100%를 초과합니다.)
이 설문조사에 빠져 있는 것은 "모바일 사용 시간 대 데스크톱 사용 시간"에 대한 조사입니다. 하지만 제 경험상, 스크린 리더 사용자들로부터 듣는 버그 보고의 대다수는 iOS 사용자와 NVDA 사용자들로부터 나옵니다.
따라서 저는 다음과 같은 우선순위 순서로 테스트할 것을 권장합니다:
하지만 iOS Safari VoiceOver에서만 테스트해도 상당한 효과를 볼 수 있을 것입니다. 저는 보통 iOS Safari만 테스트하고, 매우 꼼꼼하게 확인하고 싶을 때 Chrome에서 Windows NVDA를 테스트한 후, 보통 여기서 멈춥니다.
Windows JAWS에서는 발생하지만 Windows NVDA에서는 발생하지 않는 버그를 사용자가 보고한 것을 본 지 최소한 5년은 되었습니다. Android TalkBack에서 버그를 보고한 사용자를 본 적이 거의 없는 것 같습니다.
이 문제에 대해 진전이 있었나요?
aria-live는 토글용으로 설계된 것이 아닙니다. 시작 시 polite로 설정해 두고 계속 켜 두어야 합니다. 기존 구현 방식에서는 활성화 상태 동안 변경 사항이 발생하지 않기 때문에, 변경 사항이 발생했음을 인식할 수 없습니다.
제 경우(NVDA/Windows)의 문제는 외부 div에 aria-label이 있다는 것 같습니다. 대부분의 스크린리더에서는 이것이 콘텐츠의 주석이 아니라 접근할 수 없는 콘텐츠의 대체 텍스트로 취급됩니다. 적어도 제 경우에는 aria-label만 낭독됩니다.
이 스레드의 스포일러에 대한 녹화 영상입니다. 영상 하단의 시간 스크리버를 읽은 후, 빈 구간(무엇인지 모르겠습니다)이 나오고, 그다음에 보이는 스포일러(“버튼 확장됨 콘텐츠 숨김”)와 “2개의 답변” 드롭다운이 낭독됩니다.
참고로 NVDA의 디버그 기능을 사용해 마우스로 확장된 텍스트 위에 올려두면 낭독은 됩니다. 하지만 마우스를 사용하지 않고 텍스트를 낭독하게 하는 방법을 찾지 못했습니다. 따라서 이것이 실제로 접근성이 있는지 테스트하는 유효한 방법이라고 보기 어렵습니다…
접근성 개선을 위한 PR을 만들었습니다:
@Dannii님, PR 올려주셔서 감사합니다 
방금 검토하고 몇 가지 코멘트를 달았어요. 아주 사소한 부분들뿐이지만, 그 외에는 괜찮아 보입니다!
@Dannii 님, 감사합니다. PR이 병합되었습니다 이제 이 문제가 해결되었을 것입니다.