2020 年 Web 开发人员的 7 个决心
这篇文章最初是通过Ladies of Code Advent Calendar分享的
新年伊始往往是反省和设定目标的时刻,如果您在工作内外帮助制作 Web 应用程序,那么我有 7 个决议供您考虑。
这些非常容易实现的目标将帮助您重新调整 Web 开发方法,将可访问性考虑放在核心位置。
本文中的 7 项决议将涵盖:
- 使用 a11y 插件增强你的 linting
- 选择一个扩展程序来定期检查浏览器中的代码
- 与屏幕阅读器交朋友,至少学习这 3 项技能
- 利用鼠标/触控板度假
- 审核您的标题级别
- 熟悉单页应用程序带来的挑战
- 改变你对“完成”的定义
1. 将 A11y-Linting 集成到你的项目中
如果您从事前端开发,您很可能已经在项目中使用了ESLint。它是一款非常棒的工具,可以确保在将代码发布到生产环境之前尽早发现常见的代码错误。
其他插件可以帮助 lint 工具检测可访问性问题,其中一个很好的工具是elsint-plugin-jsx-a11y。它可以检查 linter 可以发现的常见可访问性问题,例如:
- 确保表单输入具有适当的标签和 ID
- 图像的适当
alt
属性,包括检查alt
文本中常见的质量问题(例如重复使用“图像...”等词语) - 不恰当地使用
tabIndex
使用此jsx-a11y
插件可以为您构建一个安全网,让您在查看浏览器之前就能发现代码问题。与其他 ESLint 规则一样,您也可以设置 CI 管道,使其在问题未得到解决时失败,这可以帮助您节省在代码审查中查找此类错误的时间。
2. 选择用于在浏览器中检查代码的扩展程序
浏览器扩展程序可以发现许多可访问性问题,并且不仅会在页面上清楚地突出显示该问题,而且通常还可以为您建议解决问题的方法!
这些工具尤其适用于解决以下可访问性问题:
- 确保足够的色彩对比度
- 确保所有图像都具有
alt
属性 - 验证标题级别和语义 HTML 是否已得到适当使用
最受欢迎的工具是Axe和WAVE。两者都非常出色 - 尝试一下,看看您更喜欢哪个!
在将任何代码提交审核之前先与他们核对一下,这样您就已经开始将可访问性检查作为工作流程中更不可或缺的一部分。
3. 与屏幕阅读器交朋友
熟悉屏幕阅读器的工作方式以及用户通常如何使用它们浏览网页对于在整个开发方法中正确考虑可访问性至关重要。
哪个屏幕阅读器
根据最新的WebAIM 屏幕阅读器用户调查,这些免费选项将会很好用:
- Mac 用户可以轻松使用内置的 VoiceOver(使用
cmd
+打开或关闭F5
) - Windows 用户可以下载并使用NVDA
需要学习的基础知识
作为基本的起点,学习使用您选择的屏幕阅读器执行以下操作:
- 阅读并逐步浏览页面内容- 这将帮助您检查页面的各个部分以及它们如何向屏幕阅读器用户公布。
- 浏览标题级别- 这一点至关重要,因为大多数屏幕阅读器用户在进入特定部分之前都会以这种方式“浏览”您的内容
- 通过 Tab 键浏览交互项目- 这是标准的键盘导航,但请在打开屏幕阅读器的情况下进行此操作,并在执行此操作时与这些项目进行交互(例如,单击按钮和链接)
熟悉屏幕阅读器并定期用它检查代码将有助于您在接手一项工作时自然地考虑“这将如何与屏幕阅读器配合使用?”。
如果你使用 Mac,你可能会发现我之前的帖子很有帮助:

3 个快速任务助您熟悉屏幕阅读器(Mac 上的 VoiceOver)
Suzanne Aitchison ・ 19 年 12 月 1 日 ・ 阅读时长 4 分钟
4. 告别鼠标/触控板
与步骤 3 类似,了解用户如何使用键盘浏览网页。以下是一些需要了解的关键事项:
- 您应该能够仅使用以下
tab
键来浏览页面上的所有交互项目(按钮、链接、表单输入等) - 当前焦点项目应具有清晰的视觉指示(例如蓝色边框)
- 非交互式项目永远不应该通过
tab
按键获得焦点 - 在页面中按 Tab 键切换时,焦点的放置顺序应该合理。通常,这意味着焦点会按照视力正常的用户所期望的顺序(例如从上到下)移动,而不是随意跳转。
欲了解更多详细信息,请查看此帖子:
仅使用键盘导航定期检查您的工作将有助于标记可访问性问题,例如:
- HTML 元素以非逻辑顺序声明(导致 Tab 键顺序不按逻辑顺序排列)
- 交互式项目未获得焦点(例如,用户应该能够点击的卡片等自定义组件)
- 由于品牌/设计原因,默认焦点状态被移除,但从未被取代
5. 审核你的标题级别
正如步骤 3 中强调的那样,屏幕阅读器用户利用标题级别来快速浏览和略读内容,其方式与视力正常的用户非常相似。快速审核标题级别可以带来很大的不同,并有助于向更广泛的用户展示有用的内容。
一些简单的规则:
- 每个页面都应该有一个
h1
清晰描述页面目的的元素 - 标题级别应该每次只增加一级,例如
h2
→h3
在本文中了解有关处理标题级别的更多详细信息:
6. 了解单页应用程序中的潜在问题
这本身是一个很大的话题,但如果您使用利用客户端渲染的框架(例如 React 或 Vue),熟悉这些潜在的陷阱将对您的 Web 应用程序的可访问性产生巨大的好处。
潜在的陷阱和资源
路线变更:
- 当客户端渲染的应用中的路由发生改变时,屏幕阅读器用户通常不会意识到页面内容已经改变,并且可能会“丢失”
- 如果用户单击导致客户端呈现的路线发生变化的链接,则焦点通常会留在不再可见的链接上,这可能会非常令人困惑!
您可以在Up Your A11y:在 React 中处理对路由变化的关注中找到一些进一步的探索和纠正此问题的方法。
页面标题:
- 在单页应用中,除非明确管理,否则页面标题永远不会更改。这对于屏幕阅读器用户来说不太方便,因为他们可能打开了多个标签页或窗口,并且想知道当前位于哪个页面。
您可以在我之前的帖子中找到有关如何处理此问题的一些探索和提示:

单页应用程序中的页面标题和 A11y(尤其是 React 和 Vue)
Suzanne Aitchison ・ 2019 年 9 月 16 日 ・ 阅读时长 3 分钟
7.改变你对“完成”的定义
在进行代码审查之前,这最后一步也许是最重要的:
- 使用配置为 a11y 检查的 ESLint 进行检查,并纠正任何错误
- 通过上面提到的浏览器内验证工具之一运行您的工作 - 是否存在需要修复的问题?
- 打开屏幕阅读器并快速浏览,包括按标题级别扫描
- 通过选项卡浏览您刚刚创建的内容 - 它是否按预期运行?
- 如果您的工作触发了单页应用程序中的路由更改 - 请仔细检查路由更改是否已考虑到可访问性
如果您在工作中尽可能多地完成这些步骤,那么您就有望在 2020 年创建可访问的 Web 应用程序!
你觉得这篇文章有用吗?请给我买杯咖啡,这样我就可以继续创作了🙂
文章来源:https://dev.to/s_aitchison/7-resolutions-for-web-developers-in-2020-3eh