Naming things to improve accessibility

in 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 (I’d love to repeat it, feel free to get in touch).

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>
</fieldset>

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 & mentions (73)

Milo Vermeulen reposted this
Eka likes this
Jitendra Vyas reposted this
Jitendra Vyas likes this
likes this
Anneke Sinnema likes this
adrian likes this
Phil Thompson likes this
Timon van Hasselt likes this
Roel Van Gils replied: 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…
Erik Kroes likes this
Dean Birkett likes this
geertmelotte reposted this
geertmelotte likes this
Vincent van Beek 23 Apr 2019 05:36:58

And we’re thankfull Hidde Works at The Hague City now as well.

Michael Scharnagl replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Andreea Popescu replied: Great article.
Andreea Popescu likes this
Benjy Stanton replied: 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…
Guillaume Deblock likes this
Claire Brotherton replied: Why naming things in your code is so important for accessibility hiddedevries.nl/en/blog/2019-0…
Rogier Barendregt replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Shari Hunt reposted this
Eric Bailey reposted this
Kat reposted this
Juan Olvera likes this
Randall Kaemmerer likes this
Alberto Calvo likes this
Stefan Etoh likes this
Ann replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Bob 25 Apr 2019 16:14:01

There is a typo in one of the links that dramatically changes it’s meaning.

Xenophone/xenophobe

Ser Bob of Tarth reposted this
Ser Bob of Tarth likes this
Enmanuel Ruffinelli likes this
Rachel Ann Fraser replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Yohan J. Rodríguez replied: #CSS #Automated | Naming Things to Improve Accessibility hiddedevries.nl/en/blog/2019-0…
Fresh Frontend Links replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Ruthie Edwards replied: 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 replied: Naming things to improve accessibility #a11y hiddedevries.nl/en/blog/2019-0…
지성봉(Seong bong Ji) likes this
지성봉(Seong bong Ji) replied: 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 replied: 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) replied: Oh! Thank you. Of course. I'll send you a link after I translate and post it. :)
Hana Lodhi replied: '...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…
Ann replied: Naming things to improve #accessibility hiddedevries.nl/en/blog/2019-0…
ダーシノ replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0… セマンティックマークアップもリンクのテキストも重要という話。「詳細はこちら」というリンク、「こちら」ってどちらだよ!ってなるから意味の伝わるテキスト(名前)を付けましょうとか、labelやcaptionで名前を付けようという内容
Jeremy Keith replied:

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

Adactio Links replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Baldur Bjarnason @baldur@toot.cafe replied: “Naming things to improve accessibility” hiddedevries.nl/en/blog/2019-0…
Floor Drees replied: 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 replied: 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 replied: 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 replied: hiddedevries.nl/en/blog/2019-0… #UX #uxdesign
DEVELOPER NEWZ replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Dakshraj Enterprise replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
freshmade replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0… via @chriscoyier
Charlie Charlie replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Monsoonfish replied: 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
越智です replied: 見てる。/hiddedevries.nl/en/blog/2019-0…
Arturo Wibawa replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Finest Design LTD replied: hiddedevries.nl/en/blog/2019-0…
Priya replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0… #a11y
The A11Y Project replied: "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 replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Web Axe replied: Naming things to improve accessibility: hiddedevries.nl/en/blog/2019-0… HT @LyndonDunbar #webdev #a11y #html
dailydevlinks. replied: Naming things to improve accessibility: hiddedevries.nl/en/blog/2019-0…

#html #css #javascript #webdev #dailydevlinks
Rob 06 May 2019 13:58:00

Very good explained with the right examples.

Aurélie replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Hassell Inclusion replied: 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 replied: 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 replied: Naming things to improve accessibility #UXdesign #UX hiddedevries.nl/en/blog/2019-0…
Cath replied: naming things to improve accessibility: hiddedevries.nl/en/blog/2019-0… #accessibility #ux
Delany Bisbee replied: Naming things to improve accessibility hiddedevries.nl/en/blog/2019-0…
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.