不能。w3c验证器仅校验html语法合法性，不检查可访问性语义，如缺失role、无效alt值、aria属性错误等，通过≠可访问；accessibility-linter因支持静态源码分析、即时反馈、覆盖条件渲染与ssr，比运行时工具axe-core更适配ci阶段。
W3C验证器能查出可访问性问题吗？
不能。W3C Markup Validation Service只校验HTML语法合法性，比如alt缺失、<p></p>里嵌<div>、<code>DOCTYPE缺失这类硬性错误，但它完全不检查可访问性语义——例如<div onclick="submit()">没加<code>role="button"、<input>没配<label></label>、<img>的alt值为空或为“图片”这种无效文本，它一律放行。
这意味着：过W3C ≠ 可访问。很多团队卡在“验证通过就以为没问题”这一步，结果上线后被屏幕阅读器用户投诉按钮不可聚焦、表单无法语音操作。
- W3C验证对象必须是构建后的
dist/index.html，不是含v-bind:src或{% if %}的源码模板 - 它不执行JS、不解析动态DOM、不校验CSS或ARIA属性有效性
- 报错中“Warning”级别常包含可访问性隐患（如
img缺少alt），但默认不中断构建，容易被忽略
accessibility-linter为什么比axe-core更适合CI阶段？
因为它是静态分析器，直接扫描JSX/Vue SFC/HTML模板源码，不依赖运行时环境。axe-core这类运行时工具需要启动浏览器、渲染完整页面、模拟交互，只能在E2E测试阶段跑，反馈延迟高；而accessibility-linter能在git commit或npm run build时立刻报错，比如发现<button onclick="{...}">点击这里</button>没写aria-label或语义不当，开发者当场就能改。
- 它能覆盖条件渲染分支（如
{loading ? <spinner></spinner> : <list></list>}），axe-core可能根本没渲染<list></list>就结束了 - 支持SSR初始HTML检查，axe-core只能测客户端hydrate后的DOM
- 规则映射WCAG 2.2具体条款（如
input-requires-label对应SC 3.3.2 Labels or Instructions），报错带标准编号，方便追溯
alt-require和input-requires-label规则的实际坑点
alt-require不是只要写了alt就过关——空字符串alt=""允许（装饰图），但alt="图片"、alt="icon"、alt="logo"全算违规；input-requires-label也不只是找<label for="id"></label>，它还识别<label><input></label>隐式关联、以及aria-labelledby等ARIA方案，但会误判封装好的UI组件（如<myinput label="用户名"></myinput>内部没暴露id时）。
- SVG图标用
<svg aria-hidden="true"></svg>时，alt-require不该触发——需配置规则排除svg标签 -
input-requires-label对<input type="hidden">自动豁免，但type="search"或type="color"必须有label - Vue中
v-model绑定的<input>若没显式id，label的for属性无法绑定，得靠aria-label补位
如何把可访问性审查真正嵌入开发流程？
别只靠PR时人工扫一眼。把accessibility-linter加进pre-commit钩子，配合VS Code插件实时提示，再在CI里设为构建失败项——这样alt=""写成alt=" "（带空格）、<button></button>漏掉type="button"导致表单意外提交这类低级错误，根本进不了主干。
最常被跳过的环节是“修复后验证”：改完alt文本，得用NVDA或VoiceOver真实听一遍是否自然；加了aria-label，得键盘Tab过去确认焦点停在正确位置。自动化工具拦得住代码，拦不住体验断层。
