公司官网刚上线，客服电话就响个不停。有用户抱怨下拉菜单点不开，有人反馈表单提交不了。技术团队查了一圈，发现不是浏览器兼容问题，而是部分用户在用屏幕阅读器访问网站。这时候才意识到，原来我们做的页面，对某些人来说根本‘看不见’。
什么是无障碍组件
无障碍组件，说白了就是让视障、听障、行动不便的人也能正常操作的网页元素。比如一个按钮，普通人点一下就行，但视障用户得靠键盘 tab 键导航，靠读屏软件播报内容。如果这个按钮只是用 div 加点击事件实现，读屏软件可能根本不知道它是个按钮。
正确的做法是用语义化的 HTML 标签。比如按钮就该用 <button>，而不是 <div onclick="...">。这样屏幕阅读器才能准确识别并告知用户：“这是一个按钮，功能是提交表单”。
常见组件的无障碍处理
下拉菜单是个典型例子。很多人用 div 模拟，展开收起靠 JS 控制 display 属性。但这样键盘无法聚焦内部选项，读屏软件也读不出状态。应该用 <select><option></option></select>，或者给自定义组件加上 role="listbox"、aria-expanded 等属性。
<div role="listbox" aria-expanded="true" tabindex="0">
<div role="option" aria-selected="true">选项一</div>
<div role="option">选项二</div>
</div>弹窗（Modal）也是高频场景。打开时要锁定页面滚动，把焦点移到弹窗内，并阻止焦点跑到背景内容上。关闭后焦点还得回到原先触发的位置。这些细节不做，对键盘用户就是灾难。
颜色与对比度不能忽视
有个客户反馈看不清登录框的提示文字。设计师说灰色很高级，但色弱用户根本分不清 #999 的文字和白色背景。WCAG 标准要求文本与背景对比度至少 4.5:1。可以用在线工具测一测，别让美观牺牲可读性。
图标按钮更要小心。仅用一个放大镜图标表示搜索，视障用户完全无法理解。必须加 aria-label 或隐藏文字说明。
<button aria-label="搜索">
<svg>...</svg>
</button>表单验证信息也要能被读出来。比如密码强度不足，除了变红提示，还得用 aria-live 告知辅助技术。
测试不只是跑自动化脚本
团队曾以为通过 axe 插件检测就万事大吉。直到请来一位盲人朋友现场测试，才发现很多交互流程依然卡顿。他用 NVDA 配合 Chrome，tab 键走到某个区域突然没了声音，原来是动态加载的内容没触发 aria-live 更新。
真人的使用习惯比工具更真实。偶尔花半小时，请非技术人员用键盘从头到尾走一遍流程，会发现一堆意料之外的问题。
无障碍不是加分项，而是基本功。就像修路要配盲道，做网页也得考虑所有人的通行权。当你写的组件能被任何人顺畅使用，才算真正完成。”}