我已经阅读了另一个关于用户因无限滚动功能而无法访问页脚的已关闭讨论帖。该问题尚未解决。有人提出这是用户体验(UX)问题——这确实如此。但此事也被指出属于无障碍访问(Accessibility)问题。
问题所在:
尽管用户正在输入操作(例如滚动),但其目的未必是触发无限滚动,而可能是为了访问页脚以获取更多信息或支持。
任何采用此设置的社区将无法通过 WCAG 2.1 的 A 级标准。
A 级被视为网页无障碍访问最基本且必不可少的等级。
我最近在审计一个社区,并将此问题归类为以下成功准则的失败:
2.2.2 暂停、停止、隐藏(A 级)严重
对于任何自动更新的信息,若其(1)自动开始,且(2)与其他内容并行呈现,则必须提供让用户暂停、停止或隐藏该信息,或控制更新频率的机制,除非该自动更新属于某项活动中必不可少的部分。
3.2.5 按需变更(AAA 级)严重
上下文的变更应仅由用户请求触发,或提供可关闭此类变更的机制。
解决方案:
- 在信息流中添加“加载更多帖子”按钮,将控制权交还给用户。
- 允许用户选择一次查看的帖子数量,这样希望体验无限滚动的用户仍可选择该模式。
简单地回应“如果您不喜欢此设置,请选用其他方案”是不可接受的——该设置完全可以变得更具可用性,并且应当如此。对我们许多客户而言,这既是道德要求,也是法律要求。
希望这有助于推动所需变更的落实。
3 个赞
Falco
(Falco)
2
这里说的页脚是指什么?
Discourse 默认不提供任何页脚,正如您在 Categories - Discourse Meta 等页面上看到的那样。
这是一个有意为之的设计决策,因为在无限滚动的网站上添加页脚会导致其无法访问。
5 个赞
感谢您的快速回复。
好的,目前将无限滚动信息流与页脚结合确实会造成功能不可访问的问题。
但这并非唯一的答案。我们可以在信息流上添加控制选项,让用户自行选择是加载更多帖子还是跳转至页脚。这一点是否有实现的可能?
页脚是一种非常常见的网页设计模式。提供一致且可识别的网页体验,是构建可用且易于理解体验的核心原则。
页脚支持以下成功准则(SC):2.4.5 多种方式(AA 级)
- 除非网页是某个流程的结果或步骤,否则应提供多种方式来定位一组网页中的某一页。
在特定页面上保留页脚(即不将其关闭)有助于支持成功准则 3.2.3 一致的导航(AA 级)
- 在一组网页中重复出现的导航机制,每次重复时应保持相同的相对顺序,除非由用户发起更改。
Discourse 的立场是否意味着:如果您选择了这种组合方式,那么由此产生的问题就需由您自行承担?
您是否了解是否有相关文档明确指出这一点:“在无限滚动网站上添加页脚会导致其无法访问”?
我目前处于一个棘手的境地,必须为我们运营的一些大型社区提出重新设计方案。因此,我需要彻底厘清这一问题的全貌。
2 个赞
Falco
(Falco)
4
我尚不熟悉该领域的现有研究,但毫无疑问,这是一个众所周知的事实:您不应该在无限滚动网站上放置页脚。这里有许多流行的例子,如 Facebook、Twitter、LinkedIn、Instagram、GMail 等。这些平台都没有页脚,而且它们的所有 Web 应用功能都可供数十亿用户使用。
这不在我们的路线图之中,我也不了解我们现有的任何付费客户提出过类似需求。
所以,如果我正确理解了整个情况,您的问题在于:
- 您的主要房产网站有页脚
- 您希望您的主要房产网站与 Discourse 实例的外观保持一致
- Discourse 在某些页面上不会有突出的页脚,因为这些页面采用无限滚动,页脚会被“滚走”
- 您不希望只在某些页面上放置页脚
我理解这是一个复杂的局面,但如果您想使用 Discourse,保持理性的态度来看,您只有两个选择:
-
放置页脚。
使用一个没有无限滚动的页面作为首页,例如 https://meta.discourse.org/categories,这样页脚就会显著展示,而无需担心它在 /latest 路由中无法访问。
-
不放置页脚。
我们的 discourse.org 页面有页脚,我们的博客也有。但在这里我们没有使用相同的页脚。许多公司也是如此,反之则可能是在“方枘圆凿”,强行适配并不合适的方案。
9 个赞
我代表一部分现有的付费客户。此外,正如我在最初帖子中提到的,还有其他讨论此组合及担忧的帖子,但均以与您最近的回复类似的方式被驳回。
这并非我个人的问题。这是许多社区正在经历的无障碍功能缺失,我原本希望团队愿意着手解决。
我们将继续使用 Discourse,并考虑自行构建一些定制解决方案,因为目前的路线图与我们的需求相去甚远。
3 个赞
考虑到根本没有页脚,你是否可能找错了方向?
或许你可以在页面顶部添加一段文字,说明这是一个没有页脚的无限滚动页面。
1 个赞
冒着有点偏颇的风险,我认为将 Discourse 完全归类为网页并不完全公平。
它是一个 Web 应用,因此模糊了网页与应用之间的界限。
如果我将它视为一个应用,情况是否会有显著不同?
以 PWA 方式打开时,它看起来相当可信地表现得像一个应用。
如果在 iOS 邮件应用中打开,页脚在哪里?
(好吧,底部浮动面板上确实有一些基本控件,但 Discourse 在 Hub 模式下也是如此。)
Apple 是否因为没有页脚而受到指责?
那 Gmail 呢?
为什么 Gmail 和邮件应用对电子邮件采用无限滚动是可行的,但在主题列表方面却行不通?它们在语义上难道不是非常相似吗?
如果 Gmail 或 iOS 邮件的开发者引入一个“加载更多邮件”的按钮,用户会感到高兴吗?
他们的无障碍专家为何得出无限滚动在这两个应用中是可行的结论?
那么,这些指南在这种情况下是否真的适用?
6 个赞
https://thepavilion.io/ 上的论坛提供了一个额外的页脚,可供您参考灵感。它在 iOS Safari 上运行良好,但在 iOS Discourse 应用中表现稍差(或至少表现不同)。
2 个赞