안녕하세요,
나중에 시도해 보겠습니다. 하지만 이것은 해결책이 아닙니다. 실제 스크린 리더가 수행하는 단계를 실행하고 있지 않기 때문입니다. 특정 게시글로 이동한 것은 해당 게시글을 읽고 싶다는 의미로 해석할 수 있습니다. Tab 키는 읽기 명령이 아니라 포커스를 다음으로 이동시키는 수단입니다. 읽기 명령은 스크린 리더에서 사용하는 화살표 아래 키나 SayAll 명령과 같은 것입니다. 적어도 화살표 아래 키는 제가 선호하는 읽기 명령인데, 포커스가 시각적으로 보이는 위치가 아니라 보통 게시글 목록 앞에 위치해 있어 작동하지 않습니다.
물론 Tab 키를 사용하여 이 버그를 해결하는 것은 가능한 방법이지만, 버그 자체의 근본적인 해결책은 아닙니다.
@thoeg, @nolan 감사합니다. 정말 감사드립니다. 문제의 원인을 파악한 것 같습니다. 현재 포스트에 포커스를 설정하기 위해 빈 span 요소를 사용하고 있습니다. 이 요소에는 aria-hidden=true와 tabindex=-1가 모두 설정되어 있으며, 이로 인해 스크린 리더에서 이 요소를 볼 수 없게 만드는 것 같습니다.
포커스를 포스트 내의 첫 번째 포커스 가능한 요소로 전환하는 것이 가장 좋을 것 같습니다. 대부분의 경우 이는 사용자 이름 링크, 즉 포스트 작성자가 될 것입니다.
안녕하세요,
이해가 됩니다. Ariahidden은 요소를 숨기고, -1은 포커스를 받지 못하게 합니다. 이 요소가 주제 제목에 포커스를 전달한다면 괜찮을 것입니다. 대신 tabindex=0으로만 설정했을 때 어떤 일이 발생하는지 확인해 보면 흥미로울 수 있습니다.
네, @anni_anni님 말씀 잘 들었습니다. 이 문제를 수정하겠습니다. 지난주에 첫 시도를 해보았지만, 원치 않는 부수 효과가 있어서 되돌려야 했습니다. 곧 다른 방식으로 다시 시도해 보겠습니다.
이 문제에 대한 업데이트가 있나요? 아직 확실히 해결되지 않았습니다!
Claus
네, 아직 해결되지 않았습니다. 임시 PR을 여기에 올렸습니다: A11Y: fix setting focus to a post - Pull Request #23367 - discourse/discourse - GitHub, 현재 내부 피드백을 기다리고 있습니다.
드디어 이 문제를 수정하기 위한 또 다른 시도가 병합되었습니다. 현재 구현 방식은 포스트 내 첫 번째 포커스 가능한 요소에 포커스를 설정하는 것이며, 대부분의 경우 이는 포스트 작성자의 사용자 이름이 됩니다. 포스트로 이동한 후 Tab 키를 누르면 Chrome에서 다음과 같이 보일 것입니다:
meta에서 이 기능을 직접 시도해 보고 문제가 있으면 알려주세요.
Meta와 community.fly.io에서 Chrome을 사용할 때 여전히 이전의 깨진 동작이 관찰됩니다. 다만, discourse.team 사이트에서는 수정이 제대로 적용된 것을 확인했습니다. 이 사이트들은 서로 다른 버전의 Discourse를 실행하고 있는 건가요? 저는 동일한 버전의 Chrome과 동일한 프로필을 사용하고 있습니다.
감사합니다.
음, 세 사이트 모두 약간 다른 버전의 Discourse를 사용 중일 수 있지만, 위 링크에 있는 변경 사항이 모두에 적용되어 있다고 생각합니다. 특히 Meta는 항상 tests-passed 브랜치의 최신 변경 사항과 동기화되어 있기 때문에, 여기서 제대로 작동하지 않는다는 점이 좀 걱정스럽네요…
이 문제에 대해 조금 더 정보를 드릴 수 있을 것 같습니다. 제가 이 기능이 정상 작동한다고 보고했던 discourse.team 사이트에서 관찰한 내용입니다.
읽어본 적 없는 완전히 새로운 게시물로 이동하면 음성 피드백이 전혀 제공되지 않고, 포커스가 첫 페이지로 추정되는 게시물에 무작위로 위치하는 것 같습니다.
이전에 방문한 주제(topic)로 이동하면 포커스가 올바르게 위치하며, 음성 피드백도 정상적으로 제공됩니다.
이러한 동작은 현재 Firefox와 Chrome 간에 일관되게 나타나고 있습니다. 이전에는 Firefox에서 새로운 스레드를 볼 때 포커스가 첫 번째 게시물에 올바르게 위치했던 것 같습니다. 가능하면 이러한 동작이 복원되어 첫 읽기 경험과 재방문 경험이 동일하게 작동하도록 하면 좋겠습니다. Chrome에서는 이제 마지막 읽은 위치가 최소한 복원되는 것 같아 다행입니다. 업무에 필수적이기 때문입니다.
Firefox와 Chrome 간에 이러한 동작이 이렇게나 달랐다는 점이 놀랍습니다.
이 문제를 위해 기울여주신 노력에 감사드립니다.
좋은 소식입니다! 여기서 변경 사항을 주제 내 첫 번째 게시물이 아닌 게시글로 이동하는 것으로 제한했습니다. 기존 사용자의 경우, 이미 읽었지만 이제 새 답변이 달린 주제로 이동하는 경우가 많을 것입니다.
이 정보가 도움이 됩니다. 이 문제를 반복적으로 개선하고 수정할 방법을 찾은 것 같습니다. 사용 중인 명령어의 정확한 순서를 공유해 주시면 더 큰 도움이 될 것입니다.
제 일반 크롬 브라우저에서 읽지 않은 새 주제로 이동한 후 Tab 키를 누르면 포커스가 주제 제목에 잡히는데, 제 입장에서는 합리적으로 보이지만 당신의 사용 사례에는 충분하지 않을 수 있습니다.
계속해서 피드백을 주셔서 감사합니다. 정말 감사합니다!
JAWS와 Chrome을 사용하여 메타에서 새 주제에 대해 테스트를 해보니 이상한 상황이 발생했습니다. JAWS에서 새로운 동작을 확인했습니다. 주제 제목에서 Enter 키를 누르면 방금 로드된 페이지에 대한 일반적인 정보가 표시되는데, 이는 JAWS의 표준 동작입니다. 주제 목록으로 돌아가서 같은 주제에서 Enter 키를 누르면 포커스가 마지막 읽은 게시글로 이동합니다. 이로 인해 적어도 두 가지 문제가 해결된 것 같습니다. 주제 목록에서 ‘마지막 게시글로 이동’ 기능은 테스트하지 않았지만, 이 기능도 작동할 것으로 추측됩니다.
하지만 물론 모든 것이 완벽한 것은 아닙니다. 이는 전혀 관련이 없을 수도 있지만, 뒤로 가기 버튼을 사용하여 주제 목록으로 돌아가면 포커스가 사라지고, 열어서 읽던 주제로 다시 돌아가지 않습니다. 이는 이전에 유사한 사례를 본 JAWS/Chrome 버그일 수도 있고, 개발자 측의 문제일 수도 있습니다. NVDA로 확인해 봐야겠습니다.
NVDA와 Chrome으로 방금 테스트해 봤는데, 아무것도 작동하지 않습니다. 즉, 표에 있는 주제 제목 중 어디를 눌러도 엔터 키를 눌러서 열 수 없게 되었습니다. 분명히 예전에는 잘 작동했는데, JAWS를 사용하긴 하지만 NVDA 사용자에게는 이 문제가 큰 불편을 줄 것입니다.
NVDA가 제대로 작동하지 않아서, 주제에서 주제 목록으로 돌아갈 때 포커스가 어떻게 처리되는지 테스트할 수 없습니다.
JAWS는 여기서 안정적으로 작동하며, 포커스는 페이지 상단에 배치됩니다.
거의 다 왔습니다!
우리 discourse.team 사이트의 최신 Chrome 브라우저에서 이전에 방문한 주제를 클릭하면 읽던 곳에서 다시 읽을 수 있으며, NVDA가 포커스가 있는 게시물의 제목을 올바르게 읽어 줍니다.
불행히도, 새로운 주제에 들어갈 때 포커스가 해당 주제의 첫 번째 게시물에 설정되지 않습니다. 또한 ‘h’ 키를 눌러 첫 번째 게시물에 포커스를 두려 해도 실패합니다. 읽기 시작하려면 수동으로 찾아야 합니다.
참고로 Firefox에서는 새 게시물에 포지션이 올바르게 설정되는 것 같습니다. 어떤 이유에서인지 Chrome에서만 그런 것 같습니다.
모든 조건이 같다면, 이전 스레드에서 위치가 복원되는 것이 제게 가장 큰 불편함이므로 그 점은 기쁩니다. 하지만 두 가지 사용 사례 모두에서 일관되고 정확한 동작을 얻을 수 있기를 희망합니다.
감사합니다!
좋은 소식입니다.
이 부분도 정확합니다. 현재 구현 방식에서는 대상 게시물이 첫 번째 게시물인 경우 포커스 설정을 의도적으로 건너뛰고 있습니다. 첫 번째 게시물에도 동일한 로직을 적용해 보았지만, 주제 URL을 로드할 때 불필요한 스크롤이 자주 발생하여 모든 사용자에게 너무 큰 불편을 주었습니다.
이 문제는 해결될 것으로 보입니다. 테스트를 해보면서 수정할 수 있는지 확인하겠습니다.
피드백 감사합니다!
며칠 전부터 계속 신경 쓰이던 사소한 문제 하나를 더 짚고 넘어가려 합니다.
새 주제를 등록할 때 태그/카테고리를 추가하는 드롭다운 메뉴가 좀 어색합니다. 먼저, 저에게 표시되는 라벨은 “Filter by”(필터링)입니다. 이것이 시각적으로 실제로 보이는지 아닌지는 모르겠지만, Discourse에서 수년간 글을 올렸음에도 태그를 추가하는 방법이 이것이구나 깨달은 것은 최근의 일입니다. 저에게 "Filter"라는 표현은 "물에서 무언가를 걸러내는 것"을 연상시키지, 새로운 것을 추가하는 것을 의미하지 않습니다. 만약 이것이 시각적으로 표시되는 것이라면 이 피드백을 어떻게 활용하시든 상관없지만, ARIA 전용 속성이라면 조정할 가치가 있을 수 있습니다.
다음으로, 태그 목록을 클릭하면 라디오 버튼처럼 보이는 항목들이 나타납니다. 여기서 Space 키를 누르면(즉, ARIA 라디오 그룹 패턴에 따라) 검색이 트리거되는 것 같습니다. 여기서 Enter 키를 누를 수도 있지만, 엄지가 바로 그곳에 있기 때문에 버튼 상호작용을 위해 Space 키를 누르는 습관이 있습니다.
이것은 certainly blocker(완전한 장애물)는 아니지만, 분명히 발견하기가 더 어렵고, 글을 올릴 때마다 어떻게 작동하는지 기억하거나 다시 파악해야 하는 추가적인 노력이 필요합니다. 과거에는 개별 카테고리를 클릭해 왔지만, 그렇게 하면 여러 태그를 사용할 수 있는 능력이 제한되었습니다.
이 상호작용에 더 적합한 방식은 ARIA 콤보박스 패턴일 것입니다. 특히 편집 가능한 콤보박스는 훨씬 혼란스럽지 않은 방식으로 작동합니다. "A"를 입력하면 화살표 키를 아래로 눌러 "Alabama"로 이동할 수 있습니다. 라디오 버튼으로 제시되지 않기 때문에 저의 자동 반응은 Space 키를 누르는 것이 아닙니다. 하지만 만약 누르게 되면, 예상대로 공백이 삽입됩니다. 라디오 버튼 프레젠테이션을 제거하는 것만으로 충분할 수도 있지만, 결과 개수에 대한 피드백도 좀 더 간결하게 할 수 있을 것입니다.
많은 도움 부탁드립니다.
고맙습니다, 놀런. 정말 도움이 되네요. 이 드롭다운 관련해서 처리할 내부 할 일 목록이 있는데, 거기에 피드백을 꼭 반영하겠습니다.
좋아요, 한 가지 더.
게시물 편집 박스에 이모지를 입력할 때(예: :)) 편집 중 포커스가 해당 이모지에 머물러 있으면, 위/아래 화살표 키로 이전 줄이나 다음 줄로 이동할 수 없습니다. 먼저 좌/우 화살표 키를 눌러 이모지 영역에서 벗어나야 합니다.
이것은 자동완성 동작 때문인 것 같습니다. 일치하는 항목이 하나뿐인 경우, 또는 Enter 키나 다른 키가 눌리기 전까지는 이 동작을 비활성화할 수 있을지 궁금합니다. 초기 입력이나 편집 시 자동완성 동작은 이해가 되지만, 특정 상황에서 포커스를 이동할 수 없는 이유를 디버깅하는 데 꽤 애를 먹었고, 이것이 원인이었던 것 같습니다. 편집 시 수동으로 트리거되는 드롭다운 방식이 여기서는 더 적절한 선택이 될 것 같습니다.
많은 도움 감사합니다.
