政务网站若要通过WCAG 2.1 AA级无障碍合规审查，语义化HTML并非可选项，而是必须跨越的硬性门槛。这一要求，许多开发团队往往在实测阶段才意识到问题，但那时修改的成本已大幅攀升。核心规范其实并不复杂，大致可概括为：整个页面仅允许一个包裹纯正文内容的，所有表单控件必须显式绑定，必须附带标题，需具备独立分发能力，且标题层级必须严格递进，全站有且仅有一个。
因此，语义化HTML绝非“建议”，而是政务网站合规的准入门槛。
为什么
先看一个最常见的错误：不少政务网站将里。这样做的后果是什么？屏幕阅读器（如NVDA、VoiceOver）按M键跳转时，只会识别首个合法的，并跳过所有非主内容区域。结果，用户只能逐行听完整个页面，才能找到办事指南或政策原文。这种用户体验，无异于让用户盲人摸象。
- 错误示例：
... ... 《XX条例》全文 - 正确做法：全页面仅保留一个
，且内部只包含、等承载核心服务内容的标签。顶部导航、侧边栏、页脚一律移出。 - 影响不止可访问性：搜索引擎（如百度政务搜索）会弱化
内混杂内容的权重，导致政策文件排名下降，这绝非小事。
表单控件不绑定
政务网站中，“身份证号”“手机号”“验证码”这类输入框随处可见。但很多开发团队习惯用CSS视觉对齐再加个placeholder提示，却忽略了或嵌套写法。屏幕阅读器根本无法告知用户这个输入框到底要填什么，用户反复提交失败后，只能放弃。流失率有多高，不言而喻。
- 必须显式绑定：
，不能仅靠title或aria-label替代。 - 必填项要用
required属性，而非仅靠红色星号加JS校验——后者对键盘用户完全不可见。 - 错误提示要关联控件：
请输入18位身份证号，并用aria-describedby="error-idCard"挂载到上。
很多政务站把“通知公告”列表用包一层，里面每个公告又用渲染——这等于白用语义标签。要求有标题（–），必须是可独立分发的内容单元（比如每条公告都能被RSS抓取、单独邮件推送）。
- 正确结构：
最新通知
关于调整社保缴费基数的通知
...
- 误用后果：屏幕阅读器生成一堆无意义的“section”节点，用户无法用6键（标题导航）快速跳转；Google 政务搜索也会忽略无标题的
。 - 装饰性图片必须加
alt=""，但政策文件中的图表、流程图必须有描述性alt，且优先用
标题层级断裂，会让整个导航体系崩溃
政务网站常见从开始写正文，或者外堆了4个（比如logo、banner、栏目名、副标题）。这导致屏幕阅读器的标题导航（T键）完全失效，用户无法按层级快速定位“办理条件”“所需材料”“办理流程”等子章节。
- 强制规则：全页面唯一
应为页面主标题（如“北京市居住证申领指南”），内用起始，子节严格递进（→→）。 - 禁止跳级：
后直接会导致大纲断裂，辅助技术无法构建逻辑树。 - 动态加载内容（如“常见问题”折叠面板）展开后，新标题必须插入DOM并触发
aria-live，否则键盘用户看不到新增结构。
最容易被忽略的一点是：语义化不是“写对标签就完事”，而是整套内容生产流程的约束。文案编辑必须按标题层级写稿，UI设计稿要标注每个区块的语义角色，CMS后台模板必须锁定范围。任何一环脱节，都会让前面所有的代码努力归零。
