作者归档:wenju

增强网站可访问性的25种方法

随着web使用量的增加和人们网络意识的增强,可访问性(或“通用设计”)变得更加重要。可访问性不仅取决于一个网站的代码,还受网站设计和内容的影响,这就是为什么可访问性、标准和可用性关系如此紧密。 网页无障碍是一个庞大的课题,已自成一个领域。 但不要被它吓到。无障碍并不是非常难以实施。它并不会像一些人想象的会有碍美观或影响交互。这是一种高明的(smart)设计和开发方式。 让我们来看看建立一个无障碍网站的25个重要技术。 1.一致的布局和结构 为了帮助用户快速和轻松地浏览您的网站,你应该提供一个一致的布局和结构。页面的主要元素——banner、navigation、sidebar侧栏,在整个网站中应该出现在的相同位置 。他们也应该标记一致,如使用同一标题结构(heading structure)。这有利于认知障碍者和使用屏幕阅读器(用来处理屏幕上的内容,并大声读出)的用户访问。

发表在 技术 | 标签为 , | 留下评论

无障碍的五个阶段

你可能听说过伊丽沙白·库伯勒·罗斯在其书《论死亡与临终》中提出的“悲痛的五个阶段”。 通过对大量晚期患者的访谈及研究患者临近死亡前的心理活动,将濒临死亡的过程分成五个心理阶段:拒绝、愤怒、挣扎、沮丧、接受。查看这篇博文了解详情。 将这些名词应用到无障碍领域可能有所不妥,但有助于我们理解无障碍,无论是个人层面还是企业级。 无障碍在你的组织中处在哪个阶段?如何确定你对无障碍理解的程度?下面这些话语是我们多年来听到的,可以帮助你判断你所处的阶段: 拒绝(Denial) “这针对的是web‘应用程序’,所以这些规则并不适用于我们” “我们不是政府,所以我们没有必要使它无障碍” “残疾人不会访问我的网站… …他们不是我的客户” 愤怒(Anger) “真不敢相信,他们让我们做这些事情” “为什么我们的团队成员不知道如何做到这一点!?” “这只会花费我们的钱,永远也赚不回来!” “这太不公平了!” 挣扎(Bargaining) “可不可以只兼容A级,不兼容AA级?” “我们可不可以以后再做这件事?” “我们有三个网站,可不可以只让一个网站做到无障碍?” “移动网站不需要做到无障碍,因为我们的主站已经是了。” 沮丧 “哎,我们还得做这些工作,也没看到有啥效果,可那个顾问还告诉我们,我们做错了…” “这真的很难,需要考虑很多地方” “这样做有什么意义呢?无论我们怎么做都不够好” 接受(Acceptance) “在不影响我们的业务目标和网站美观的情况下,让我们的网站被尽可能多的人访问。如果今后需要修改使其更容易访问,我们也会做。” “我们可以做到!” 你在哪个阶段?如果大家都处在接受阶段,那再好不过了,但这可能并不现实。你的组织对无障碍的认识在哪个阶段呐?   REF: Five Stages of Accessibility 译文原地址: 进步博客 | 无障碍的五个阶段

发表在 观点 | 标签为 | 留下评论

创建无障碍的对话框

如今的web应用程序中,对话框如同在桌面应用程序中一样常见。我们使用较少的JavaScript和CSS就可以很容易的显示或隐藏一个元素,但很少会考虑对话框对可访问性的影响。多数情况下,它是可访问性的一个灾难。输入焦点未能正确处理以及屏幕阅读器无法感知内容变化。其实,使对话框可访问并非如此困难,你只需要理解几行代码的作用。 ARIA role 如果你想要屏幕阅读器用户感知到弹出了一个对话框,那么你需要学习一些ARIA role知识。ARIA role [1]为HTML元素提供了额外的语义,让浏览器与屏幕阅读器以更具描述性的方式进行沟通。ARIA定义了大量的角色,改变了屏幕阅读器感知页面中不同元素的方式。与对话框有关的角色有两个:dialog和alertdialog 。 在大多数情况下, 我们使用dialog。将一个元素的role属性设为此值,浏览器则会把该元素看作为一个对话框。 <div id=”my-dialog” role=”dialog”> <– Your dialog code here –> </div> 当role属性值为dialog的元素可见时,浏览器会告知屏幕阅读器一个对话框已打开。这可以让屏幕阅读器用户意识到,他们已经不在页面的常规流中了。 对话框应有描述标签(label)。你可以使用aria-label属性来指明描述文本或者使用aria-labelledby属性来指明包含描述文字的元素的ID。示例如下: <div id=”my-dialog” role=”dialog” aria-label=”New Message”> <– Your dialog code here –> </div> <div id=”my-dialog” role=”dialog” aria-labelledby=”dialog-title”> <h3 id=”dialog-title”>New Message</h3> … 继续阅读

发表在 技术 | 标签为 , , | 留下评论

WAI-ARIA Live Regions

概要 6年前我写了一篇关于W3C的无障碍网页倡议-无障碍的富互联网应用程序 (WAI-ARIA)中的live region属性的文章(译文地址),WAI-ARIA规范在这段时间发生了显著变化,那篇文章中的一些细节现在已经过时了。那篇文章中的例子需要使用XHTML的命名空间,现在HTML5已支持WAI-ARIA了。 富互联网应用 开发人员使用HTML、CSS和JavaScript创建富互联网应用程序时,往往把残疾人士抛在脑后,因为这些应用程序无法提供被辅助技术理解所需的语义信息。可悲的是,过去几年里这种情况并没有多少改变,其实我们可以扭转这种局面。WAI-ARIA能够提供足够的语义,以确保富互联网应用是可以理解的,并且现在已经得到相对较好的支持。 WAI-ARIA规范解决的一个重大问题是页面的部分内容已更新,但使用辅助工具的用户并未得到通知,使用live region可以解决此问题。 实时区域(live regions) 使用辅助工具的用户通过live region可以获知文档的变更部分,而且焦点仍保留在当前活动中。例如,报读一个表中的动态更新的股票信息。live region也可用于帮助理解复杂的小部件(widget)。例如,汉斯·希伦使用一个隐藏的live region来报读返回的条目数目,参见他的自动完成部件例子,根据指示使用光标键来浏览整个列表,如果此时没有这个语境信息,自动完成的效果就不会如此好。下面的属性用于定义一个实时区域。 aria-live 属性 aria-live 属性表示该区块内的内容是实时的,内容的详细变化都会报读。可以使用下面的值来确定详细度(verbosity)。 aria-live=”off” 默认值,表明一个区域不是实时的,不会报读变化。 aria-live=”polite” 更新内容应当在适当时刻报读,比如在用户停止输入时。 aria-live=”assertive” 立即向用户报读更新内容。由于这是突兀的, assertive值应当仅用于更新内容是重要的,应立即通知给用户的情况。 在下面的例子中,无序列表中的文本的变化或增加,都将通知给用户。 使用aria-live=”polite” <ul aria-live=”polite”> <li>Item 1</li> <li>Item 2</li> <li>item 3</li> </ul> aria-atomic属性 aria-atomic属性是一个可选属性,其值可以是true或false(默认值)。当区域内有更新时,使用atomic属性来指示辅助工具应当报读变化区域的部分内容还是全部内容,并受aria-relevant 属性的影响。 如果aria-atomic属性值为true … 继续阅读

发表在 技术 | 标签为 , , , | 留下评论