如何设计无障碍网页?制作为盲人使用的网页该注意哪些方面?

本题已收录至知乎圆桌 残障:我和少数人的生活,更多「身障人士(残疾人)」相关话题欢迎关注讨论。 想将现有的站点改为无障碍使用,因为有一部分盲人用户。但是从来没做过……之前看过盲人是如何浏览网页的?但是我们的网站经过盲协那边的评定认为不足以被使用,所以求改进方法
关注者
121
被浏览
8199

一个网站的好坏,除了内容有创意、页面优美、访问速度快以外,用户体验是至关重要的。而这里的“用户体验”中的用户包括了如视力障碍者、听力障碍者、阅读障碍者等小众用户。一个没有满足无障碍设计的网站,是不能被这一个小众群体访问并使用的。尤其是视障用户(也是访问网站最多的障碍用户)。他们借助屏幕阅读器,采用TTS(文字转语音技术)将屏幕上的文字朗读出来,使视力障碍用户能与网站进行交互。由于本人是一名视障信息无障碍攻城狮,因此以下就以视障者的角度,从可用性、易用性两个方面重点谈谈网站无障碍设计需注意的几个点。


一、可用性。

可用性,顾名思义,至少要能满足用户可以使用该网站,好不好用另说。一般导致不可用的因素会有以下几点:元素无法被TAB键focus、需点击操作的元素无响应回车/空格键等点击事件、鼠标悬浮菜单无提供键盘的交互方式、键盘陷阱、仅提供图形验证码的验证方式等等。下面我们根据这些影响的因素逐个来说说实现无障碍的方法。

1.无法被TAB键focus:通常此类问题都是因为前端开发未按照<button>、<input>、<a href="xxx"></a>等标准方式实现,采用自定义标签,如<span></span>绑定onclick进行响应,导致TAB键无法focus,因此自然而然的就没法与之交互了,确定提交?下一步?关闭等均无法操作。解决办法也很简单,一方面可使用标准的<button>、<input>或<a href=”xxx”></a>实现以外,也可在自定义标签(如<span></span>)中添加tabindex="0"(”0”为当前DOM顺序)增加TAB键交点,并响应onkeydown键盘事件即可。

2.需点击的元素无响应回车/空格事件:上面有提到,未按照标准实现,采用自定义标签绑定onclick进行响应操作会导致键盘用户无法进行点击操作,如<span onclick=”alert(‘hello’);”>click me</span>此种方式对使用鼠标操作的用户而言,的确没有任何障碍,但依赖键盘的用户就无从下手了。为此,我们可以同时响应onkeydown事件进行回车/空格的点击操作,并使用role=”button”货role=”link”明确该元素控件类型(用于告知用户该元素可点击)即可。

3. 鼠标悬浮菜单无提供键盘的交互方式:现在很流行的设计,鼠标划过、停留就会弹出下拉菜单,非常方便,界面清爽干净,也容易理解和管理。但对于键盘用户而言却无法呼出该下拉菜单,提供其他入口进入的,麻烦点多走几步还是能进入,若为唯一通道则该功能模块将会对键盘用户完全封闭。常见的设计是,当TAB键focus到具有下拉菜单的元素后按空格键弹出菜单,esc键货当TAB交点离开该区域时收起下拉菜单。同时也要在该元素添加aria-haspopup=”true”属性,明确该元素具有弹出项目。若为菜单,还需将控件类型设为role=”menu”、role=”menuitem”等。

4.键盘陷阱:当切换TAB键浏览网页时,发现focus到某元素货某区域后TAB交点会卡死货在这个区域内几个元素循环跳转,这种现象我们称之为“键盘陷阱”。此种情况常出现在多行编辑框中,人为的将TAB键作为四个空格的缩进,却忽视了依赖此键遍历网页的键盘用户。

5.仅提供图形验证码的验证方式:图形验证码就是用于确保当前操作的是一个人而非机器而设计的,但视障用户无法使用肉眼获取验证码,只能通过屏幕阅读器获取后进行语音播报,导致被判定为非人类。这是一个国际性难题,也是一个安全与无障碍很难兼容的问题。因此,我们不去直接解决图形验证码的难题,而采用其他渠道验证的方式,如语音验证码、短信验证码等,同样能达到验证操作者是一个人的效果。


二、易用性。

易用性则是凌驾于可用性之上的,先要可以用才能谈容易使用。相对可用性的严重问题而言,易用性的问题是较多的,也是当下网站普遍存在的。如图片无描述文本、装饰性图片无屏蔽访问、TAB交点顺序不合理、控件类型不明确、无关联文本标签、没有合理设置landmark导航等诸多问题。

1.图片无描述文本:很多网站logo、banner等图片,本身带有文字显示的,设计人员往往不会进一步提供alt货title属性描述该图片的内容。导致屏幕阅读器访问该图片时只能朗读出“图片”却无法得知该图片的用途、传递出的信息、如何与之交互等。简单的两个属性,方便了视障用户的理解,更满足了网站的设计规范。

2.装饰性图片无屏蔽:视障用户借助屏幕阅读器,通过TAB键与上下左右方向键进行网站浏览的,如果这时候存在大量纯粹是为了装饰而添加的图片元素,则会大大降低视障用户的浏览效率。因此,对于纯粹为了美观而添加的装饰性图片,都应当屏蔽辅助器(屏幕阅读器)的访问。屏蔽方法也很简单,若为<img>元素,可以直接使用alt="",引号内留空即可。又或者使用aria-hidden="true",若该元素具备TAB交点的,还需要使用tabindex="-1"来屏蔽TAB键的focus。

3.TAB焦点顺序不合理:我们都知道,对于一个用户登录表单而言,符合逻辑的操作顺序应该是这样的“输入用户名->输入密码->输入验证码->勾选记住密码->点击登录”。一旦编码时没注意,颠倒DOM顺序,视觉顺序不影响,但对于键盘用户来说可就错乱了。这样的案例也有很多,此处就不点名了。解决办法可从代码层面上调整DOM顺序,又或者适当使用tabindex来调整。但使用tabindex需要注意,若理所当然的将其顺序设为1、2、3、4、5,这将会跳过前面所有元素优先访问,这也是不推荐的,这样不易于视障用户理解网页的布局结构。

4.控件类型不明确:当自定义标签实现的按钮、链接、复选/单选框时,没有正确使用role属性明确控件类型,视障用户使用屏幕阅读器访问该自定义控件时则无法知道如何与之交互。我们都知道,按钮、链接可以用空格货回车进行点击,复选框可用空格勾选/不选,明眼用户可通过视觉获知,而视障用户则通过控件类型的语音播报获知。

5.无关联文本标签:填写表单时,通常会使用一段提示文本加一个操作控件,如用户名:<input type="text" />、<input type="checkbox" />苹果。屏幕阅读器访问第一个用户名输入框时也许能正确朗读,但后面的checkbox就未必了,可能仍然朗读“用户名”。因此,正确的关联至为重要,可使用<label for进行关联。如<input type="checkbox" id="apple"><label for="apple">苹果</label>。

6.没有合理设置landmark路标:一个页面都会有以下区域组成“横幅区banner)、导航区(navigation)、主内容区(main)、搜索区(search)、页脚信息区(contentinfo)”,鼠标用户可快速通过鼠标滚轮定位到指定区域,而键盘用户则需要通过规定的landmark路标进行快速跳转。如将主内容区的<div>元素添加role="main",此时键盘用户只需通过特定的热键即可一键抵达,其余路标同样如此。


当然,无障碍设计是一个非常庞大、非常专业的事情,从产品到视觉设计、交互设计,开发、测试全流程都需要参与并考虑的事情,不是通过这个篇幅就能说清的。以上只是根据我个人的经验,尽量写出最为典型的问题并给出我认为较为合适的解决方案。也许上述方案没有完全按照相关标准实现,这是因为考虑到国内外众多辅助器之间的兼容性,而不得已作出的取舍,尽可能去适配更多辅助器。以上若有说得不当,还请指正。