Naming things to improve accessibility

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 (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 (75)

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…
Hidde de Vries (@hdv) is a freelance front-end and accessibility specialist in Rotterdam (NL), conference speaker and workshop teacher. Currently, he works for the W3C in the WAI team (views are his own). Previously he was at Mozilla, the Dutch government replied:

Wow, the year only has 8 days left! Time for a review.

Like last year, I’ve divided this into highlights and things I learned.

Highlights

Projects

In the first half year of 2019, I continued my project at Mozilla’s Open Innovation team, building their People directory, and worked in the City of The Hague on accessibility and the internal design system.

In July I started a new project: at the W3C’s Web Accessibility Initiative (WAI), I am now working as part of the European Commission-funded WAI-Guide project. My work there is focused on improving the accessibility of/in tools that create web content, like CMSes. In short: we want more accessibility both for content editors (a good editing experience) and for end users (good output).

Apart from my work at the W3C, I’ve been doing the occasional WCAG audit and accessibility/CSS workshop in my own capacity too.

Speaking

Last year I spoke at my first conference. This year I got the opportunity to do new (and some older) talks in various places.

In March, I did a talk called It’s the markup that matters at De Voorhoede. It was part of their Future Proof Components event, and covered building accessible components, accessibility trees and the AOM.

At WordCamp Rotterdam and Inclusive Design Ghent, I shared 6 ways to make your site more accessible, based on my experience looking at common accessibility problems that front-end developers can do something about.

In October, I presented a very short lightning talk at the Web We Want session at View Source Conference, about how some accessibility problems could cease to exist if browsers would automatically fix them. The problems: zoomability, readability, color contrast and focus indication (the first three are each solved in at least one browser, the fourth has not). This talk, shockingly, won both the jury and audience award.

Also in October was a talk called Breaking barriers with your CMS at the Fronteers Jam Session (on behalf of W3C/WAI). This presented some of my recent work at WAI: it explained ATAG and the role of the CMS in accessibility efforts.

At the Design in Government Conference in November, I talked about the case for web accessibility from philosophical ethics, attending on behalf of W3C, and I did an updated version of my graphic design on the web talk in Dutch for Freshheads in Tilburg.

Then in December, I joined dotCSS to talk about the history of CSS: On the origin of cascades put some of that in a Darwin-themed talk. The venue was enormous and intimidating, and there was transport strikes, but the event itself was excellent, with a great atmosphere and very well organised.

I also did a number of in-house talks and workshops, about CSS Layout, ARIA and accessibility guidelines.

Reading

I read much more than last year (72 books so far), and have written more about books on this blog (see reading list about equality and reading list about tech and society). Reading more books helped me read less social media, watch less video and generally relax more.

Some notes:

  • Audiobooks are great as you can read them in situations where holding a book doesn’t work (e.g. walking a dog, housework)
  • To read more, finding the right books is half of the work (I mean, not literally… but it is important). I found more people to follow on Goodreads, keep a close eye on the literary supplements in the papers and love posts like 2018: books in review by Karolina Szczur.
  • Dutch libraries have ebooks and audiobooks that can be ‘borrowed’ via apps.

Writing

This year marked over 100 posts on this blog, I wrote 24 posts (including this one).

Some posts that people found interesting:

I also contributed to the Mozilla Hacks blog, writing Indicating focus to improve accessibility and How accessibility trees inform assistive tech. Thanks to Havi Hoffman for the opportunity!

Cities

This year I traveled to Antwerp, Berlin, Bristol, Essen, Ghent, Nice, Paris, Taipei and Vienna, using trains where possible, but I need to do better at that.

Things I learned

Here’s some random things that I learned about in the past year:

  • Recently I started working on an app with Svelte, the front-end framework that doesn’t ship in its entirety to the user’s runtime, but tries to compile as much as possible to vanilla JavaScript. Small bundles, yay!
  • As I started my project at the W3C, I learned a lot the standards process, the dynamics in Working Groups and the bots that help run teleconferences.
  • A large part of my work centered around authoring tools, or tools that create web content, and how they can help bring more accessibility in the world.
  • I became increasingly aware of the role of surveillance capitalism in the world.
  • I learned to love AirTable as a way to organise and plan the non-coding parts of my work, which are becoming a larger part of the whole

In any case, I’d like to thank the readers of this blog for reading and sharing the posts I’ve published, it means a lot. I wish you all a great 2020!

Women Who Code BOS 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…
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.