autorenew

无障碍测试 | Accessibility Testing

辅助功能测试确保每个人都可以使用移动和网络应用程序,包括视力或听力障碍以及其他身体或认知障碍等残疾人。

相关术语

有关辅助功能测试的问题吗?

基础知识和重要性

什么是可访问性测试?

辅助功能测试 是确保软件和 Web 应用程序可供患有各种残疾的人使用的过程,包括视觉、听觉、身体、言语、认知、语言、学习和神经障碍。这种形式的测试检查应用程序是否可以被使用屏幕阅读器、盲文终端和替代输入设备等辅助技术的个人有效地操作和理解。 辅助功能测试关键方面 包括:

  • 导航性:用户可以使用键盘或辅助设备在应用程序中导航吗?
  • 可读性:内容对于有视觉障碍的用户来说是否可读且易于理解?
  • 兼容性:该应用程序是否可以与各种辅助技术配合使用?
  • 语义 HTML:HTML 元素是否用于传达含义和结构?
  • 动态内容:动态内容可以通过屏幕阅读器访问吗?
  • 视觉设计:对于弱视用户来说,文本和背景之间是否有足够的对比度?
  • 多媒体:视频和音频内容是否可以通过字幕和文字记录来访问? 技术涉及自动化和手动测试方法。自动化工具可以扫描某些类型的问题,例如缺少替代文本或不正确的 ARIA 角色,而 手动测试 可能包括使用屏幕阅读器使用应用程序或仅通过键盘导航。 使用自动化工具检查图像替代文本的代码示例
  it('should have alt text for all images', () => {
    cy.get('img').each(($img) => {
      expect($img.attr('alt')).to.be.a('string').and.not.be.empty;
    });
  });

总之,辅助功能测试 是软件质量保证的关键组成部分,可确保包容性和法律合规性。

为什么可访问性测试很重要?

辅助功能测试 至关重要,因为它确保所有用户,包括残疾人,都可以有效地访问和使用软件产品。通过识别和解决可访问性障碍,它促进了包容性设计并增强了不同受众的用户体验。此类测试不仅是道德责任和用户倡导的问题,也是许多司法管辖区的法律要求,帮助组织遵守法律并避免潜在的法律后果。 此外,辅助功能测试 可以带来改进的 SEO,因为搜索引擎更喜欢可访问的网站,从而有可能增加网站的可见性和覆盖范围。它还鼓励最佳编码实践,从而产生更干净、更易于维护的代码。通过在开发过程的早期整合可访问性考虑因素,公司可以减少以后改造可访问性功能所需的成本和工作量。 总之,辅助功能测试 很重要,因为它:

  • 促进包容性确保软件可供具有广泛能力的人使用。

  • 履行法律义务 ,帮助组织遵守无障碍标准并避免法律问题。

  • 增强搜索引擎优化 ,有可能提高软件的可见性和覆盖范围。

  • 鼓励更好的编码实践 ,从而带来更可维护和更健壮的软件。 忽略辅助功能测试可能会导致用户群缩小、潜在的法律挑战以及错失产品改进的机会。

  • 促进包容性确保软件可供具有广泛能力的人使用。

  • 履行法律义务 ,帮助组织遵守无障碍标准并避免法律问题。

  • 增强搜索引擎优化 ,有可能提高软件的可见性和覆盖范围。

  • 鼓励更好的编码实践 ,从而带来更可维护和更健壮的软件。

可访问性测试的目标是什么?

辅助功能测试 的目标是确保软件产品可供各种能力和残障的人使用。这包括验证产品是否符合无障碍标准指南**,例如网络内容无障碍指南 (WCAG) 和第 508 条。通过这样做,它的目的是提供包容性的用户体验,让有视觉、听觉、身体、言语、认知、语言、学习和神经障碍等障碍的个人可以有效地导航互动访问内容辅助功能测试 还力求识别并消除可能阻止残疾人使用该产品的障碍,确保所有用户都平等地访问信息和功能。它涉及自动化工具手动技术的组合,以涵盖仅靠自动化可能无法捕获的各个方面。 最终的目标是维护法律和道德标准避免歧视,并通过让更广泛的受众接触到产品来扩大市场覆盖范围。这不仅仅是合规性的问题;这是关于拥抱多样性提高用户满意度

可访问性测试如何使用户受益?

辅助功能测试 通过确保软件产品可供各种能力和残障人士使用来使用户受益。这种包容性允许更广泛的受众与应用程序、网站或工具有效地交互,无论他们的身体或认知挑战如何。通过适应屏幕阅读器、盲文终端和语音识别软件等辅助技术辅助功能测试 有助于创建更公平的用户体验。 对于残障用户来说,辅助功能测试 可能意味着能够在线执行基本任务和面临重大障碍之间的区别。它实现了独立导航和交互,这对于个人自主和尊严至关重要。此外,它可以减少用户的挫败感提高用户的效率,因为他们可以访问和使用功能和信息而不会受到不必要的阻碍。 除了直接的用户利益之外,辅助功能测试 还可以为所有用户带来提高可用性。许多辅助功能(例如清晰的导航和可读字体)增强了整体用户体验。通过关注可访问性,开发人员可以无意中为更广泛的用户群改进设计和功能,从而打造出更加直观和用户友好的产品。 最后,辅助功能测试 可以帮助避免因不遵守无障碍法律和法规而可能产生的法律后果,确保该软件不仅具有包容性,而且符合法律规定。

不进行可访问性测试有什么影响?

不执行 辅助功能测试 可能会产生重大影响:

  • 排除用户:如果没有辅助功能测试,残障人士可能无法使用软件,从而有效地排除他们访问产品或服务。
  • 法律影响:不遵守《美国残疾人法案》(ADA) 或第 508 条等法律标准可能会导致诉讼和经济处罚。
  • 品牌损害:无法访问可能会损害公司的声誉,因为这表明缺乏对所有用户的考虑。
  • 市场覆盖范围缩小:忽视无障碍测试会限制潜在的用户群,因为残疾人代表了一个重要的市场领域。
  • 用户体验差:辅助功能问题可能会导致令人沮丧的用户体验,不仅对于残障用户,而且对于那些受到临时或情况限制的用户也是如此。
  • 成本增加:在开发后期或发布后识别和修复可访问性问题通常比在常规测试周期中解决这些问题更昂贵。 总之,忽视辅助功能测试 可能会产生道德、法律、财务和声誉后果,同时还会损害软件的整体质量和可用性。

标准和指南

可访问性测试的关键标准和指南是什么?

辅助功能测试 的主要标准和指南包括:

  • 网页内容无障碍指南 (WCAG):网页无障碍的主要国际标准,详细说明了如何使残障人士更容易访问网页内容。遵循最新版本(当前为 WCAG 2.1),并争取至少达到 AA 级合规性。

  • 可访问的富互联网应用程序 (ARIA):定义了一种使残障人士更容易访问 Web 内容和 Web 应用程序的方法。使用 ARIA 角色和属性来增强动态内容和复杂用户界面组件的可访问性。

  • 第 508 条:美国联邦法律要求联邦政府开发、采购、维护或使用的所有电子和信息技术均可供残疾人使用。如果您的软件将由联邦机构或承包商使用,请确保您的软件符合这些标准。

  • EN 301 549:欧洲数字无障碍标准,规定了 ICT 产品和服务的要求,以确保残障人士更容易使用它们。

  • ISO/IEC 40500:与WCAG 2.0相同的国际标准,提供稳定、可参考的技术标准。 进行辅助功能测试时,请遵守以下准则:

  • 尽可能自动化:使用自动化工具来捕获易于检测的问题,但请记住它们无法捕获所有内容。

  • 手动测试:通过手动检查补充自动化测试,特别是对于易于导航和理解等主观标准。

  • 用户测试:让真实的残疾用户参与测试,以获得有关可访问性的真实反馈。

  • 持续合规性:将 辅助功能测试 集成到您的持续集成/持续部署 (CI/CD) 管道中,以确保持续合规性。

  • 保持更新:随时了解可访问性标准和指南的更新,因为它们随着时间的推移而发展。

  • 网页内容无障碍指南 (WCAG):网页无障碍的主要国际标准,详细说明了如何使残障人士更容易访问网页内容。遵循最新版本(当前为 WCAG 2.1),并争取至少达到 AA 级合规性。

  • 可访问的富互联网应用程序 (ARIA):定义了一种使残障人士更容易访问 Web 内容和 Web 应用程序的方法。使用 ARIA 角色和属性来增强动态内容和复杂用户界面组件的可访问性。

  • 第 508 条:美国联邦法律要求联邦政府开发、采购、维护或使用的所有电子和信息技术均可供残疾人使用。如果您的软件将由联邦机构或承包商使用,请确保您的软件符合这些标准。

  • EN 301 549:欧洲数字无障碍标准,规定了 ICT 产品和服务的要求,以确保残障人士更容易使用它们。

  • ISO/IEC 40500:与WCAG 2.0相同的国际标准,提供稳定、可参考的技术标准。

  • 尽可能自动化:使用自动化工具来捕获易于检测的问题,但请记住它们无法捕获所有内容。

  • 手动测试:通过手动检查补充自动化测试,特别是对于易于导航和理解等主观标准。

  • 用户测试:让真实的残疾用户参与测试,以获得有关可访问性的真实反馈。

  • 持续合规性:将 辅助功能测试 集成到您的持续集成/持续部署 (CI/CD) 管道中,以确保持续合规性。

  • 保持更新:随时了解可访问性标准和指南的更新,因为它们随着时间的推移而发展。

什么是 WCAG?为什么它很重要?

WCAG(即 Web 内容可访问性指南)是一组旨在使残障人士更容易访问 Web 内容的建议。它是通过 W3C 流程与世界各地的个人和组织合作开发的,旨在为 Web 内容可访问性提供单一共享标准,以满足国际上个人、组织和政府的需求。 WCAG 很重要,因为它作为网络可访问性的全球基准,确保每个人都可以使用网站、应用程序和数字工具,包括那些有听觉、认知、神经、身体、言语和视觉障碍的人。遵守 WCAG 有助于消除阻碍残疾人互动或访问网站的障碍。当网站被正确设计、开发和编辑时,所有用户都可以平等地访问信息和功能。 遵循 WCAG 指南不仅是道德责任包容性的问题,也是许多司法管辖区的法律要求。不遵守规定可能会导致法律后果并损害组织的声誉。此外,遵守 WCAG 可以改善整体用户体验,并有可能增加受众范围,因为可访问的网站往往对 SEO 更友好,并且对所有用户(而不仅仅是残疾人)具有更好的可用性。

WCAG 合规性有哪些不同级别?

WCAG 合规性分为三个合规级别:

  • A 级:最基本的网络辅助功能。网站必须满足此级别,以免将残疾人群体排除在外。它包括为非文本内容提供文本替代品以及确保可以使用键盘进行导航等内容。
  • AA 级:解决残疾用户面临的最大和最常见的障碍。此级别引入了一些标准,例如为音频内容提供字幕并确保文本可读且易于理解。达到这一水平通常是许多组织和政府的法律要求。
  • AAA 级:WCAG 合规性的最高且最严格的级别。该级别包括更广泛的标准,以改善不同类型残疾人的无障碍环境。它包含所有 A 级和 AA 级要求,并增加了更多内容,例如为音频内容提供手语翻译并确保现场音频内容具有较低的背景噪音水平。然而,某些内容并不总是能够满足所有 AAA 级成功标准,因此这并不是完全合规的严格要求。 每个级别都建立在前一个级别的基础上,AAA 包括 AA 和 A 中的所有标准。在追求合规性时,请务必注意,AA 级通常是大多数网站的目标标准,因为它在提高可访问性和实际可实现性之间提供了平衡。

第 508 节是什么以及它与可访问性测试有何关系?

第 508 条是 1973 年《康复法案》的一部分,该法案要求联邦机构向残疾人士提供电子和信息技术 (EIT)。在软件 测试自动化 的背景下,第 508 条合规性意味着确保应用程序和网站可供患有一系列残疾的个人使用,包括视觉、听觉、身体、言语、认知、语言、学习和神经障碍。 为了遵守第 508 节,自动化测试应包括以下检查:

  • 键盘导航:确保所有功能都可以通过键盘命令操作,无需鼠标。
  • 屏幕阅读器兼容性:验证内容的结构是否适合屏幕阅读器可以正确解释和发音的方式。
  • 颜色对比度:测试文本和背景之间是否有足够的对比度,以帮助有视觉障碍的用户。
  • 图像的替代文本:检查所有图像是否都为无法看到图像的用户提供描述性替代文本。
  • 字幕和音频描述:确保多媒体内容为有听力或视觉障碍的用户提供字幕和描述。 自动化工具可以帮助识别一些第 508 条合规性问题,但 手动测试 对于完全确保可访问性也是必要的。 测试自动化 工程师应将自动和手动可访问性检查集成到他们的测试策略中,以涵盖第 508 节中概述的广泛要求。这种集成有助于创建包容性的用户体验,并减轻与不合规相关的法律和声誉风险。

ARIA 角色是什么以及它们如何在可访问性测试中使用?

ARIA 角色是可访问的富互联网应用程序规范的一部分,该规范定义了使残障人士更容易访问 Web 内容和 Web 应用程序的方法。 ARIA 角色提供有关功能、结构和行为的语义信息,允许辅助技术向用户传达适当的信息。 在 辅助功能测试 中,ARIA 角色用于:

  • 识别 UI 元素通过定义诸如屏幕阅读器之类的角色来使用辅助技术 button , dialog , menu , 和 progressbar

  • 沟通状态具有以下角色的 UI 元素 aria-expanded 对于可折叠内容或 aria-checked 对于复选框。

  • 定义结构具有以下角色的网络内容 navigation , main , complementary , 和 contentinfo 。 要测试 ARIA 角色:

  1. 验证正确实施使用自动化工具或手动检查来确定角色和属性。

  2. 确保角色匹配元素的功能(例如, role="button" 对于可点击的元素)。

  3. 检查动态变化在 ARIA 状态和属性中与用户交互。

  4. 使用屏幕阅读器确认角色和状态已正确宣布。 具有 ARIA 角色的按钮示例:

  <button role="button" aria-pressed="false">Toggle</button>

在此示例中,role="button" 传达元素的功能,aria-pressed 指示切换状态。 测试自动化 工程师 应将 ARIA 角色验证集成到他们的测试套件中,以确保 Web 应用程序可访问并为辅助技术提供必要的上下文。

  • 识别 UI 元素通过定义诸如屏幕阅读器之类的角色来使用辅助技术 button , dialog , menu , 和 progressbar

  • 沟通状态具有以下角色的 UI 元素 aria-expanded 对于可折叠内容或 aria-checked 对于复选框。

  • 定义结构具有以下角色的网络内容 navigation , main , complementary , 和 contentinfo

  1. 验证正确实施使用自动化工具或手动检查来确定角色和属性。

  2. 确保角色匹配元素的功能(例如, role="button" 对于可点击的元素)。

  3. 检查动态变化在 ARIA 状态和属性中与用户交互。

  4. 使用屏幕阅读器确认角色和状态已正确宣布。

工具和技术

可访问性测试常用哪些工具?

辅助功能测试 的常用工具包括:

  • Axe:一个可以集成到测试框架中的开源库。它可作为浏览器扩展和 CLI 工具使用。
    npm install axe-core --save-dev
  • WAVE(Web 可访问性评估工具):一套评估工具,可帮助作者使其 Web 内容更易于访问。它包括浏览器扩展和在线服务。
  • lighthouse :一种用于提高网页质量的开源自动化工具。它对性能、可访问性、渐进式 Web 应用程序等进行审核。
    lighthouse https://example.com --only-categories=accessibility
  • JAWS(通过语音获取工作):适用于 Windows 的屏幕阅读器,允许视障用户通过文本转语音输出或盲文显示器阅读屏幕。
  • NVDA(非可视化桌面访问):适用于 Windows 的免费开源屏幕阅读器。
  • VoiceOver:Apple Inc. 的 macOS 和 iOS 操作系统内置的屏幕阅读器。
  • 颜色对比度分析器:颜色对比度分析器 (CCA) 等工具可帮助您确定文本的易读性和视觉元素的对比度。
  • Tenon.io:一个 API 优先的自动化可访问性测试工具,可以集成到开发管道中。
  • Pa11y:一种自动可访问性测试工具,可从命令行运行 HTML CodeSniffer 以进行编程可访问性报告。
    pa11y http://example.com
  • Accessibility Insights:一种为可访问性测试提供指导和解决方案的工具,可作为浏览器扩展和 Windows 应用程序使用。 这些工具有助于自动检测辅助功能问题,然后解决这些问题,以确保软件产品可供各种残障人士使用。

  • Axe:一个可以集成到测试框架中的开源库。它可作为浏览器扩展和 CLI 工具使用。

    npm install axe-core --save-dev
  • WAVE(Web 可访问性评估工具):一套评估工具,可帮助作者使其 Web 内容更易于访问。它包括浏览器扩展和在线服务。
  • lighthouse :一种用于提高网页质量的开源自动化工具。它对性能、可访问性、渐进式 Web 应用程序等进行审核。
    lighthouse https://example.com --only-categories=accessibility
    pa11y http://example.com
  • Accessibility Insights:一种为可访问性测试提供指导和解决方案的工具,可作为浏览器扩展和 Windows 应用程序使用。

可访问性测试有哪些手动技术?

辅助功能测试 的手动技术涉及用户模拟辅助技术使用清单的组合,以确保软件可以由各种残疾人使用。以下是一些技巧:

  • 键盘导航:仅使用键盘导航应用程序,以确保无需鼠标即可访问和使用所有交互元素。
  • 屏幕阅读器测试:使用 NVDA 或 JAWS 等屏幕阅读器来像视障用户一样体验应用程序。检查元素、顺序和上下文的阅读是否正确。
  • 颜色对比度分析:使用颜色对比度分析器等工具手动检查颜色组合,以确保色觉缺陷的用户获得足够的对比度。
  • 手动代码[检查](/zh-cn/wiki/检查/):查看 HTML/CSS 代码的语义结构、正确使用辅助技术所依赖的标题、标签和角色。
  • 缩放和放大:在不同级别的缩放和放大倍率下测试应用程序,以确保内容保持可读性和功能性。
  • 内容可读性:评估内容的可读性,确保语言清晰简单,这对有认知障碍的用户有利。
  • 焦点管理:确保焦点顺序符合逻辑且可见,这对于通过键盘或辅助技术导航的用户至关重要。
  • 与残疾参与者进行用户测试:让残疾用户参与测试过程,以获得有关应用程序可访问性的直接反馈。 这些手动方法通过涵盖需要人类判断和视角的方面来补充自动化测试,而自动化工具经常会忽略这些方面。

如何在可访问性测试中使用自动化工具?

自动化工具通过快速扫描网页和应用程序以查找常见的可访问性问题来简化辅助功能测试。它们可以集成到 CI/CD 管道中,以确保持续符合可访问性标准。 axe-coreWAVElighthouse 等工具提供 API 以及用于与 seleniumJestCypress 等测试框架集成的插件。 使用自动化工具来:

  • 检测代码级问题:识别缺少替代文本、ARIA 角色使用不当以及颜色对比度不足等问题。
  • 运行回归测试:确保新代码不会引入可访问性回归。
  • 生成报告:为技术和非技术利益相关者创建详细报告。
  • 优先修复:突出显示对用户影响最大的关键问题。 将 辅助功能测试 工具与测试框架集成的示例:
  const axe = require('axe-core');
  const { browser, by, element } = require('protractor');
  describe('Accessibility checks', () => {
    it('should analyze the page', async () => {
      await browser.get('https://example.com');
      const results = await axe.run();
      expect(results.violations.length).toBe(0, 'Accessibility violations found');
    });
  });

自动化工具并不能取代 手动测试 或对残疾人进行用户测试,但它们是识别和减轻可访问性障碍的宝贵的第一步。它们有助于维护可访问性基线并减少需要手动审核的问题数量。

自动化可访问性测试工具有哪些限制?

自动化 辅助功能测试 工具有几个限制:

  • 误报/Negatives:工具可能会报告不是实际障碍的问题(误报)或错过真正的问题(误报)。
  • 上下文理解:他们缺乏理解上下文和含义的能力,这对于某些可访问性检查至关重要。
  • 用户体验:自动化工具无法全面评估用户体验,包括残疾用户的导航难易度和理解能力。
  • 动态内容:他们经常会遇到因用户操作而变化的动态内容或复杂的 JavaScript 交互。
  • 视觉设计和可读性:工具可能无法准确判断视觉设计元素,例如对比度和可读性,尤其是在图形内容中。
  • 键盘导航:虽然某些工具可以模拟键盘导航,但它们可能无法有效识别仅使用键盘的用户遇到的所有问题。
  • 屏幕阅读器兼容性:需要使用实际的屏幕阅读器进行测试,因为工具无法复制屏幕阅读器用户的体验。
  • 辅助技术差异:辅助技术种类繁多,自动化工具无法测试与所有技术的兼容性。
  • 全面测试:没有一个工具可以涵盖所有可访问性准则;彻底的测试通常需要多种工具和手动测试。 为了减轻这些限制,请将 自动化测试手动测试 以及针对残障人士的 用户测试 结合起来。这种方法提供了对可达性的更准确和全面的评估。

如何测试不同类型的残疾?

针对不同类型的残疾的测试涉及模拟具有各种缺陷的个人的用户体验。这包括视觉、听觉、运动和认知障碍。以下是一些策略:

  • 视觉障碍:使用 NVDA 或 JAWS 等屏幕阅读器来导航您的应用程序。确保所有内容均可读,并且无需视觉提示即可进行导航。使用不同的对比度设置和字体大小进行测试,以适应弱视用户的需求。
  • 听觉障碍:验证所有音频内容是否都有替代文本,例如字幕或文字记录。测试应用程序在没有声音的情况下是否可用,并且没有仅通过音频传达重要信息。
  • 运动障碍:仅使用 Tab 键、Enter、空格和箭头键测试键盘导航。确保所有交互元素均可通过键盘访问和操作。考虑无法使用鼠标或精细运动控制有限的用户的需求。
  • 认知障碍:简化和构建内容以支持有认知障碍的用户。测试一致的导航和可预测的交互。使用清晰的语言并在适用的情况下提供延长时间限制的能力。 将辅助技术用户偏好纳入您的测试环境中,以模拟不同的残疾场景。这包括语音控制软件、替代输入设备以及修改显示设置的浏览器扩展。 请记住,虽然自动化工具可以捕获许多可访问性问题,但它们无法检测残疾人用户体验的所有细微差别。 手动测试 与真实用户或可访问性专家一起进行综合评估至关重要。

实施和最佳实践

实施可访问性测试的最佳实践有哪些?

实施 辅助功能测试 的最佳实践包括:

  • **尽早集成辅助功能测试**在开发过程中发现并解决问题的成本较低。

  • 教育你的团队关于无障碍原则和包容性设计的重要性。

  • 创建清单基于 WCAG 指南,确保满足所有无障碍要求。

  • 使用自动化和手动测试的组合涵盖可访问性问题的广度和深度。

  • 自动化重复任务例如颜色对比检查和键盘导航,以节省时间和资源。

  • 进行用户测试与残障人士一起获得有关您产品的可访问性的真实反馈。

  • 定期审查和更新您的可访问性测试跟上新的标准和技术。

  • 文档可访问性问题提供清晰的描述、屏幕截图或视频来帮助开发人员理解和解决问题。

  • 确定问题的优先顺序基于它们对用户的影响和修复的复杂性。

  • **在完成的定义中包含辅助功能测试**确保功能在可访问之前才被视为完整。

  • 利用浏览器开发工具和可访问性插件,可快速识别开发过程中的问题。

  • 及时了解法律要求和行业标准,以确保合规性并避免潜在的法律后果。 通过遵循这些实践,您可以创建更具包容性的产品并改善残障人士的整体用户体验。

  • **尽早集成辅助功能测试**在开发过程中发现并解决问题的成本较低。

  • 教育你的团队关于无障碍原则和包容性设计的重要性。

  • 创建清单基于 WCAG 指南,确保满足所有无障碍要求。

  • **结合使用自动化和手动测试**涵盖可访问性问题的广度和深度。

  • 自动化重复任务例如颜色对比检查和键盘导航,以节省时间和资源。

  • 进行用户测试与残障人士一起获得有关您产品的可访问性的真实反馈。

  • 定期审查和更新您的可访问性测试跟上新的标准和技术。

  • 文档可访问性问题提供清晰的描述、屏幕截图或视频来帮助开发人员理解和解决问题。

  • 确定问题的优先顺序基于它们对用户的影响和修复的复杂性。

  • **在完成的定义中包含辅助功能测试**确保功能在可访问之前才被视为完整。

  • 利用浏览器开发工具和可访问性插件,可快速识别开发过程中的问题。

  • 及时了解法律要求和行业标准,以确保合规性并避免潜在的法律后果。

如何将可访问性测试纳入软件开发生命周期?

辅助功能测试 纳入软件开发生命周期 (SDLC) 涉及将其集成到每个阶段,以确保从一开始和整个过程就考虑可访问性。 在需求收集阶段,根据 WCAG 和第 508 条等标准定义可访问性标准。指定所需的合规级别并包括满足残疾人需求的用户故事。 在设计阶段,使用线框和原型来评估可访问性考虑因素,例如颜色对比度和导航顺序。可以尽早使用色彩对比度分析仪等工具,以避免以后的设计返工。 在开发阶段,实现语义 HTML 和 ARIA 角色以增强可访问性。开发人员应使用自动化工具来运行初步检查并在编码时解决问题。例如:

  // Example of an automated test using Axe-core
  const { AxePuppeteer } = require('axe-puppeteer');
  async function checkAccessibility(page) {
    const results = await new AxePuppeteer(page).analyze();
    console.log(results);
  }

在测试阶段,在 测试用例 中包含可访问性并执行自动和手动测试。自动化测试可以发现一系列问题,但 手动测试 对于从人类角度评估可用性至关重要。 在部署阶段,执行最终的可访问性审查和验证,以确保没有引入新问题。 部署后,与用户建立反馈循环,以发现可能遗漏的任何可访问性问题,并保持对用户需求的响应。定期更新您的测试套件 和工具,以适应不断发展的标准和技术。 通过将可访问性嵌入到 SDLC 中,您可以确保持续考虑它,从而降低成本高昂的返工风险并确保产品更具包容性。

如何确保持续的无障碍合规性?

为了确保软件 测试自动化 中持续的可访问性合规性:

  • 集成可访问性检查进入您的常规测试套件。使用 Axe 或 Wave 等工具自动执行这些检查。

  • 实施持续集成 (CI) 流程,包括可访问性测试,确保它们在每次构建时都运行。

职位: 可访问性_测试: 运行:ubuntu-latest 步骤:

  • 名称:运行可访问性检查运行: npm 运行测试:可访问性

  • Adopt a shift-left approach, incorporating accessibility testing early in the development cycle to catch issues sooner.

  • Update your test cases regularly to cover new accessibility standards and guidelines as they evolve.

  • Educate your team on accessibility importance, encouraging developers to write accessible code from the start.

  • Conduct periodic manual audits to catch issues that automated tools might miss.

  • Use real user metrics (RUM) to monitor how actual users interact with your application, which can help identify accessibility barriers.

  • Engage with users with disabilities for feedback and incorporate their insights into your testing strategy.

  • Stay informed about legal requirements and industry best practices to ensure compliance with the latest standards. By embedding these practices into your development and testing workflows, you can maintain a high level of accessibility compliance over time.

  • 集成可访问性检查进入您的常规测试套件。使用 Axe 或 Wave 等工具自动执行这些检查。

  • 实施持续集成 (CI) 流程,包括可访问性测试,确保它们在每次构建时都运行。

需要注意哪些常见的可访问性问题?

测试期间要查找的常见可访问性问题包括:

  • 替代文本:缺失 alt 图像文本,这对于屏幕阅读器用户至关重要。

  • 键盘导航:无法单独使用键盘导航网站,这会影响行动不便的用户。

  • 颜色对比度:文本和背景之间的对比度不足,导致有视觉障碍的用户难以阅读内容。

  • 焦点指示器:缺乏可见的焦点指示器,这对于依赖键盘导航的用户来说至关重要。

  • 表单标签:屏幕阅读器用户难以解释的未标记表单。

  • ARIA 误用:ARIA 属性不正确或缺失,导致屏幕阅读器体验不佳。

  • 基于时间的媒体:缺少音频和视频内容的字幕或文字记录。

  • 可调整大小的文本:在不损失内容或功能的情况下无法调整或缩放的文本。

  • 语言识别:缺少告知屏幕阅读器有关文本语言的语言属性。

  • 错误识别:错误消息传递不足,无法指导用户纠正错误。

  • 一致的导航:导航顺序或命名不一致,导致依赖模式的用户感到困惑。

  • 动态内容更新:动态内容更新发生时缺乏屏幕阅读器的警报。 这些问题可以通过自动化工具和手动测试的组合来识别,以确保全面的可访问性评估。

  • 替代文本:缺失 alt 图像文本,这对于屏幕阅读器用户至关重要。

如何使网站更易于访问?

为了增强网站的可访问性:

  • 使用语义 HTML构建内容,确保标题等元素( <h1><h6> ), 列出 ( <ul> , <ol> ) 和按钮 ( <button> )被正确使用。

  • 提供替代文本alt 属性)用于非文本内容(例如图像)。

  • 确保足够的对比度文本和背景颜色之间。

  • 通过键盘使用所有功能通过使用可聚焦元素并管理焦点顺序。

  • 创建标签对于交互元素,使用 <label> 元素或 aria-labelaria-labelledby

  • 避免或提供导致癫痫发作的内容的替代品 ,如闪烁的灯光。

  • 提供清晰一致的导航

  • 包括跳过导航链接允许用户绕过重复的内容。

  • 确保表格可访问 ,带有清晰的标签和错误消息。

  • 使用 ARIA 地标定义页面区域( <nav> , <main> , <aside> 等)。

  • 使用屏幕阅读器进行测试和其他辅助技术来识别问题。

  • 提供控制或停止动画、视频和音频的选项

  • 设计响应式布局适用于各种设备和屏幕尺寸。

  • 使用可访问的调色板并考虑色盲。

  • 提供字幕和文字记录用于音频和视频内容。

  • 确保动态内容更新传达给辅助技术使用 ARIA 现场区域。

  • 与真实用户进行测试残疾人士以获得有关您网站的可访问性的反馈。 请记住,可访问性是一项持续的承诺,应该集成到定期的开发和测试周期中。

  • 使用语义 HTML构建内容,确保标题等元素( <h1><h6> ), 列出 ( <ul> , <ol> ) 和按钮 ( <button> )被正确使用。

  • 提供替代文本alt 属性)用于非文本内容(例如图像)。

  • 确保足够的对比度文本和背景颜色之间。

  • 通过键盘使用所有功能通过使用可聚焦元素并管理焦点顺序。

  • 创建标签对于交互元素,使用 <label> 元素或 aria-labelaria-labelledby

  • 避免或提供导致癫痫发作的内容的替代品 ,如闪烁的灯光。

  • 提供清晰一致的导航

  • 包括跳过导航链接允许用户绕过重复的内容。

  • 确保表格可访问 ,带有清晰的标签和错误消息。

  • 使用 ARIA 地标定义页面区域( <nav> , <main> , <aside> 等)。

  • 使用屏幕阅读器进行测试和其他辅助技术来识别问题。

  • 提供控制或停止动画、视频和音频的选项

  • 设计响应式布局适用于各种设备和屏幕尺寸。

  • 使用可访问的调色板并考虑色盲。

  • 提供字幕和文字记录用于音频和视频内容。

  • 确保动态内容更新传达给辅助技术使用 ARIA 现场区域。

  • 与真实用户进行测试残疾人士以获得有关您网站的可访问性的反馈。