本文主要是介绍优先考虑 Web 可访问性的清单，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

优先考虑 Web 可访问性的清单

本着透明的精神，我并不总是优先考虑可访问性。这并不是说我故意将应用程序构建为不可访问，而是说这通常是事后才想到的——我需要在最后“解决”的问题。正因为如此，我从来没有花足够的时间确保用户界面的所有部分都可供不同能力的用户访问。随着时间的推移，我意识到从跳跃开始让它成为我开发过程中自然的一部分是多么重要。

简而言之，网络上的可访问性是指 每个人 成功感知、操作、理解和访问网站或网络应用程序。残障人士使用辅助技术——屏幕阅读器、屏幕放大器、盲文显示器、语音控制等等——来访问网络。

Categories of differently-abled people (source: Microsoft’s inclusive design kit)

在深入研究之前，我们将稍微了解一下幕后情况。当浏览器加载网页时，会发生几件事。其中之一就是创造了所谓的 可访问性树 — 浏览器获取 DOM 树并将其转换为辅助技术可以理解的版本。可访问性树由网页上元素的名称、角色、值和状态（以及其他属性）组成。屏幕阅读器等技术将参考此树将信息传递给其用户。

Chrome’s Accessibility Tree (within Developer tools) showing the accessibility data for a button

为确保网站开发人员遵守可访问性规则， WCAG （Web 内容可访问性指南）是多年前推出的。本文以易于遵循的清单格式重点介绍了其

✔️ 你在使用语义 HTML 吗？

默认， HTML 是可访问的 .然而，一个网站变得越复杂——就像现在的情况一样——就越需要确保它仍然可以访问。使用语义 HTML 奠定了基础。

语义元素 ( 标题 , 页脚 , 主要的 , 在旁边 , 文章 , 按钮 , 导航 , 菜单 引用 , 时间 ，仅举几例）为网页引入含义，这意味着辅助技术能够建立地标区域并识别页面的布局和部分。

“开发语义网站可以解决 50% 以上最常见的可访问性问题。” — 莱昂纳多·格拉特罗

Semantic vs Non-semantic code

在某些情况下，可能不存在需要实现的语义元素——例如，构建下拉菜单。另一种方法是创建一个自定义的非语义组件，它有可能影响可访问性。这就是 ARIA 的用武之地（稍后讨论）。

更多关于语义： HTML 语义备忘单 .

✔️ 每个元素都有名称吗？

正如人们通过名字来称呼一样，网络元素在可访问性方面也是如此。元素的名称（也称为“可访问名称”）是屏幕阅读器在用户浏览网站时向用户宣布的值之一。

元素从不同的来源获取其默认的可访问名称：

• 图像名称来自 alt 属性。
• 按钮名称来自按钮的文本内容（或来自封闭图像的 alt 值，如果存在）。
• 表名来自 title 属性。
• 表单输入名称来自占位符、关联标签或标题属性。

以下是三个 Web 元素的一些示例，随后是每个元素的 MacOS 屏幕阅读器公告的屏幕截图：

 <button class="button">设置</button>

Screen reader announcement for a button

 <a href="/settings/labels">管理标签</a> 

Screen reader announcement for a link

 <form role="search">  
 <label for="q">搜索：</label>  
 <input type="text" id="q" name="q" />  
 </form>

Screen reader announcement for a form with a search field

有时，需要明确地为元素指定其可访问的名称。以下是两个示例场景：

• 需要为视障用户提供额外上下文的“阅读更多”链接
• 没有文字的图标按钮

Icon buttons without text

咏叹调来救援！

如果您向上滚动到文章开头的 Chrome 辅助功能树的屏幕截图，您会注意到标题为“ARIA 属性”的部分。

ARIA（可访问的富 Internet 应用程序）是一组角色、状态和属性，可以添加到元素中以指定其行为方式。

这 咏叹调标签 属性将覆盖元素的可访问名称。

 <button class="button" aria-label="Shopping Cart">  
 <svg>  
 ...  
 </svg>  
 </button> <button aria-label="Read more about the blog post on global travel">  
 阅读更多  
 </button>

Button’s accessible name will come from its aria-label — “Shopping Cart”

需要注意的关键事项：

• 所有图像都应该有一个 alt 属性。
• 如果图像纯粹是装饰性的（例如，帮助按钮旁边的问号图标或搜索输入中的放大镜图标），则替代文本应该是空字符串（这可以防止屏幕阅读器宣布冗余元素）。
• 如果图像不是多余的并且有目的，则替代文本应准确描述 图像是什么 或者在某些情况下， 图像的作用 .
• 所有 HTML 表单输入都应具有关联的描述性标签以增强可访问性。

所以很明显，一个没有名字的元素会影响用户的体验。检查可访问性树以确保元素具有正确的命名将增加上下文屏幕阅读器提供给用户的数量。

有关可访问名称的更多信息： 名字里有什么？

✔️ 标题是否按层次顺序排列？

一些辅助技术用户更喜欢使用标题来导航页面，尤其是在具有大量内容的网站上，例如 Wikipedia。标题应具有正确的层次结构（即 <h3> 必须先到 <h4> ) 让用户了解页面内容的结构。

标题也应该尽可能简洁和具有描述性，以正确说明它们介绍的内容。

标题元素应该按降序排列，不要跳过一个级别，这意味着 h4 应该只在 h3 之后。跳过标题级别会导致屏幕阅读器用户怀疑是否缺少内容——WCAG

按大小而不是按级别排序标题可能很诱人。在这种情况下，CSS 实用程序类可用于使元素在视觉上看起来更小或更大，而不管它们的标题级别如何。

有关标题层次结构的更多信息： 可访问的标题结构

✔️ 您的内容是否具有逻辑标签顺序和可见的焦点指示符？

并非所有用户都使用鼠标或触控板。有些人必须依靠键盘，而另一些人则选择。无论如何，确保这组用户能够成功浏览网页应该是一个优先事项。

HTML 元素要么是展示性的（div、span、section、article），要么是交互式的（a、button、input、select、textarea）。默认情况下，交互式元素是可聚焦的。键盘用户将单击 Tab 键以从一个可聚焦元素跳转到下一个。

用户在页面中 tab 的顺序是基于 DOM 的顺序，而 DOM 的顺序是基于 HTML 标记的顺序。因此，优先考虑如何编写代码很重要，因为它将决定键盘用户如何浏览您的网站。例如，如果您的 UI 应该在左侧显示文章内容，并且在右侧显示文章标题，那么您的 HTML 应该以正常顺序编写，文章标题首先出现，文章内容其次。然后可以使用 CSS 来调整页面的视觉外观。

也可以使用更改页面选项卡顺序 表索引 — 此属性确定元素将落在选项卡流中的哪个位置。默认 表索引 交互元素的值为 0。值 -1 的元素将从选项卡流中删除，而值为 1 的元素将优先于其他元素。后者应该避免，因为它可能会影响用户在页面上的导航流程。

 <div tabindex="1">我将在所有其他元素之前专注</div> <div tabindex="0">我是默认</div> <div tabindex="-1">我永远不会成为焦点</div>

需要注意的关键事项：

• 确保用户需要与之交互的任何元素，尤其是下拉菜单等自定义控件，都有 表索引 值为 0。否则，键盘用户将永远无法访问它。
• 如果一个元素在视觉上是隐藏的，但可能在某些时候被用户交互（例如一个弹出模式），它应该被设置为 显示：无 或者 可见性：隐藏 以防止聚焦，直到它变得可见。
• 如果一个元素在视觉上是隐藏的，并且永远不会涉及用户的任何交互，则应该给它一个 表索引 值为 -1 以将其完全从焦点流中删除。
• 当用于交互式控件时，非语义元素无法通过键盘访问（例如，使用 <div> 创建一个按钮），并且需要编写一些 Javascript 才能访问。另一方面，语义元素具有内置的键盘可访问性。

那么，键盘用户在浏览页面时如何知道哪些元素处于焦点位置呢？

作为 Sara Soueidan 写道 ：

键盘用户的光标等价物是焦点指示器。

删除浏览器默认焦点指示器（使用 大纲：无 ) 而不用另一个替换它会使站点无法访问。今天，除了 ：重点 , 大多数浏览器都支持 :focus-visible 当元素处于焦点并且用户的输入是键盘时将应用伪类。

The focus indicator is displayed on the “Paid Courses” menu item via a keyboard

这里是如何使用 :focus-visible 来自 MDN 的文档：

 。按钮 {  
 边距：10px；  
 边框：2px 纯深灰色；  
 边框半径：4px；  
 } .button:焦点可见{  
 /* 支持 :focus-visible 时绘制焦点 */  
 轮廓：3px 纯深天蓝色；  
 轮廓偏移：3px；  
 } @supports not selector(:focus-visible) {  
 .button.with-fallback:focus {  
 /* 没有 :focus-visible 支持的浏览器的后备 */  
 轮廓：3px 纯深天蓝色；  
 轮廓偏移：3px；  
 }  
 }

更多关于焦点指标：

• 设计可访问的、符合 WCAG 的焦点指示器的指南
• WCAG 焦点指标指南

✔️ 您是否正确使用 ARIA？

正如我们在上面看到的，ARIA 允许您修改元素呈现给辅助技术的方式。

您可以使用 ARIA 来定义元素的角色，例如 角色="对话框" ，或设置其状态，例如 咏叹调检查=“真” .您还可以使用它来使自定义控件易于访问。例如，如果您选择创建复选框而不是使用 HTML 的本机复选框元素，则需要添加 ARIA 状态和属性以使您的复选框可用且可访问。

然而，尽管 ARIA 很有用，但它并不总是必需的。应尽可能使用语义标记。

更多关于咏叹调： 什么时候应该使用 ARIA

✔️ 您是否让用户知道动态内容何时发生变化？

想象一个视障用户在网站的客户服务聊天小部件上发送消息，但在收到回复时却没有意识到？

如果您的网站上有任何对用户体验至关重要的时间敏感通知，您应该探索使用 咏叹调现场 .此属性可以添加到任何元素，并允许网站开发人员确定屏幕阅读器应如何通知用户网页上的更改。

• 咏叹调直播=“关闭” : 不会发布任何公告（“关闭”是默认值）。
• aria-live="礼貌" ：只有在用户完成一个过程后才会发布公告，即用户不会被打断。
• aria-live="断言" : 用户将被打断，因此可以进行公告。

✔️您是否仔细选择颜色？

很多时候，当谈到颜色时，我把美学放在了可访问性之上，却没有意识到这一点，在这个过程中忽略了一大群人。

随着意识的提高，盲人或视力低下的用户会得到更多的考虑。这意味着优先考虑以下事项：

• 确保所有文本与其背景具有适当的对比度。 WCAG 期望网站的背景与文本的对比度至少为 4.5:1 .

Chrome 的颜色对比工具，显示所选颜色通过（左）和失败（右）对比度检查

• 包括用于描述不同颜色交互状态的替代文本。例如，错误、成功或警告状态。
• 使用与周围元素或背景具有足够对比度的焦点指示器。
• 尽管这与颜色无关，但重要的是还要考虑其他 UI 元素，如字体大小、行高和字母间距，并考虑内容在网站上的感知程度。

更多关于颜色： 这就是为什么你不应该使用纯黑色作为文本或背景 .

Web 可访问性是一个比本文所涵盖的更广泛的主题。然而，当我开始以上述所有方式优先考虑它时，它导致我的观点发生了重大转变，促使我重新评估我构建用户界面的方式，并最终让我成为一个更有思想的开发人员。

有用的资源：

• 构建更易于访问的前端的实用技巧
• A11y 项目
• 隐藏内容以获得更好的 a11y
• 跳过链接
• Pa11y — 自动化的可访问性测试工具
• 谷歌灯塔

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/35166/21371400

这篇关于优先考虑 Web 可访问性的清单的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！