手动审计是确保网站真正可访问的核心，需结合键盘导航、屏幕阅读器测试、视觉检查与代码审查。首先通过键盘操作验证焦点顺序、指示器与陷阱；再用屏幕阅读器检测语义结构、alt文本、表单标签及ARIA使用是否合理；同时检查颜色对比度、文本可读性、点击区域与多媒体字幕；最后借助开发者工具审查HTML语义与CSS隐藏问题。相比自动化工具仅能发现表面缺陷，手动审计能深入评估交互逻辑与用户体验，如模态框焦点管理、动态内容通知等复杂场景。核心技术点包括：语义化标签（标题层级、地标元素）、键盘可操作性、替代文本、对比度达标（WCAG 2.1 AA）、原生HTML优先于ARIA。问题记录需标准化，包含标题、页面定位、WCAG依据、严重等级、复现步骤、影响说明与修复建议，并配截图或视频；按影响排序优先级，通过会议沟通并用项目工具跟踪修复，推动可访问性持续改进。
网站可访问性手动审计，说白了，就是我们用“人”的视角，结合各种辅助技术，去真实体验和评估一个网站对所有用户，尤其是残障用户是否友好、易用。它不仅仅是跑一遍自动化工具，而是深入到交互细节、语义结构和用户体验的深层考量。
HTML可访问性手动审计是一个细致活儿，它要求我们像一个真实的用户那样去“走查”网站的每一个角落。这通常会涉及几个关键步骤，而且这些步骤往往不是线性的，而是相互穿插、反复验证的。
首先，我们会从键盘导航开始。把鼠标收起来，只用键盘（Tab键、Shift+Tab、Enter、空格键、方向键）来操作网站。能用键盘访问所有可交互元素吗？焦点指示器清晰吗？（比如那个蓝色边框，或者自定义的视觉提示，是不是总能看到？）焦点顺序符合逻辑吗？（Tab键按下去，是不是按照视觉顺序和阅读顺序走的，而不是跳来跳去？）有没有焦点陷阱？（比如打开一个模态框，焦点被困在里面出不来，或者关掉模态框后焦点不知道去哪了。）这步能发现很多自动化工具发现不了的交互逻辑问题。
接着，屏幕阅读器测试是重头戏。这需要安装一个屏幕阅读器（比如Windows上的NVDA或JAWS，macOS上的VoiceOver），然后闭上眼睛，或者至少不看屏幕，纯粹听屏幕阅读器朗读网站内容。
立即学习“前端免费学习笔记（深入）”；
- 语义化结构：标题层级对吗？（H1-H6）列表（
ul
,
ol
）有正确朗读吗？表格（
table
）结构清晰吗？
- 图片与链接：
alt
文本描述准确吗？链接文本有意义吗？（不能只说“点击这里”）。
- 表单：
label
标签是否正确关联输入框？错误提示能被朗读吗？必填项有提示吗？
- ARIA使用：如果用了ARIA，是不是用对了？有没有滥用或者误用导致反而更糟糕的情况？（比如给一个按钮加
role="link"
，或者给非交互元素加
tabindex="0"
）。
- 动态内容：页面内容更新时，屏幕阅读器能及时通知用户吗？（
aria-live
区域）。
再来，视觉和内容检查也不能少。
- 颜色对比度：使用工具（如WebAIM Contrast Checker）检查文本和背景色的对比度是否符合WCAG 2.1 AA级标准。
- 文本可读性：字体大小、行高、字间距是否合适？文本是否能调整大小而不会破坏布局？
- 可点击区域大小：按钮和链接的点击区域是否足够大，方便触摸屏用户操作？
- 多媒体：视频有没有字幕？音频有没有文字转录？
最后，代码审查作为辅助。通过浏览器开发者工具，检查HTML结构、CSS样式和JavaScript行为。看看有没有不规范的HTML标签使用，或者通过CSS隐藏了本应被屏幕阅读器识别的内容。
整个过程，其实就是不断地切换角色，从普通用户到键盘用户，再到屏幕阅读器用户，甚至低视力用户，去感受网站的真实体验。
为什么手动审计比自动化工具更关键？
自动化工具，比如Lighthouse、axe DevTools，它们确实很棒，能快速抓出不少低级错误，比如颜色对比度不达标、图片缺少
alt
文本、或者某些ARIA属性拼写错误。这就像是网站可访问性的“体检”，能发现一些显而易见的问题。但它们能做到的，也仅限于此了。
想想看，一个自动化工具怎么能理解“这个按钮的文案是否清晰地表达了它的功能”？它也无法判断“这个模态框弹出后，焦点是否逻辑地转移到了模态框内部，并且用户关闭后又能回到正确的位置”。这些都是涉及到语义理解、用户意图、交互逻辑和整体用户体验的深层问题。
举个例子，一个
<div>
元素被用CSS样式化成了按钮的模样，并且通过JavaScript实现了点击事件。自动化工具可能只会告诉你，这个
div
没有
role="button"
，没有
tabindex="0"
，这确实是个问题。但它不会告诉你，即使你给它加上了这些，它仍然不如一个原生的
<button>
元素在语义上那么强大，也不如原生按钮那样能自动处理键盘事件。
手动审计，特别是结合屏幕阅读器测试，能够真正模拟辅助技术用户的使用场景。只有通过人耳去听、人脑去判断，才能发现那些“表面上没问题，实际上却很糟糕”的可访问性障碍。比如，一个导航菜单，视觉上很清晰，但屏幕阅读器却把它读成了一堆无序的链接，没有层级感，这就是语义上的失败。所以说，自动化工具是第一道防线，而手动审计才是确保网站真正可访问的最终防线，它关乎的是真正的用户体验和包容性。
进行HTML可访问性手动审计时，需要关注哪些核心技术点？
在进行手动审计时，我们的目光要像X光一样穿透表象，直达HTML的骨架和肌肉。有几个核心技术点是必须紧盯不放的：
首先，语义化HTML结构。这是基石。
- 标题层级：
<h1>
到
<h6>
必须有逻辑地组织页面内容，确保每个页面只有一个
<h1>
作为主标题，后续标题按重要性递减。这对于屏幕阅读器用户快速理解页面结构至关重要。
- 列表：
<ul>
,
<li>
,
<ol>
应该用于呈现列表内容，而不是用一堆
<div>
模拟。
- 地标元素：
<header>
,
<nav>
,
<main>
,
<aside>
,
<footer>
等HTML5语义化标签，它们能帮助屏幕阅读器用户快速跳转到页面不同区域。
- 表单元素：
<label>
标签要正确地用
for
属性关联到对应的
<input>
,
<textarea>
,
<select>
。这是表单可访问性的核心。
其次，键盘可操作性与焦点管理。
- Tab顺序：确保所有可交互元素（链接、按钮、表单控件）都能通过Tab键按预期的逻辑顺序访问。
- 焦点指示器：默认的浏览器焦点指示器（通常是蓝色边框）必须可见，如果自定义了，也要确保有足够的对比度。
- 模态框与弹出层：当模态框打开时，焦点应该被“捕获”在模态框内部，不能跳到模态框后面的内容。关闭后，焦点应返回到触发模态框的元素上。
第三，图片与多媒体的替代文本。
-
alt
属性
：所有<img>
标签都应该有
alt
属性。对于纯装饰性图片，
alt=""
（空字符串）是正确的做法；对于有信息量的图片，
alt
文本要简洁准确地描述图片内容。
- 视频与音频：视频需要提供字幕（
<track>
元素）和文字转录。对于纯音频，也需要提供转录文本。
第四，颜色对比度与文本可读性。
- WCAG 2.1 AA标准：正文文本与背景的对比度至少达到4.5:1；大号文本（18pt常规或14pt粗体）至少达到3:1。
- 文本缩放：确保用户在浏览器中放大文本时，页面布局不会混乱，内容仍然可读。
第五，ARIA属性的正确使用。
- 优先使用原生HTML：如果原生HTML元素能实现相同的功能，就不要使用ARIA。例如，用
<button>
而不是
<div role="button">
。
- 谨慎使用：ARIA是强大的补充，但误用或滥用反而会制造新的可访问性障碍。例如，不要给一个非交互元素加上
role="button"
。
-
aria-label
和
：用于为没有可见标签的元素提供可访问名称，或覆盖现有标签。aria-labelledby
-
aria-live
区域
：用于通知屏幕阅读器用户页面上动态更新的内容（如加载状态、错误消息）。
这些技术点，每一个都可能成为用户体验的瓶颈。审计时，需要用挑剔的眼光去审视每一个细节。
如何有效记录和报告可访问性审计发现的问题？
审计发现问题只是第一步，如何清晰、有条理地记录并报告这些问题，让开发团队能够理解并有效修复，这同样关键。这需要一套系统化的方法。
首先，建立一个标准化的报告模板。这个模板应该包含以下核心信息：
- 问题标题：简洁明了地概括问题。
- 受影响页面/组件：明确指出问题发生在哪里，最好附上URL和具体组件的截图。
- WCAG引用：指出违反了WCAG（Web Content Accessibility Guidelines）的哪个具体准则和成功标准。这提供了问题的权威性和严重性依据。例如，“WCAG 2.1 SC 1.4.3 对比度（最小）”。
- 严重程度：根据问题对用户的影响程度进行分级（如：高、中、低）。高严重性问题通常是阻碍用户完成关键任务的。
- 复现步骤：详细描述如何重现问题。越具体越好，包括使用的浏览器、辅助技术（如NVDA）、具体操作路径等。
- 实际用户体验影响：用通俗的语言描述这个问题会给残障用户带来怎样的困扰。这有助于团队理解问题的“人情味”。
- 建议修复方案：提供具体的修改建议，最好能附上代码示例或指向相关文档的链接。不要只是说“修复它”，而是要说“考虑使用
<label for='...' >
来关联输入框”。
- 截图或视频：直观地展示问题，比文字描述更有说服力。对于交互性问题，短视频录屏会非常有帮助。
其次，优先级排序。不是所有问题都一样紧急。根据WCAG的A/AA/AAA等级，以及问题对用户完成核心任务的影响程度，给问题排定修复优先级。那些导致用户无法访问关键功能的问题，无疑是最高优先级。
第三，持续沟通与协作。审计报告不是一锤子买卖，需要与设计、开发团队进行有效的沟通。
- 召开评审会议：面对面（或线上）讲解报告，解答疑问，确保团队对问题有共同的理解。
- 技术深度：在报告中加入适当的技术深度，比如指出具体的HTML标签错误、CSS属性问题或JavaScript逻辑缺陷。
- 迭代跟踪：利用项目管理工具（如Jira、Trello）跟踪问题的修复进度，确保每个问题都被妥善处理。
有效的报告不仅能清晰地呈现问题，更能促进团队对可访问性的理解和重视，将修复工作融入到开发流程中，而不是作为额外的负担。这才能真正推动网站可访问性的持续改进。
css javascript java html html5 windows 浏览器 access JavaScript html5 css html for select 字符串 堆 事件 input 键盘事件 ul table li windows macos jira 自动化