Naming things to improve accessibility

Published 2019-04-18 category: code

One thing you can do to improve the accessibility of your work is to always ensure things have accessible names. Unique and useful names, ideally, so that they can be used for navigation. In this post I’ll explain how browsers decide on the names for links, form fields, tables and form groups.

This post is based on part of my talk 6 ways to make your site more accessible, that I gave at WordCamp Rotterdam last week.

Accessibility Tree

When a user accesses your site, the server will send markup to the browser. This gets turned into trees. We’re probably all familiar with the DOM tree, a live representation of your markup, with all nodes turned into objects that we can read properties of and perform all sorts of functions on.

What many people don’t know, is that there is a second structure that the browser can generate: the accessibility tree. It is based off the DOM tree, and contains all meta information relation related to accessibility: roles, names and properties. Another way to say it: the accessibility tree is how your page gets exposed to assistive technologies.

Assistive Technology

Assistive Technology (AT) is an umbrella term for all sorts of tools that people use to improve how they access things. For computers and the web, they include:

Alternate pointing devices, braille bars, screen magnifiers and screenreaders

All of these tools, to work efficiently, need to know what’s happening on the screen. To find out, they access Platform APIs, built into every major platform, including Windows, Mac and Linux. The APIs can expose everything in the OS, so they know about things like the Start Bar, Dock or the browser’s back button. One thing they don’t know about, is the websites you access. They can’t possibly have the semantic structure of every website built into their APIs, so they rely on an intermediary — this is where the Accessibility Tree comes in. It exposes your website’s structure. As I said, it is based on the DOM, which is based on our mark-up.

Your markup becomes a DOM tree which the accessibility is based on which is then sent to platform APIs and ultimately ends up at assistive technologies A handy flow chart

The accessibility tree exposes roles (is this a header, a footer, a button, a navigation?), names (I’ll get into those in a bit), properties (is the hamburger menu open or closed, is the checkbox checked or not, et cetera) and a number of other things.

If you want to see what this looks like on a site of your choosing, have a look at the Accessibility Panel in Firefox Developer Tools, or check out the accessibility info boxes in Chrome, Safari Tech Preview or Edge developer tools.

Accesssible name computation

Names are one of the things the accessibility tree exposes for its objects. What a thing’s name is, gets derived from markup. There are many aspects that can influence this. If you want to know this in detail, check out the Accessible Name and Description Computation Specification.

Unique names help distinguish

Before going more into how to expose names, let’s look at which names we want. What the names are is crucial for whether they are accessible or not.

What if your family has four cats, and each of them is named ”Alice”? This would be incredibly impractical, as it would make communication difficult. “Has Alice been fed yet?”, you might wonder. “Is Alice outside?”, you might ask your partner. Ambiguity is impractical. Yet, this is what we do when our homepage has four news items, with each “Read more” as its link text.

Four very cute cats Imagine all of your cats were named Alice (photo: stratman2 on Flickr)

This is very common, sadly. In the WebAIM Million project, in which WebAIM looked at over a million sites and ran automated accessibility checks, they found:

24.4% of pages had links with ambiguous link text, such as ‘click here’, ‘more’, ‘continue’, etc.

Reusing “Read more” as the link text for each news item makes our code and content management simpler, but it provides bad usability for screenreader users. When they use the link shortcut to browse through links on the page, they will have no idea where each links leads them. In the example above, when you ask an AT to read out all links, it will read “Link Read more, Link Read more, Link Read more, Link Read more”.

Naming things

So, unique and descriptive names are useful to AT users. Let’s look at which HTML can help us provide names. As I said before, the heuristics for determining names are in a spec, but with just HTML providing names for most things is trivial. The following section is mostly useful for people whose HTML is rusty.

Links

The contents of an <a> element will usually become the accessible name.

So in:

<a href="/win-a-prize">
Win a prize</a>

the accessible name would compute as “Win a prize”.

If there’s just an image, its alt text can also get used:

<a href="/win-a-prize">
  <img src="prize.png" alt="Win a prize" />
</a>

And, to be clear, if there’s nothing provided, the name would be null or empty string, so some people would be unable to win any prize.

Form fields

Form fields get labelled using the <label> element. In their aforementioned research, WebAIM also found:

59% of form inputs were not properly labeled.

Let’s look at what a labelling mistake could look like:

<div>Email</div> <!-- don't do this-->
<input type="email" id="email" />

In this example, the word “Email” appears right before the input, so a portion of your users might be able to visually associate that they belong together. But they aren’t associated, so the input has no name— it will compute as null or '' in the accessibility tree.

Associating can be done by wrapping the input in a <label> element, or by using a for attribute that matches the input’s id attribute:

<label for="email">Email</label> <!-- do this-->
<input type="email" id="email" />

Tables

To give a table a name, you can use its <caption> element. This is used as the first element in a <table>.

Groups in a form

Within forms, you sometimes want to group a set of form inputs, for example a collection of radiobuttons or checkboxes that answer the same question. HTML has <fieldset> for grouping form elements. To name this group as a whole, use the <legend> element:

<fieldset>
  <legend>Don't you love HTML?</legend>
  <input type="radio" name="yesno" id="yes"/>
  <label for="yes">Yes</label>
  <input type="radio" name="yesno" id="no"/>
  <label for="no">No</label>

If you were to inspect this fieldset in the accessibility tree, you will notice that the group is now known as “Don’t you love HTML?”.

What about ARIA?

Those familiar with the Accessible Name and Description Computation spec might wonder at this point: doesn’t ARIA also let us give elements accessible names? It totally does, for instance through the aria-label / aria-labelledby attributes. When added to an element, they overwrite the accessible name (if there was one).

Good reasons to prefer standard HTML tags over ARIA include:

Sometimes ARIA can come in handy, for example if an element doesn’t play along well with your CSS (like if you want a Grid Layout in a fieldset), or if your (client’s) CMS is very inflexible.

It’s the markup that matters

In modern browsers, our markup becomes an accessibility tree that ultimately informs what our interface looks like to assistive technologies. It doesn’t matter as much whether you’ve written this markup:

It is which markup that determines if your site is pleasurable to experience for AT users. In short: it’s the markup that matters

There’s good chance your site already uses all of the above HTML elements that name things. They have existed for many years. But I hope this post explains why it is worth the effort to always ensure the code your site serves to users, includes useful names for assistive technologies. Markup-wise it is trivial to assign names to all things on our site, the real challenge is probably two fold. It’s about content (do we come up with useful and distinguishable names), and about tech (can we ensure the right markup gets into our user’s DOMs).

Comments, likes & shares (78)

Eka, Jitendra Vyas, , Anneke Sinnema, adrian , Phil Thompson, Timon van Hasselt, Erik Kroes, Dean Birkett, geertmelotte, Andreea Popescu, Guillaume Deblock, Juan Olvera , Randall Kaemmerer, Alberto Calvo, Stefan Etoh, Ser Bob of Tarth, Enmanuel Ruffinelli, 지성봉(Seong bong Ji), GnarlyQuinn, desliguei o aquecedor da piscina, Johan Groenen and Erwin / (perceived) performance / technical UX/CRO liked this

Milo Vermeulen, Jitendra Vyas, geertmelotte, Shari Hunt, Eric Bailey, Kat, Ser Bob of Tarth and Eric Bailey reposted this

Roel Van Gils wrote on 20 April 2019:
What if your family has four cats, and each of them is named Alice? That sounds very impractical, but it’s what poor markup translates to for screenreader users. In this latest post, @hidde explains how to name things properly. #a11y

hiddedevries.nl/en/blog/2019-0…
Michael Scharnagl wrote on 23 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Andreea Popescu wrote on 23 April 2019:
Great article.
Benjy Stanton wrote on 23 April 2019:
Using "read more" as link text makes as much sense as having 4 cats and calling them all Alice. hiddedevries.nl/en/blog/2019-0…
Claire Brotherton wrote on 23 April 2019:
Why naming things in your code is so important for accessibility hiddedevries.nl/en/blog/2019-0…
Rogier Barendregt wrote on 23 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Rachel Ann Fraser wrote on 26 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Yohan J. Rodríguez wrote on 26 April 2019:
#CSS #Automated | Naming Things to Improve Accessibility hiddedevries.nl/en/blog/2019-0…
Ann wrote on 25 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Fresh Frontend Links wrote on 26 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Ruthie Edwards wrote on 28 April 2019:
Something I didn’t consider when building my current website — accessible component names! hiddedevries.nl/en/blog/2019-0…
Eduardo Meza-Etienne, MSc, MIM, CPACC wrote on 28 April 2019:
Naming things to improve accessibility #a11y hiddedevries.nl/en/blog/2019-0…
지성봉(Seong bong Ji) wrote on 29 April 2019:
I am very grateful for sharing a good article. I would like to translate this article into Korean and share it with developers via my blog, would you allow me?
Hidde wrote on 29 April 2019:
Absolutely, please do. Could you please link back to the original and send me a link so that I can link to your translation? Thanks!
지성봉(Seong bong Ji) wrote on 29 April 2019:
Oh! Thank you. Of course. I'll send you a link after I translate and post it. :)
Hana Lodhi wrote on 29 April 2019:
'...this post explains why it is worth the effort to always ensure the code your site serves to users, includes useful names for assistive technologies... hiddedevries.nl/en/blog/2019-0…
ダーシノ wrote on 29 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0… セマンティックマークアップもリンクのテキストも重要という話。「詳細はこちら」というリンク、「こちら」ってどちらだよ!ってなるから意味の伝わるテキスト(名前)を付けましょうとか、labelやcaptionで名前を付けようという内容
Jeremy Keith wrote on 29 April 2019:

Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.

Adactio Links wrote on 29 April 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Baldur Bjarnason @baldur@toot.cafe wrote on 29 April 2019:
“Naming things to improve accessibility” hiddedevries.nl/en/blog/2019-0…
Ann wrote on 29 April 2019:
Naming things to improve #accessibility hiddedevries.nl/en/blog/2019-0…
Floor Drees wrote on 30 April 2019:
TIL: Reusing link text ("Read more") for each item makes our code and content management simpler, but it provides bad usability for screenreader users.

Also label your form fields correctly, and other tips
Floor Drees wrote on 30 April 2019:
TIL: Reusing link text ("Read more") for each item makes our code and content management simpler, but it provides bad usability for screenreader users.

Also label your form fields correctly, and other tips
Federica Dardi wrote on 30 April 2019:
Una cosa che puoi fare per migliorare il tuo lavoro è assicurarti che le cose abbiano nomi accessibili
hiddedevries.nl/en/blog/2019-0…
John Hegener wrote on 30 April 2019:
hiddedevries.nl/en/blog/2019-0… #UX #uxdesign
DEVELOPER NEWZ wrote on 1 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Dakshraj Enterprise wrote on 2 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
freshmade wrote on 2 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0… via @chriscoyier
Charlie Charlie wrote on 2 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Monsoonfish wrote on 2 May 2019:
Naming things to improve #accessibility

hiddedevries.nl/en/blog/2019-0…

#css #css3 #html #html5 #DesignThinking #python #JavaScript #programming #business #code #tech #technology #nodejs #webdev #DevOps #coding #UX #WebDesign #WebDevelopment #FrontEnd #developers #uiux #webdeveloper
越智です wrote on 2 May 2019:
見てる。/hiddedevries.nl/en/blog/2019-0…
Arturo Wibawa wrote on 2 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Priya wrote on 2 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0… #a11y
Finest Design LTD wrote on 2 May 2019:
hiddedevries.nl/en/blog/2019-0…
The A11Y Project wrote on 3 May 2019:
"One thing you can do to improve the accessibility of your work is to always ensure things have accessible names." hiddedevries.nl/en/blog/2019-0…
Animadio wrote on 4 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Web Axe wrote on 5 May 2019:
Naming things to improve accessibility: hiddedevries.nl/en/blog/2019-0… HT @LyndonDunbar #webdev #a11y #html
dailydevlinks. wrote on 6 May 2019:
Naming things to improve accessibility: hiddedevries.nl/en/blog/2019-0…

#html #css #javascript #webdev #dailydevlinks
Aurélie wrote on 9 May 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Hassell Inclusion wrote on 9 May 2019:
Hidde de Vries writes about improving the accessibility of your work by ensuring things have accessible names
ow.ly/46nZ50tiZaK @hdv @TheUXCollective #UX #A11y #InclusiveDesign
Hassell Inclusion wrote on 9 May 2019:
Hidde de Vries writes about improving the accessibility of your work by ensuring things have accessible names
ow.ly/46nZ50tiZaK @hdv @TheUXCollective #UX #A11y #InclusiveDesign
Jahangeer Ansari wrote on 16 May 2019:
Naming things to improve accessibility #UXdesign #UX hiddedevries.nl/en/blog/2019-0…
Cath wrote on 17 May 2019:
naming things to improve accessibility: hiddedevries.nl/en/blog/2019-0… #accessibility #ux
Delany Bisbee wrote on 12 October 2019:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Women Who Code BOS wrote on 15 January 2020:
This post explains why it is worth the effort to always ensure the code your site serves to users includes useful names for assistive technologies. hiddedevries.nl/en/blog/2019-0…
Christine Amsel wrote on 16 March 2020:
Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…

常见可访问性问题

简单的方法就能轻易解决

WebAIM已发布最新报告。通过自动检测的方法检测网站,报告针对100万个网站上出现的可用性问题进行了分析。其中哪些问题是可轻而易举改正的呢?

扩展阅读

WebAIM,是一家总部位于美国犹他州的非营利组织。自2019年,启动WebAIM Million’项目。每年发布综合分析报告,观察互联网可用性的发展趋势和改善/下降。
报告内容很有见地。值得推荐阅读!

基于自动可用性检测而进行调查,需要加上以下警告:

一是“易于感知的问题”和“对用户造成影响的问题”,两者无关,是不一样的。自动化测试也只涵盖了所有互联网可用性中的一小部分,因为有些问题机器(现在或永远)无法检测。我并不是说这会降低调查的作用,而是想明确指出这一点。W3C的ACT-Rules 组织致力于指定合理的测试规则。

好的,让我们看看当今最热门的问题以及开发人员、浏览器和 CMS 是如何解决问题的。

低文本对比度

在某些情况下,文本颜色和背景颜色的对比度低于WCAG阈值(另请参见MDN on contrast)。

通过安装插件(如:Contrast Ratio 设计师可以检查对比度。

开发人员可以使用自动对比度检查器,来确保避免使用低对比度文本。运行一个检查器,如Firefox 开发工具辅助功能面板中的检查器或CI/CD 的ax,或者将两种颜色粘贴到一个手动工具中,如 Contrast Ratio。

设计人员和开发人员都可以使用 Polypane 的对比度检查器,它会给出替代方案建议,这不仅可以更轻松地找到问题,还可以同时修复问题。

用户可以使用像Fix Contrast这样的插件:它可以即时微调颜色,这样就不必忍受低对比度文本。

针对网页内容无障碍指南的新颜色对比度算法之一问题,人们进行诸多讨论,目前讨论仍在进行中。

缺少替代文字

当你创建内容,对图片进行描述。在使用Twitter的内容管理器,甚至在GitHub上发布帖子:使用替代文本功能,以便看不到图像的用户可以访问图片的替代文本。在不支持替代文本的平台上,例如 Slack 或移动 LinkedIn (!),可以用文本描述图像。如果您选择 CMS 或内容平台,确保它可以处理或设置使用替代文本。

生成的 HTML 如下:

<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />

<!-- image with redundant content -->
<img src="hidde.png" alt="" /> 
<p>Photo of Hidde</p>

你可根据Alt Decision Tree书写替代文本。文本内容的要点是,如果图像的位置显示出一个正方形,在正方形中写什么以使其不影响阅读?可以选择将其留空。就像上面的例子一样,有一张照片,下面有一段描述它的段落。在这种情况下,在alt属性中写“Hidde”或“Hidde 的照片”是多余的,最好使用一个空的alt(但不要将属性保留在那里,否则某些浏览器会使用图像 URL 作为替代)。

用户可以使用 Microsoft Edge,它可以填补缺失的替代文本。AI 不擅长理解意图或背景,但精通识别文本。下次新闻网站再发布新冠病毒防治新规则的图片,并不带有替代文本时(就像荷兰主要新闻网站在整个疫情期间所做的那样),Edge 的用户可以理解其内容。

空链接和按钮

当链接、按钮或其他交互元素没有名称时,屏幕阅读器或语音控制等辅助技术无法唯一识别它们。如果要与之交互,则需要给它们定义一个名称。

屏幕阅读器说“这里有 4 个按钮:按钮、按钮、按钮和按钮”与“这里有 4 个按钮:发布内容、删除内容、更改为草稿、上传图像”,想象一下两者之间的区别。在第一种情况下,需要按一下按钮才知道按钮的用处;在第二种情况下,不需要任何额外操作。

名称源自文本内容,例如按钮内的实际文本,或者可以通过属性添加。有关更多详细信息,请参阅命名以提高可访问性控件命名规范

开发人员需要确保他们构建的所有控件(链接、按钮、表单字段等)都有名称,最好是有独立意义:

<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>

<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/">read more</a><!-- avoid -->

<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->

浏览器有时可以从附近的文本中节选名称。这并不理想,可能会导致错误和令人困惑的猜测,导致用户体验糟糕。开发人员最清楚控件的作用并能命名它。

缺少表单标签

表单标签受命名影响,因为表单单独命名表单元素。

开发人员设置表单输入框的for属性并指向input/select/textareaid,可以解决此问题,这也使得单击标签将光标移动到输入狂

<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />

他们还可以给输入框添加一个aria-label属性(注意,ARIA 标签解析得不好)。

缺少表格标签

开发人员应确保元素具有 lang 属性,并使用正确语言:

<!-- marks this document as 'in English -->
<html lang="en">

有时有忘记,因为<html> 元素存在于哪些从未修改过的模板中,但这并不难,因此请务必仔细检查此属性是否存在并设置为正确的语言。

如果页面的一部分内容是另一种语言的,在相应DOM节点元素上再次设置lang属性。当使用国际化的插件时,确保设置了 langs 。

CMS可以确保 lang 属性的正确设置。浏览器可以猜测语言,但也有可能出错,特别是在区分方言时:它们通常对人很重要,而对机器则不那么重要。

原文地址:https://hidde.blog/common-a11y-issues/