무한 스크롤 기능 때문에 사용자가 푸터에 도달할 수 없다는 문제를 다룬 다른 폐쇄된 스레드를 읽었습니다. 해당 문제는 해결되지 않았습니다. UX(사용자 경험) 문제라는 우려가 제기되었는데, 이는 확실히 사실입니다. 하지만 이 문제는 접근성(Accessibility) 문제이기 때문에 제게 알려졌습니다.
문제점:
사용자가 스크롤과 같은 입력을 하고 있다고 해서 무한 스크롤을 활성화하려는 의도인 것은 아닙니다. 추가 정보나 지원을 위해 푸터에 도달하려는 의도일 수도 있습니다.
이 구성을 사용하는 커뮤니티는 WCAG 2.1 A 레벨을 통과하지 못합니다.
A 레벨은 웹 접근성에서 가장 기본적이고 필수적인 수준으로 간주됩니다.
저는 한 커뮤니티를 감사(audit)하고 있으며, 이 문제는 다음과 같은 성공 기준의 실패로 분류됩니다:
2.2.2 일시 정지, 중지, 숨기기 (레벨 A) - 중요
(1) 자동으로 시작되고 (2) 다른 콘텐츠와 병렬로 표시되는 자동 업데이트 정보에 대해, 사용자가 이를 일시 정지, 중지 또는 숨기거나 업데이트 주기를 제어할 수 있는 메커니즘이 있어야 합니다. 단, 자동 업데이트가 필수적인 활동의 일부인 경우는 제외합니다.
3.2.5 요청 시 변경 (레벨 AAA) - 심각
컨텍스트 변경은 사용자 요청에 의해서만 시작되거나, 이러한 변경을 끄는 메커니즘이 제공되어야 합니다.
해결책:
피드에 ‘더 많은 게시물 불러오기’ 버튼을 추가하여 사용자에게 제어권을 돌려줍니다.
사용자가 한 번에 볼 게시물의 수를 선택할 수 있도록 하여, 더 무한한 경험을 원하는 사용자들이 그렇게 할 수 있게 합니다.
"이 구성이 마음에 들지 않으면 다른 것을 선택하세요"라고 말하는 것은 정말로 허용될 수 없습니다. 이 구성은 훨씬 더 사용 가능하도록 쉽게 개선할 수 있으며, 그렇게 해야 합니다. 이는 많은 고객들에게 도덕적 및 법적 요구사항입니다.
이 분야에 대한 기존 연구에 대해서는 잘 알지 못하지만, 무한 스크롤 웹사이트에 푸터를 배치해서는 안 된다는 것은 널리 알려진 사실입니다. 여기에는 Facebook, Twitter, LinkedIn, Instagram, GMail 등 많은 인기 있는 사례가 있습니다. 이 서비스들 중 어느 곳에도 푸터가 없으며, 수십억 명이 사용하는 웹 애플리케이션으로서 모든 기능이 정상적으로 작동하고 있습니다.
이것은 우리의 로드맵에 없으며, 기존 유료 고객 중 이러한 기능을 요청한 사례를 본 적이 없습니다.
따라서 전체적인 맥락을 올바르게 이해했다면, 당신의 문제는 다음과 같습니다:
주요 프로퍼티(주요 사이트) 웹사이트에는 푸터가 있습니다.
주요 프로퍼티와 Discourse 인스턴스가 유사해 보이기를 원합니다.
Discourse는 무한 스크롤을 통해 푸터를 밀어내므로, 일부 페이지에는 눈에 띄는 푸터가 없습니다.
일부 페이지에만 푸터를 두는 것은 원치 않습니다.
복잡한 상황이라는 점을 이해하지만, Discourse를 사용하려는 경우라면 담담하게 받아들이고 두 가지 옵션 중 하나를 선택해야 합니다:
푸터를 배치합니다.
무한 스크롤이 없는 페이지를 홈 페이지로 사용하세요(예: Categories - Discourse Meta). 이렇게 하면 푸터가 눈에 잘 띄게 표시되며, /latest 경로에서 도달하기 어렵다는 점은 신경 쓰지 않아도 됩니다.
푸터를 배치하지 않습니다.
우리의 discourse.org 페이지에는 푸터가 있으며, 블로그에도 있습니다. 하지만 여기(메타 사이트)에는 동일한 푸터가 없습니다. 많은 회사가 이렇게 하고 있으며, 반대로 하려는 시도는 둥근 구멍에 네모난 못을 끼우려는 것과 같습니다.