문제: 문서 객체 모델(DOM)에서 페이지 초기 로드 시 답변 게시글 요소가 초기에 표시되지 않으며, 스크린 리더가 해당 요소를 지나간 후 DOM에서 제거되어 Windows 스크린 리더의 콘텐츠 접근이 차단되고 VoiceOver의 페이지 접근에 사용할 수 있는 도구가 제한됩니다.
구체적인 동작:
● 메인 게시글에서 답변 게시글로 탐색을 시도할 때, 답변 게시글에 사용되는 요소가 아직 DOM에 렌더링되지 않아 사용자가 빠른 탐색 기능을 통해 어떤 답변 게시글의 요소로도 이동할 수 없습니다.
● 개별 답변 게시글은 스크린 리더가 해당 요소에 포커스를 맞출 때만 DOM에서 헤딩 레벨 2로 표시되어, 사용자가 답변 게시글에 도달하려면 페이지의 모든 요소를 탐색해야 합니다.
● ANDI 접근성 도구는 요소 상호작용 이후 지속적으로 변하는 헤딩 구조를 표시합니다.
● 요소에 접근을 시도할 때 “DOM에서 제거됨” 오류가 표시됩니다.
● 스크린 리더가 페이지 구조에 대한 일관된 뷰를 유지하지 못합니다.
플랫폼 세부 정보:
● JAWS/NVDA: 완전한 실패 - 답변 헤딩에 전혀 접근할 수 없음
● VoiceOver: 빠른 탐색을 통한 접근은 가능하지만 로터 접근은 불가 - VoiceOver는 직접적인 페이지를 읽는 방식으로 작동하므로, 사용자는 빠른 탐색 키를 사용하여 답변 헤딩으로 탐색할 수 있습니다. 그러나 로터 내에서 스크린 리더가 포커스를 맞춘 요소만 접근 가능합니다.
중요한 이유: 스크린 리더 사용자는 토론 답변을 읽는이라는 핵심 작업을 완료할 수 없습니다. 이는 토론 참여에 대한 완전한 장벽입니다.
구체적으로 어떤 주제에서 테스트를 해 보셨는지 아실까요? 동일한 문제를 보고 있는지 확인하기 위해 공유할 수 있는 기준이 있으면 도움이 될 것입니다. 게시글 콘텐츠에는 다양한 변형이 많기 때문에, 노력이 올바른 방향으로 집중되도록 확인하고 싶습니다.
try.discourse.org를 사용하시거나, 도움이 된다면 Meta의 이 게시글을 참고용으로 사용할 수도 있습니다.
"빠른 내비게이션"이라고 말씀하시면서 특정 요소 목록(element lists)에 대해 보고하시는 것 같습니다. NVDA와 VoiceOver 모두 DOM에 현재 사용 가능한 콘텐츠만 요소 목록에서 접근할 수 있음을 확인했습니다. 이는 시력 있는 사용자에게도 동일하며, Discourse가 작동하는 방식의 근본적인 부분입니다. 수동 페이지네이션 대신, 사용자가 페이지를 아래/위로 스크롤할 때 콘텐츠를 로드/해제(offload)합니다.
"빠른 내비게이션"을 언급할 때 보통 제가 예상하는 상황은 이것입니다. 다만, 애플리케이션마다 용어가 항상 일관되지는 않다는 점을 이해하고 있습니다.
NVDA와 VoiceOver에서 요소 간 탐색이 정상 작동하는지 확인했습니다. 그러나 주제 내 "작은 게시글(small posts)"에서 탐색이 중단될 수 있는 문제를 발견했으며, 이를 수정할 예정입니다.
"작은 게시글"은 고정(pinned), 닫힘/열림, 활성화(actived) 등 주제 상태 업데이트를 의미합니다. 이러한 게시글의 문제는 일반 게시글과 달리 내부 헤딩이 없다는 점입니다. 탐색 중 더 많은 게시글이 로드되기 직전의 임계값에 도달했을 때, 사용자가 멈추고 "다음 헤딩 없음"만 듣게 될 수 있습니다.
ANDI와 같은 자동화 도구는 Discourse와 같은 웹 애플리케이션의 DOM 변경 사항을 인식하지 못하는 경우가 많습니다. 이러한 도구는 정적 페이지와 같은 단순한 시나리오를 위해 일반적으로 구축됩니다. 따라서 이러한 도구를 사용하여 문제를 식별하는 경우가 있긴 하지만, 탐색과 같은 더 복잡한 시나리오에서는 수동 테스트로 재현할 수 있는 부분에 집중해야 합니다.
이것도 요소 목록에 대한 언급으로 보입니다. 이는 예상된 동작이지만, Discourse에서 요소 목록이 작동하도록 할 수 있는 개선 사항이 있는지 고려해 볼 수 있으며, 엔지니어에게 의견을 구해 보겠습니다.
이것도 특정 요소 목록에서의 문제인가요? 위에서 언급했듯이 NVDA와 VoiceOver의 요소 간 탐색을 테스트했으며, 정상 작동하는 것을 확인했습니다… 하지만 작동하지 않는 특정 컨텍스트가 있다면 더 자세히 살펴볼 수 있습니다.
안녕하세요 @awesomerobot, 저희는 APH로부터 이 문제에 대한 접근성 자문을 의뢰받았습니다. 아래에 이 스레드와 관련된 주요 문제를 보여주는 몇 가지 비디오 링크를 제공했습니다. 첫 번째 녹화본의 타임스탬프 08:36부터 시작하는 부분에서 문제를 확인하실 수 있습니다. Discourse Accessibility Audit JAWS
이것은 요소 목록과는 관련이 없으며, 우리가 ‘퀵 키(Quick Keys)’ 또는 '퀵 내비게이션(Quick Navigation)'이라고 부르는 기능과 관련이 있습니다. 이 기능을 사용하면 다음 HTML 요소 유형(이 경우 제목)으로 이동할 수 있습니다.
새로운 랜드마크(landmark)를 생성하여 이 문제를 해결하는 것의 문제는, 랜드마크가 일반적으로 상위 수준의 섹션에 할당된다는 점입니다. 따라서 화면 낭독기 사용자에게는 페이지의 작은 섹션 사이를 랜드마크로 이동하는 것이 내비게이션 배너와 같은 페이지의 큰 영역에 대한 빠른 접근을 방해하게 됩니다. 또한 이는 WCAG 표준 레벨 A를 위반하여 '바이패스 블록(Bypass Block)'을 생성하게 됩니다.
안녕하세요 @awesomerobot, 저는 코디(Cody)의 동료이자 접근성 엔지니어입니다. 문제를 진단하기 위해 저장소를 살펴봤습니다. 이미 알고 계실 수 있지만, 핵심 문제는 (1) 가려진(cloaked) 게시물의 내용이 스크린 리더에서 볼 수 없고, (2) 게시물이 PostStreamViewportTracker를 통해 사용자의 뷰 안에 있을 때만 가려짐이 해제된다는 점으로 보입니다.
잠재적인 해결책을 고안하면서, 두 가지를 최적화하고자 합니다: (1) 스크린 리더를 통해 각 게시물의 헤딩으로 탐색할 수 있도록 하고, (2) Discourse 저장소에 대한 변경 사항과 성능에 미치는 영향을 최소화하는 것입니다.
제가 권장하는 접근 방식은, 각 로드된 게시물에 대해 헤딩 탐색에 사용되는 의미론적 H2를 포함하는 경량 래퍼를 유지하고, 무거운 본문은 가려진 상태로 두는 것입니다. 이렇게 하면 보조 기술에 대한 헤딩을 안정적으로 유지하면서도 페이지 전체에 걸쳐 DOM을 부풀리지 않을 수 있습니다. 사용자가 헤딩 탐색을 통해 특정 게시물의 H2에 도달하면, 스크린 리더가 페이지 스크롤을 트리거하고, 이는 다시 게시물의 본문을 해당 위치에 가려짐을 해제합니다.
이 솔루션의 실행 가능성은 다음 게시물 청크가 로드되는 시점에 달려 있습니다. 선택적 개선 사항으로, 로드된 게시물 목록의 하단에 스크린 리더 전용 센티넬 헤딩인 “더 많은 게시물 로드”를 배치하는 것입니다(당신의 PR에서 제안된 "더 많은 로드 영역"과 유사). 이 헤딩이 뷰에 들어오거나 헤딩 로터에서 선택되면, 다음 청크가 로드되고 aria-live=polite 메시지를 통해 완료 사실이 공지됩니다.
