企业官网无障碍怎么做？键盘、对比度、图片、表单与 WCAG 验收清单
企业官网能在手机和电脑上打开，不代表所有访客都能顺利使用。有人只用键盘操作，有人需要屏幕阅读器朗读页面，也有人必须放大文字、提高对比度或关闭动画。常见障碍往往藏在细节里：焦点看不见，菜单只能用鼠标展开，图片没有合适的替代文本，表单报错只变成红色，弹窗打开后键盘却跑到页面背后。
无障碍改造需要设计、前端、内容编辑和测试人员共同参与。这份清单以 W3C《Web Content Accessibility Guidelines（WCAG）2.2》为主要技术参照，适用于企业展示站、制造业官网和外贸独立站。它可以帮助团队提出需求和组织验收，但不能替代完整的一致性评估，也不代表自动满足某个国家、地区或行业的法律要求。
先写清无障碍目标和验收范围
项目需求书要说明采用哪个标准版本、目标级别、覆盖哪些页面和业务流程。WCAG 2.2 将成功标准分为 A、AA 和 AAA 三个等级。企业常把 AA 作为项目目标，但合同、采购规则或当地法规可能另有要求，不能只凭行业习惯决定。
范围至少应包含首页、导航、产品列表、产品详情、文章、搜索、询盘表单、下载、登录或会员功能、弹窗和错误页面。完整流程也要覆盖，例如访客从产品页进入询盘、填写、校验、提交并看到结果。只抽查一个静态页面，无法证明整条流程可用。
把四项原则落到具体任务
WCAG 2.2 用可感知、可操作、可理解和健壮四项原则组织要求。项目团队不必把这些词写成宣传口号，可以直接转换成任务：为视觉内容提供替代方式，让键盘能够完成操作，让页面和错误提示容易理解，并让浏览器及辅助技术能够识别控件名称、角色和状态。
需求、设计、开发和内容验收都应引用具体成功标准或测试条件。只在合同里写“符合国际无障碍标准”，交付时很难判断哪些页面、哪个等级以及如何证明。
HTML 结构先于视觉样式
页面标题、主标题、章节标题、段落、列表、导航和页脚应使用与含义相符的 HTML。视觉上放大的一行文字不会自动成为标题；用多个换行和空格模拟布局，也无法向屏幕阅读器表达结构。
每页要有能区分内容的 title，主标题与章节层级应保持清楚。页面区域可使用 header、nav、main 和 footer 等原生元素。开发人员应检查 DOM 顺序，因为屏幕上的左右布局与程序读取顺序可能不同。
页面语言和局部语言都要标记
中文页面应在根元素声明正确的 lang，英文页面也要使用对应语言代码。正文中连续出现另一种语言的句子或片段时，可按内容标记局部语言，帮助屏幕阅读器选择合适的发音规则。
多语言站不能只靠国旗图标或 Cookie 判断语言。每个语言版本应有稳定 URL、明确的页面语言和可操作的切换入口。URL 与维护方法可参考外贸独立站多语言规划清单。
整站操作要能离开鼠标完成
验收人员可以把鼠标放到一边，只用 Tab、Shift+Tab、Enter、空格、方向键和 Escape 走完整站。导航展开、轮播控制、弹窗、筛选、折叠面板、文件上传和表单提交都应有合理的键盘操作方式。
焦点不能被困在组件里。弹窗打开后，焦点应进入弹窗；关闭后回到触发按钮。自定义菜单和组合框要遵循与组件角色相符的键盘行为，不能让用户靠猜测寻找退出方法。
焦点必须看得见，也不能被遮住
浏览器或网站需要为当前键盘焦点提供清楚的视觉指示。设计稿若用 outline: none 删除默认轮廓，却没有提供等效样式，键盘用户就不知道自己停在哪里。焦点颜色和形状还应在实际背景上检查，而不是只看组件库截图。
WCAG 2.2 新增了焦点不被遮挡的要求。粘性页头、底部 Cookie 条、客服悬浮层和模态窗口不能盖住当前焦点。验收时应在不同视口和缩放比例下逐项 Tab，观察焦点是否完整可见。
重复导航要提供绕过方式
页面顶部有大量导航时，键盘和屏幕阅读器用户不应每次都重复经过所有链接。可以在页面开头提供“跳到主要内容”的链接，并使用清晰的主内容区域。该链接获得焦点时应可见，目标位置也要能正确接收或定位焦点。
面包屑、站内搜索和一致的导航结构能帮助访客判断位置。链接文字要说明目的，避免同一页面出现一排无法区分的“了解更多”。
文字对比度要用计算结果验收
WCAG 2.2 AA 级的普通文字最低对比度为 4.5:1，大号文字最低为 3:1，并有标准列明的例外。团队要测量文字与实际背景的组合，包括按钮、图片上的文字、禁用或悬停之外的常规状态，不能凭肉眼说“看起来够深”。
大号文字的定义涉及字号和粗细，不能把稍微加粗的小字当作大字降低要求。品牌色若无法承担正文或按钮文字，可以保留品牌色作为装饰，再为信息和操作选择通过对比度测试的颜色。
颜色不能独自承担信息
必填项、错误、库存状态、图表类别和当前步骤不能只用红、绿或深浅区分。可以同时使用文字、图标、线型或位置，并确保这些辅助表达也能被程序识别。
链接若只靠颜色与正文区分，应核对相应成功标准和交互状态。焦点、选中、悬停和错误边框属于非文本视觉信息时，也要检查与相邻颜色的对比。
放大与窄屏不能丢内容
访客把文字放大到 200% 后，内容和功能仍应可用。按钮文字不能被裁掉，表单标签不能覆盖输入框，导航也不能因为容器高度写死而消失。测试应使用浏览器文字缩放和页面缩放，不只拖动响应式设计工具。
WCAG 2.2 的 Reflow 成功标准要求一般内容在相当于 320 CSS 像素宽的视口中无需同时进行横向和纵向滚动，确实需要二维布局的内容有例外。数据表、地图和大型图纸可以单独处理，但页面主体不应被固定宽度拖出屏幕。
点击和触摸目标要留出空间
WCAG 2.2 AA 级的 Target Size（Minimum）要求指针目标达到至少 24×24 CSS 像素，或通过间距等方式满足标准，同时存在若干例外。手机端常见问题是小号图标紧贴、分页数字拥挤、关闭按钮贴在屏幕边缘。
验收不能只量视觉图标。实际可点击区域、相邻目标距离、缩放状态和触控反馈都要检查。产品筛选和语言切换若只有很小的箭头可点，可以让完整标签成为操作区域。
图片替代文本取决于使用场景
有意义的产品照片、流程图和证书需要文本替代，但 alt 不是把文件名或关键词塞进去。W3C 的图片替代文本决策树建议根据图片功能和上下文判断：信息图片简要表达相关含义；链接或按钮中的图片说明操作目的；复杂图表还要在页面提供完整数据或说明。
纯装饰图片应使用空的 alt，让屏幕阅读器跳过。附近文字已经完整重复图片信息时，也要避免再次朗读。制造业图片的命名、授权和内容交付可结合制造业官网图片准备清单执行。
图标按钮必须有可访问名称
只有放大镜、电话、分享或关闭图标的按钮，需要让辅助技术读出明确名称。开发人员可优先使用带文字的原生按钮；界面确实只显示图标时，再通过合适机制提供名称。图标文件名和 CSS 类名不会自动成为可靠标签。
WAI-ARIA Authoring Practices 对名称和描述作了详细说明。使用 aria-label、aria-labelledby 或 aria-describedby 前，应先确认原生 HTML 是否已经能表达目的，并检查名称是否与屏幕上的文字一致。重复或冲突的命名会让朗读结果更难理解。
表单标签不能由占位文字代替
姓名、邮箱、电话、选择框和上传控件都需要可见且与控件正确关联的标签。Placeholder 会在输入后消失，颜色也可能偏淡，不能独自承担标签职责。必填、格式和字数说明要在用户填写前提供，并能被辅助技术关联到对应字段。
W3C 表单教程建议优先用 label 明确关联控件，相关选项可用 fieldset 和 legend 分组。企业询盘表单还要控制字段数量、隐私说明和送达验证，完整流程可参考企业官网询盘表单设计与验收清单。
错误提示要说明位置和改法
提交失败时，页面应指出哪个字段有问题，并用文字说明原因。只给边框变红或弹出“输入错误”，用户仍不知道该改哪里。焦点可以按设计移动到错误摘要或第一个错误字段，但要避免突然改变上下文。
输入成功、正在发送、提交完成和上传进度等状态，也应让辅助技术在不移动焦点的情况下获知。验证码若只有视觉挑战，要评估可访问替代方式及安全边界。
动态组件优先使用原生元素
按钮应使用 button，链接应使用 a 并提供真实目的地。用 div 模拟按钮，会额外产生焦点、键盘、角色和状态维护工作。原生元素满足不了组件需求时，再按成熟模式补充 ARIA。
折叠面板要暴露展开状态，选项卡要让当前项和面板关系可识别，弹窗要提供标题、关闭方法和合理的焦点管理。组件在桌面端能点击，不代表在键盘、触屏和屏幕阅读器中都可用。
轮播、动画和闪烁内容要受控
自动开始且持续移动的轮播、滚动公告和动画可能妨碍阅读。符合条件的内容应提供暂停、停止或隐藏控制，控制本身也要能用键盘操作。访客启用减少动态效果的系统设置时，网站可以减少非必要动画。
页面不能出现超过标准阈值的闪烁内容。宣传视频、GIF、加载动画和活动页都应纳入检查。把轮播速度调慢不能解决焦点顺序、朗读重复和控制名称等问题。
音视频要准备字幕和替代内容
预录视频中的语音通常需要准确字幕。只有背景音乐的视频、播客、直播和包含关键视觉信息的演示，还要根据适用成功标准准备文字稿、音频描述或其他替代方式。自动字幕可以作为制作起点，发布前仍需校对专有名词、数字和说话人。
播放器的播放、暂停、音量、进度和全屏控件要有名称并能用键盘操作。自动播放声音会打断屏幕阅读器，企业官网不宜把它设为默认体验。
数据表和文档下载也在范围内
参数对照表需要正确的表头及行列关系，不能用合并单元格和空白字符拼版。复杂表格可以提供说明、简化视图或可下载数据，但下载按钮仍要说明文件类型和大小。
PDF、产品手册、证书和电子表格属于访客实际获取的内容。网页通过无障碍检查，而下载文档没有标题、阅读顺序、标签或文本替代，完整流程仍存在障碍。采购资料时应把可访问文档作为交付要求。
第三方组件不能从验收中消失
地图、验证码、客服、视频播放器、预约系统、Cookie 管理和嵌入表单常由第三方提供。企业仍要检查它们在真实页面中的键盘、焦点、名称、对比度和错误提示。供应商无法修正时，应提供可用替代路径并记录限制。
插件升级可能改变 DOM、样式和焦点行为。每次更换模板、统计脚本或第三方组件后，重新执行关键路径测试，不能只沿用旧报告。
CMS 编辑流程要保护语义结构
开发团队修好模板后，内容编辑仍可能新增空标题、跳级标题、无意义链接和缺少替代文本的图片。CMS 可以提示图片用途、限制标题样式、保留表格表头选项，并在发布前检查缺失信息。
编辑手册要用本站真实示例说明产品图、装饰图、证书、图表和按钮分别怎么处理。审核人员不能只检查错别字，还要查看标题层级、链接目的、语言、字幕和文档附件。
自动化扫描只能发现一部分问题
代码扫描工具擅长发现部分缺少标签、对比度、结构和属性问题，却无法可靠判断替代文本是否表达了图片作用、焦点顺序是否符合业务流程，或错误提示是否让用户真正知道怎么改。W3C 的评估说明明确指出，没有单一工具能够判断网站是否满足无障碍标准。
可以把自动化检查放进开发和发布流程，用于阻止明显回归；人工键盘测试、屏幕阅读器检查、缩放和真实任务测试仍需保留。快速检查通过，只能说明所检查项目没有发现问题。
验收要留下页面、方法和结果
测试记录应包含页面 URL、日期、浏览器、视口、缩放比例、辅助技术、操作步骤、预期结果、实际结果和证据。问题要关联组件和模板来源，便于判断修复一处能否覆盖同类页面。
代表页面抽样适合发现模板问题，一致性声明则需要按标准覆盖完整页面和完整流程。W3C 提供的 Easy Checks 只能用于初步观察；正式评估应采用更完整的方法并由具备相应知识的人员复核。
在需求书中明确持续维护
无障碍不是上线前的一次修补。企业应在设计规范、组件库、内容模板、采购条款、代码测试和编辑培训中保留要求，并指定问题反馈渠道。改版、新增栏目、上线活动页或更换第三方工具时，要重新验收受影响范围。
需求书可以列出目标标准、页面样本、业务流程、支持的浏览器和辅助技术、测试责任、缺陷等级、修复时限与报告格式。网站需求书的组织方式见制造业官网需求书与功能验收清单。
凯乐丰可以参与的环节
凯乐丰官网列有企业官网建设、外贸独立站建设和SEO/GEO 增长方案等业务页面。企业准备新建或改版网站时，可以把无障碍目标、目标访客、重点流程、内容语言和现有问题一并写入需求，双方再确认设计、开发、内容和测试范围。
凯乐丰可以在约定范围内协助页面结构、组件实现、内容模板和上线检查。是否达到特定标准等级或法律要求，需要按照明确范围、版本和评估方法形成证据，不能用一份自动扫描结果或笼统承诺代替。
