이 문제가 이미 알려져 있거나 추적되고 있는지 확실하지 않습니다. 알고 있다면 링크를 공유해 주시면 감사하겠습니다. 하지만 점차 개선되고는 있지만, 스크린 리더와 함께 Discourse를 사용할 때 몇 가지 어려움이 있어 이를 문서화하고 싶었습니다.
저는 스크린 리더 사용자이며, 주로 시각장애인 사용자를 대상으로 하는 자체 호스팅 인스턴스를 설정하고 싶었습니다. 일반적으로 접근성 문제로 인해 Discourse를 권장하지는 않지만, 제가 원하는 기능들을 갖춘 자체 호스팅을 매우 쉽게 만들어 주셨기 때문에 접근성이 아직 완벽하지 않은 점은 아쉬울 따름입니다. 제가 겪고 있는 몇 가지 어려움은 다음과 같습니다:
스크린 리더에 HTML <select/>로 보고되는 드롭다운은 거의 완전히 깨져 있습니다. 일반적인 키보드 단축키를 통해 확장되긴 하지만, 접근성은 거기서 끝납니다. 어려움은 설정 중에 언어를 선택해야 했을 때 시작되었습니다. 영어(미국)이 기본값으로 설정되어 있는지 바로 파악하기는 어려웠지만, 확인해 보려다 보니 어쩜 보니 언어가 스페인어로 설정되어 있었고 되돌리는 데 큰 어려움을 겪었습니다. 결국 스크린 리더로 목록을 찾아 수정했습니다. 하지만 거의 모든 드롭다운이 깨져 있습니다. 인터페이스의 구석진 곳에 작동하는 드롭다운이 있을지도 모르기 때문에 '모든’이라고 말하고 싶지는 않지만, 제가 시도해 본 것들은 전혀 작동하지 않습니다.
직접 내비게이션을 하지 않고서는 관리자 인터페이스로 가는 방법을 찾을 수 없습니다. 설정 화면에서는 기어 아이콘 아래에 있다고 알려주었지만, 기어 아이콘의 텍스트적 표현을 찾을 수 없고, 제가 찾은 키보드 접근 가능한 컨트롤 중 어느 것도 결국 관리자 인터페이스로 연결되지 않았습니다. 지금은 그냥 /admin을 입력하고 있지만, 이 기어 아이콘을 찾지 못해서 어떤 도구를 놓치고 있는지 궁금해집니다.
설정 드롭다운과 관련해서, 카테고리 목록 상단의 드롭다운/셀렉터를 사용하여 카테고리 목록으로 이동할 수 없습니다. 일반적으로 제가 사용하는 ‘Categories(카테고리)’ 링크는 알고 있습니다. 하지만 해당 셀렉터가 작동하면 좋겠습니다.
Discourse에 가입하지 않을 때, 포럼이 제가 읽기를 중단한 위치를 기억해 주기 때문에 가입해야 한다고 알려줍니다. 스크린 리더를 사용할 때 이 기능은 저에게 작동한 적이 없습니다. 이 기능은 어떻게 작동해야 하나요? 링크를 클릭하면 제가 마지막으로 읽은 게시글로 포커스가 이동해야 하나요?
그리고 제 사이트와 관련은 없지만, 이곳의 모달 가입 경험에도 몇 가지 어려움이 있었습니다. 이메일로 가입을 시도했는데, 거의 17년 동안 사용해 왔고 제 사이트에서는 잘 작동했던 .info 이메일 주소가 이 인스턴스에서 거부되었습니다. 그 후 Google로 가입했는데, 돌아왔을 때 주어진 모달이 몇 가지 문제를 일으켰습니다:
키보드 포커스를 가져오지 않아서, 제가 직접 찾아서 상호작용해야 했습니다.
그렇게 하던 중, 무한 스크롤되는 주제 목록이 새 주제를 계속 추가하면서 포커스가 실제로 대화상자에 도달하는 것을 더 어렵게 만들었습니다. 정확히 어떻게 주제보다 빠르게 이동했는지 기억은 나지 않습니다—아직 커피를 마시지 않았거든요—하지만 여기 있습니다.
그래서 몇 가지 질문이 있습니다:
가능하다면 저는 Discourse를 계속 사용하고 싶습니다. 이 중 얼마나 많은 부분을 제 사이트에서 직접 변경할 수 있나요? 특히:
사용자가 지금은 카테고리 목록 링크를 통해 상호작용해야 하도록 카테고리 목록 셀렉터를 제거할 수 있나요?
사용자가 게시할 카테고리를 먼저 입력해야 하고, 실수로 분류되지 않은 게시글을 만들거나 혼란을 겪지 않도록 새 주제 페이지의 카테고리 셀렉터를 제거할 수 있나요?
이 두 가지를 모두 업그레이드를 쉽게 하는 방식으로 할 수 있나요? 어쩔 수 없다면 표준 템플릿을 편집하거나 프로젝트를 포크하고 싶지 않으며, 완전히 새로운 테마를 원하지도 않습니다.
이 작업이 어딘가에서 추적되고 있으며, 이를 전담할 사람이 있나요? Discourse 포럼이 인터넷을 집어삼키고 있습니다. 제가 시간을 보내는 프로젝트나 커뮤니티 어디서나 이를 채택하고 있습니다. 솔직히, 시각장애인 사용자인 저조차 Discourse를 운영하기를 원합니다. 다시 말하지만, 여러분은 이를 매우 쉽게 만들어 주었기 때문입니다. 저는 단지 이토록 중요한 도구의 접근성이 사후 조치나 새로운 개발에 대한 영원한 추격전이 되기를 원하지 않을 뿐입니다.
@nolan님, 정말 깊이 있는 글이네요. 다른 팀원들도 질문에 대해 의견을 나눌 거라고 생각합니다. 하지만 개발자가 겪고 계신 문제를 재현해 볼 수 있도록 사용 환경을 공유해 주실 수 있을까요? 예를 들어 어떤 운영체제, 어떤 스크린리더를 사용 중인지 같은 정보 말이에요.
피드백 주셔서 감사합니다! 접근성 측면에서 아직 갈 길이 멀다는 점을 잘 알고 있으며, 최근 이 부분에 대해 더 많은 노력을 기울이고 있습니다. 2020년 말에 Discourse의 가장 중요한 비관리자 페이지에 대해 제3자 접근성 감사를 진행했으며, 지난 몇 주간 우선순위가 높은 문제들을 해결하기 위해 작업을 시작했습니다.
말씀해 주시니 관리자 메뉴를 찾는 것이 왜 어려웠는지 이해할 수 있습니다. 메뉴 링크는 주요 헤더 메뉴 중 하나 안에 위치해 있으며, aria-label이 "다른 주제 목록 또는 범주로 이동"으로 설정되어 있습니다… 이는 내부에 몇 가지 관리자 링크가 포함되어 있다는 것을 명확히 알리지 못합니다.
Discourse가 마지막으로 읽은 위치를 기억한다는 메시지에 대해서는, 주제에 진입하면 읽기를 중단했던 위치로 건너뛰는 것이 예상되는 동작입니다. 방금 키보드로 이 기능을 탐색해 보았으며, 포커스가 올바른 위치에 설정되지 않는다는 것을 확인했습니다.
우리의 드롭다운 중 많은 부분은 커스텀 구현이며, 이는 접근성 개선을 위해 지적받은 영역 중 하나입니다. 또한 모달이 포커스를 트랩하지 않는다는 사실도 인지하고 있으며, 이는 특히 무한 스크롤이 있는 페이지에서 경험하셨듯이 도달하기 어려운 콘텐츠를 초래합니다.
Discourse를 계속 사용하느냐에 대한 질문들에 대해 말씀드리자면, 나열하신 모든 것은 가능합니다. 해당 요소를 숨기려면 몇 줄의 CSS가 필요할 뿐입니다. 이 CSS는 테마 내에 있어야 하지만, 기존 테마에 추가할 수 있는 테마 컴포넌트 내에 존재할 수 있습니다(따라서 기본 테마를 변경할 필요가 없습니다). 테마는 Discourse 위에 존재하기 때문에 업그레이드 과정에 훨씬 유리합니다… 말씀하신 것처럼 템플릿을 편집하거나 포크하면 업데이트가 매우 어려워집니다.
우리는 Meta에서 접근성 문제 보고에 accessibility 태그를 붙여 한 곳에서 쉽게 찾을 수 있도록 합니다… 다만 앞서 언급한 제3자 접근성 보고서와 그 후속 작업은 공개적으로 추적되지 않습니다.
특히 게시하는 데 추가적인 노력이 필요했음에도 불구하고 여기에서의 피드백에 진심으로 감사드립니다. 앞으로 몇 달 동안 Discourse가 여러분에게 훨씬 사용하기 쉬워지기를 바랍니다.
또한, 이 문제가 아직 언급되지 않았다면 몇 가지 빠른 접근성 개선을 위해 이 문제를 지적하고 싶습니다.
스크린 리더는 HTML 5의 시맨틱 태그를 효과적으로 활용합니다. 태그 사이를 효율적으로 이동할 수 있을 뿐만 아니라, 현재 위치한 콘텐츠의 유형도 읽어 줍니다.
게시글이 <article/> 안에 있고, 헤더와 푸터가 각각 <header/> 및 <footer/> 요소 안에 포함되어 있으면 좋겠습니다. 요소를 교체하는 것이 불가능하다면, role 속성을 적절히 사용하여 동일한 의미를 전달할 수 있습니다.
현재 긴 스레드를 읽는 것이 어렵습니다. 첫 번째 게시글 이후에는 추천 주제 섹션 등을 넘어서 스크롤해야 합니다. 이후 게시글들을 선형적으로 읽게 되는데, 날짜만 다를 뿐 나머지는 동일한 헤더를 수백 번씩 듣거나, 동일한 메시지 컨트롤이 포함된 푸터를 건너뛰는 방법이 없습니다. 물론 더 나은 결과를 위해 고급 ARIA 설정을 사용할 수 있지만, 태그를 교체하거나 role을 사용하는 것은 적은 노력으로 큰 효과를 거둘 수 있는 방법이라고 생각합니다.
자명한 이야기일 수 있지만, 그래도 말씀드리겠습니다. 단순히 ARIA를 이러한 컨트롤에 붙여 놓고 끝내는 것만으로는 충분하지 않습니다. 다시 말해, 툴바 패턴을 따르지 않은 채 해당 영역을 단순히 툴바로 표시하는 것은, 아예 role 속성을 붙이지 않는 것보다 오히려 나쁠 수 있습니다. 툴바에 접근하게 되면, role 속성만 추가했을 때 자동으로 보장되지 않는 방식으로 동작할 것을 기대하게 됩니다. 접근성을 추가할 때 흔히 발생하는 실수 중 하나가 이러한 role을 추가하되, 그에 연관된 키보드 동작은 구현하지 않는 것이기 때문에 이 점을 명확히 하고 싶었습니다. 그렇게 되면 제 기대와 다르게 동작하는 컨트롤들에 계속 부딪히게 되는데, 이러한 기대 자체가 처음부터 없었던 것보다 훨씬 나쁜 경험이 됩니다.
크리스, 안녕하세요. scrollbar 역할이 여기서 정확히 원하시는 것일지는 모르겠습니다. 실제 동작을 확인해봐야겠지만, 지금까지 이런 방식으로 사용된 사례를 실제로 본 적이 없습니다. 이는 HTML5의 range 요소와 유사하며, 컨테이너의 상대적인 스크롤 위치를 나타냅니다. "첫 번째 게시물로 이동"과 “마지막 게시물로 이동” 항목은 단순히 뷰를 스크롤할 수 있는 버튼일 뿐입니다. aria-value* 속성을 가져야 하는 스크롤바 컨테이너의 내용물로 이러한 버튼이 적절한지 의문입니다.
P.S. VS Code 커뮤니티에서는 제가 ARIA 역할 전문가로 알려져 있습니다. 정확히 어떤 이유로 그런 평판을 얻게 된지는 모르겠지만, 역할에 대해 까다로운 사람으로 알려져 있습니다. 역할은 도움이 되기보다 해가 될 수 있으므로, 이번 변경 사항은 되돌려야 할 가능성이 큽니다. 거의 확실합니다.
호기심에 물어보는데, 팀 안에 접근성(accessibility)에 초점을 맞춘 사람이 있나요? 최근 진행된 접근성 감사와 계획된 변경 사항에 대해 기대하고 있지만, Discourse가 인터넷의 상당 부분을 뒷받침하고 있으므로, 현장에서 직접 경험을 쌓은 사람이 이러한 변경 사항과 함께 작업하며 조언을 해주는 것이 좋을 것 같습니다. 실수를 하기 쉽기 때문에, 의도치 않게 상황이 더 나빠질 수도 있습니다.
예를 들어, Slack은 접근성에 초점을 맞추고 있다고 주장하며 ARIA 사용에도 노력하고 있지만, 그들의 시도는 제 스크린 리더를 통해 채팅 영역에 완전히 접근할 수 없게 만드는 결과를 낳은 것 같습니다. 혹은 접근 가능하더라도, 수십 년의 경험을 가진 저도 어떻게 해야 할지 모르겠네요. Discourse가 의도치 않게 그런 길을 걷게 되는 것은 보고 싶지 않습니다.
어쨌든, 저는 이런 일과 유사한 일을 직업으로 하고 있으며, 도움을 줄 수 있는 상태입니다. 또한 저는 여러 Discourse 포럼을 사용하므로, 신뢰할 수 있는 접근성은 제 삶의 질을 향상시키는 실질적인 이점이 될 것입니다. 관심 있는 분들과 더 이야기 나누기 좋습니다.
@MarcoZehe 타임라인 컨트롤에 대해 스크롤바 역할과 슬라이더 역할 중 어느 것을 사용할지 약간 고민했습니다. 해당 컨트롤이 실제로 페이지를 스크롤하며 W3C에서 제공한 설명에도 부합한다고 판단하여 스크롤바 역할을 선택했습니다:
뷰 영역 내에서 콘텐츠의 스크롤을 제어하는 그래픽 객체로, 콘텐츠가 뷰 영역 내에 완전히 표시되는지와 무관합니다.
그럼에도 불구하고, 우리가 만든 이 컨트롤은 다소 독특한 구조입니다… 페이지를 스크롤하는 동시에 현재 게시물 범위 내에서의 위치를 표시합니다(예: 현재 12개 중 6번째 게시물에 있음을 보여줍니다). 스크린 리더를 위해 마크업하는 좋은 방법이 아예 없을 수도 있고, 그냥 숨기는 것이 더 나을 수도 있습니다… 평소와 같이 페이지 스크롤은 이 컨트롤 없이도 예상대로 작동하니까요. 일단 시도해 보고 실제 동작에 대해 어떻게 생각하는지 의견을 듣고 싶습니다. 잘 작동하지 않으면 되돌릴 수 있습니다.
@nolan 님의 질문에 답하자면, 저는 접근성 권장 사항 정리와 감사(audit) 진행에 대한 책임을 맡게 되었습니다. 다만, 이전의 접근성 관련 경험은 대부분 타인이 정의한 명세를 구현하는 데서 비롯되었습니다. 아직 Slack보다 훨씬 작은 규모라 전담 접근성 전문가를 상근으로 두고 있지는 않습니다… 하지만 이 문제를 제대로 해결하고 상황을 악화시키지 않기 위해, 그 사이 누군가를 계약해서 작업하게 할 필요가 있을 수도 있습니다…
내용이 유실되지 않도록, 본인 감사 결과의 각 항목에 대해 Contribute > UX 태그를 달아 새로운 토픽을 생성하는 것을 추천합니다. 결과들이 밀접하게 관련되어 있다면 각 항목마다 같은 토픽을 사용하는 것이 더 적절할 수 있습니다. 기본적으로, 처음 게시물의 53개 항목 목록에서 1개만 놓쳤다는 걱정을 하지 않고도 독립적으로 추적하고 "완료"로 표시할 수 있는 작은 단위로 항목들을 그룹화하는 것이 목표입니다.
패턴을 구현하지 않고 역할을 사용하는 것은, 무언가를 버튼처럼 스타일링한 뒤 마우스를 올려두고 휠을 스크롤할 때만 반응하도록 만드는 것과 비슷합니다. 툴바에 탭키 등으로 포커스를 맞췄을 때, 모든 버튼을 개별적으로 노출하거나 화살표 키에 반응하지 않는다면, 그 이상한 마우스 휠 버튼처럼 느껴질 수 있습니다. 모든 상호작용 전에 매번 생각해야 하고, 실제로 그렇게 행동하지 않으면서도 그렇게 행동한다고 주장하는 셈이니까요.
이 설명이 조금은 도움이 되길 바랍니다. 무언가가 툴바라는 사실은 툴바처럼 행동할 때만 가치가 있습니다. 그렇지 않으면 오히려 방해가 됩니다.
아, 실망스럽네요. 이 글을 올렸을 때 진행 중이던 것처럼 보였던 모든 업데이트의 현황을 여쭤보려고 이곳에 왔습니다. 아직 커뮤니티를 시작하지는 않았지만, 기존에 사용하던 PHP 기반 포럼이 곧 종료될 예정이라 지금 아니면 기회가 없을 것 같습니다. 이제쯤이면 상당한 개선이 있었을 거라고 생각했거든요.
하지만 제 사이트의 관리자 영역에 어떻게 접근해야 하는지 도무지 알 수가 없었습니다. /admin 경로로는 분명히 접속할 수 있지만, 제가 찾은 어떤 방법으로도 사이트 링크에 키보드로 접근할 수 없었습니다. 스크린리더 사용자에게 모더레이션을 도와달라고 요청할 때 이게 꽤 큰 장벽이 됩니다.
그리고 5분 전에 이 답글을 입력하려 했다가, 어떻게 된 일인지 편집(Edit) 또는 인용(Quote) 버튼을 잘못 클릭했습니다. 그러자 제가 이전에 보낸 메시지의 편집 가능한 버전으로 보이는 화면으로 넘어갔습니다. '취소’라고 표시된 링크에 엔터를 눌렀지만 작동하지 않았습니다. 페이지를 새로 고침하는 것도 마찬가지였습니다. 결국 답글을 보내버린 뒤, 처음 여기에 보고했던 것과 유사한 접근 불가능한 모달 창을 찾아서 메시지를 폐기했습니다.
이 부분에 대해 변화가 있었나요, 아니면 공개된 로드맵이 있나요? 스크린리더 사용자로서 원하든 원하지 않든 디스커스(Discourse) 커뮤니티와 상호작용해야 하는 입장에서, 제 자신은 어떻게든 해결할 수 있지만, 맹인 커뮤니티가 이 플랫폼을 사용하도록—아니, 적어도 디스커스에서 그들이 즐길 수 있는 커뮤니티를 구축하도록—요청하는 일은 마음이 편치 않습니다.
Discourse는 저에게 잘 작동하지만, 접근성 개선이 확실히 이루어지기를 원합니다. 관리자 UI를 사용하거나 Discourse 포럼을 관리한 지 꽤 시간이 흘렀지만, 3개월 동안 상당한 진전이 있을 것으로 기대합니다.
ARIA가 도전적일 수 있다는 점은 이해하지만, 그것이 진전이 불가능하다는 의미는 아닙니다. @nolan, 저도 이전에 같은 문제를 겪었습니다. '취소’를 클릭했는데 편집 상자가 사라지지 않은 이유를 파악하는 데 시간이 좀 걸렸거든요. 미래에 제 커뮤니티를 위한 포럼으로 Discourse를 사용하고 싶지만, 접근성 개선이 이루어지지 않는다면 그 계획을 재고해야 할지도 모릅니다. 그리고 PHP로 돌아가는 것은 정말 원치 않습니다.
여러분은 사실상 접근성 문제를 도와줄 사람이 있는 셈입니다. 조급하게 들린다면 죄송합니다. 이 일이 어렵고 여러분에게 힘든 일이라는 것을 알고 있습니다. 하지만 @nolan과 저 모두 도움을 줄 준비가 되어 있습니다. Discourse 테스트 인스턴스를 설정하는 것도 기꺼이 도와드리겠습니다.
