최근 2.8.0.beta2로 업데이트한 후, 관리자 메뉴 버튼이 노란색으로 강조되어 있습니다.
Discourse가 무언가 알려주려는 줄 알고 웹과 이 포럼을 검색해 봤지만, 그 이유가 무엇인지 전혀 알 수가 없습니다.
혹시 아시는 분 계신가요?
키보드 포커스가 해당 항목에 맞춰져 있다는 것을 알려주는 것 같습니다. 이는 최근 accessibility(접근성) 변경 사항입니다:
메뉴를 표시한 후, Tab 키를 눌러 메뉴 항목 사이를 이동해 보세요.
4개의 좋아요
네, 맞습니다. @simonk가 지적했듯이, 오버레이로 포커스를 전환하지 않는 것이 우리가 범했던 오류 중 하나입니다. 애플리케이션 내를 탐색할 때 포커스는 합리적인 위치에 있어야 합니다.
4개의 좋아요
음, 잘 모르겠는데; @awesomerobot 거기에 호버 상태가 필요할까요?
1개의 좋아요
CSS에서 :focus 대신 :focus-visible를 사용하는 것이 좋을 것 같습니다. 아직 Safari에서는 지원되지 않지만, 해당 경우 :focus로 폴백(fallback)하는 것은 쉽습니다.
스펙에 따르면:
활성 요소가 :focus-visible와 일치하고, 스크립트가 포커스를 다른 곳으로 이동시키는 경우, 새로 포커스가 설정된 요소는 :focus-visible와 일치해야 합니다.
즉, 탭 키를 사용하여 햄버거 메뉴로 이동하여 메뉴를 여는 경우(:focus-visible 스타일이 활성화됨), 메뉴가 열리면 :focus-visible 스타일이 표시됩니다. 포인터(마우스 등)를 사용하여 메뉴를 여는 경우, :focus-visible 스타일은 표시되지 않습니다:
하나라는 단점이 있습니다. 포인터로 햄버거 메뉴를 연 후 탭 키로 내비게이션을 시도하는 혼합 입력 시나리오에서는, 첫 번째 링크에 :focus-visible 스타이가 표시되지 않습니다(기술적으로는 포커스가 설정되어 있음에도 불구하고). 따라서 건너뛴 것처럼 보입니다. 이 문제를 해결하는 우회 방법이 있는지 확실하지 않습니다…
5개의 좋아요
저는 (대부분) 마우스를 사용하므로, 그런 동작을 기대하는 것이 당연합니다.
한편, 때로는 터치스크린이 있는 스마트폰을 사용하는데: 그곳에서도 동일한 문제가 발생합니다. Admin 항목이 강조되어 있어, 관리 섹션에 주의가 필요한 중요한 내용이 있을 수 있음을 시사합니다.
관련된 스크린 리더 주제에서 포커스를 어떻게 설정해야 하는지에 대한 필요가 있는 것 같습니다.
위에서 언급한 포인터에 대한 동작만이라도 구현된다면 만족하겠습니다.
1개의 좋아요
저도 같은 문제가 있습니다.
이 요소가 여러분이 의도했던 UX 가치를 제공한다고 생각하지 않습니다. 포럼에서 이 문제에 대한 버그 리포트가 즉시 접수되었습니다. 창 안에서 아무 곳이나 마우스 오른쪽 버튼을 클릭하면 포커스가 사라지고, 버튼 위에 마우스를 올리면 이중 포커스가 나타납니다. 특히 Discourse는 다른 뷰에서는 이러한 선택을 강제하지 않기 때문에, 사용자에게 전반적으로 버그가 있는 것처럼 보입니다.
사용자가 Tab 키를 처음 눌렀을 때만 키보드 포커스를 표시하거나, 사용자가 키보드 조작으로 햄버거 메뉴를 열었을 때만 표시하는 것이 더 나을 것입니다.
2개의 좋아요
이 문제에 대한 스크린샷을 올려주실 수 있나요? 해당 문제는 인지하고 있지 않습니다
1개의 좋아요
Safari와 Firefox(macOS)에서도 동일한 증상이 관찰되며, 이는 위 게시물에서도 언급된 내용입니다:
이 기능을 제가 이해하는 대로라면, 클릭하거나 = 키를 눌러 해당 메뉴를 연 다음, 방향 키(혹은 다른 키)로 이동한 뒤 Enter 키를 눌러 하이라이트된 항목으로 이동할 수 있어야 합니다.
macOS의 Safari와 Firefox에서는 클릭으로든 = 키로든 메뉴를 열었음에도 불구하고 메뉴 내에서 이동하는 것이 불가능해 보입니다. 위/아래 방향 키는 페이지를 위아래로 스크롤하고, 좌/우 방향 키는 눈에 띄는 반응을 보이지 않습니다.
Tab 키는 포스트의 좋아요 버튼 등 다른 요소로 포커스를 전환하고, 메뉴의 노란색 하이라이트를 제거합니다. Firefox에서는 이 답변을 쓰기 시작하기 전까지는 Tab 키로 메뉴 항목 사이를 순환할 수 있었지만, 지금은 그렇지 않습니다. 두 시도 사이에 비공개 창이 닫혔습니다.
이러한 동작은 meta 사이트와 efbc2481d8 버전으로 업데이트된 제 인스턴스에서도 확인됩니다(다만, Firefox에서 Tab 키가 성공적으로 동작하는 현상은 meta 사이트에서만 관찰되었습니다).
1개의 좋아요
방향키는 아무것도 하지 않아야 하지만, Tab과 Enter는 동작해야 합니다!
즉, =로 메뉴를 연 다음 Tab을 누르면 메뉴 항목 사이를 순환하지 않는다는 뜻인가요? 저는 macOS를 사용 중인데, Safari, Firefox, Chrome 모두에서 예상대로 작동하므로 조금 당혹스럽습니다!
여기서 무슨 일이 일어나고 있는지 전반적으로 더 자세히 살펴봤는데, 위에서 언급한 focus-visible 사용 아이디어는 작동하지 않을 것입니다.
문제는 햄버거 메뉴가 HTML에서 메뉴 버튼 컨테이너(검색, 햄버거, 사용자 버튼을 포함하는 컨테이너) 외부에 나타난다는 것입니다. 즉, 메뉴는 자연스러운 Tab 순서에서 바로 다음에 위치하지 않습니다. 이를 보완하기 위해 JavaScript를 사용하여 첫 번째 메뉴 항목에 focus를 설정합니다. 이로 인해 해당 항목이 강조 표시되는 부수적인 효과가 발생합니다(우리는 :focus 스타일도 가져야 하므로).
Tab 키 입력을 감지하는 데 의존할 수 없을 것 같습니다. 스크린 리더가 탐색에 사용하는 유일한 키가 아니기 때문이고, 모든 키 입력을 캡처하면 다른 단축키와 충돌할 수 있기 때문입니다…
두 가지 가능한 해결책이 생각납니다:
-
HTML에서 메뉴를 이동하여 트리거 버튼 바로 뒤에 나타나도록 합니다. 이로 인해 레이아웃에 일부 부수적인 영향이 있을 수 있습니다.
-
메뉴가 열려 있을 때 포커스를 메뉴 내부에 가두되, 특정 항목에 포커스를 설정하지 않습니다. 이는 메뉴가 열려 있을 때 페이지의 다른 요소가 아닌 메뉴 내용만 Tab으로 이동할 수 있음을 의미합니다. 이 방법이 더 바람직한 해결책이라고 생각합니다…
2개의 좋아요
맞습니다. 좀 더 구체적으로 말씀드리면, 제 환경은 macOS 11.4와 Safari 14.1.1입니다. 메타 사이트는 비공개 창에서, 제 인스턴스는 일반 창에서 보고 있습니다.
Firefox 초기 테스트를 제가 잘못한 것 같습니다. 시스템 환경 설정에서 키보드 탐색을 사용하여 컨트롤 간 포커스 이동이 활성화되어 있으면 말씀하신 대로 작동하고, 비활성화되어 있으면 이전에 설명드린 대로 좋아요 버튼으로 탭 이동합니다.
Firefox에서는 페이지를 새로고침하지 않고 해당 시스템 설정만 전환하면 동작 방식이 확실하게 바뀝니다.
Safari의 경우, 해당 시스템 설정과 관계없이 페이지를 새로고침해도 좋아요 버튼으로 탭 이동하는 현상이 관찰됩니다. 설정을 활성화한 후 Safari를 재시작하는 테스트는 아직 하지 않았습니다.
Chrome도 확인해 보았는데, 시스템 설정과 관계없이 말씀하신 대로 작동합니다.
1개의 좋아요
Safari에서 문제를 일으키는 원인을 찾았습니다. Chrome이나 Firefox와 달리, Safari에서는 헤더 바의 아무 곳이나 클릭한 뒤 Tab 키를 누르면 헤더의 어떤 요소도 선택되지 않는다는 것을 알게 되었습니다.
이로 인해 Safari의 고급 설정에서 다음 옵션을 발견하게 되었습니다:
새로 설치한 Big Sur의 기본 설정이 이 옵션일 것으로 99% 확신합니다. 제가 이 설정을 변경했을 리가 없기 때문입니다. 이 옵션을 켜두면 설명하신 대로 정상적으로 작동합니다. 위 텍스트에서도 언급했듯이, 이 옵션을 꺼둔 상태에서도 Option-Tab을 사용하면 동일하게 작동합니다.
2개의 좋아요