Web accessibility
in terms and tools
you already know

One primary example of things you can't do (yet) with standard HTML is putting images inside of a <select> element. This is a common ask from developers, but requires a custom element, because the standard one doesn't provide this functionality.

Well the good news is that the Open UI project is working on making things like this a reality—check out their site for more info!

Let's consider a simple page, with a figure and a button. The figure has some alternative text, and the button might, in some frameworks, end up being wrapped in multiple layers of <div>s, creating the infamous "<div> soup" effect. If you inspect this page in the DevTools DOM panel, you get a representation of the living DOM tree in memory. It looks like HTML, but it's live and you (and your scripts) can do anything with it.

But what sort of info is important to assistive technologies? Definitely similar stuff: the order or structure; some of the types of elements (the semantic ones); and things like content alternatives for images, for example. Some other stuff isn't so important—the semantically-neutral <div> soup could be losslessly stripped out, for example.

If you activate the accessibility tree view in the DevTools, you'll find something similar to the DOM, but pared back in some ways (and maybe quite detailed in others). The accessibility tree provides the subset of the DOM tree that is relevant to assistive technologies, and it is the thing that assistive technologies can query in order to do their job of both presenting the content in the appropriate way for the user, and in some cases to help the user navigate about the page.

Bringing it together

Orders of precedence come up a lot in computing, and you have most likely come accross them before. The next example shows how we might improve the labelling of buttons in a table, and also demonstrates the effect of the order of precedence we use to calculate an element's accessible name.

This table represents a shopping basket with some items in it. The buttons at the end of each row are for deleting that item from the basket. They are standard HTML button elements, labelled by a unicode "wastebasket" character—which is announced correctly as "wastebasket"e; by screen readers. Also, if you Tab around the table, moving between rows will cause most screen readers to announce the row header (if semantically provided) before the name of the button, so you'd hear something like "Pineapple Wastebasket button" and "Ironing board Wastebasket button" as you Tab into and through the table.

This behaviour is quite helpful already, but we can improve it. One way that people using screen readers navigate is to bring up a list of controls, such as a list of buttons, on the page. In this case, having the buttons labelled just "wastebasket" isn't very helpful. Also the idea of a bin meaning "delete" may be clear to some, but it's quite a visual metaphor, and may not be clear to everyone (visually-browsing or otherwise).

So the first thing we could do is to inspect the <button> elements, and see indeed that their accessible names come from their contents: the Unicode "wastebasket" character.

We could then override this by supplying each <button> element with an aria-label="Remove" attribute that gives it an invisible accessible name of "Remove", which would be announced by a screen reader. In fact, if you inspect the <button> now, you will see that the previous name (the wastebasket character) has been superceded by the aria-label value. This is becuase aria-label has higher precedence in the accessible name calculation than the contents of the element.

But we've just made the names clearer—we've not solved the ambiguity problem: they're all just going to be called "Remove" now instead.

We can solve this by employing two neat tricks; one of which we just used:

• We can override the accessible name of the button again, by using the highest-precedence aria-labelledby attribute—which takes the IDs of the elements whose contents should form our buttons' accessible names, rather than a text string that directly is intended to be the accessible name.

• We can make that aria-labelledby attribute value self-referencing—so it uses the button's current name (from its existing aria-label attribute in conjunction with the table's row header).

Sounds complicated, but it's as simple as just adding another attribute to the <button> element: aria-labelledby="remove-1 item-1" for example. Check it out and you'll see the effect in the accessibility inspector, and in a screen reader. Voilà: bringing up a list of buttons (if you do the same thing to the other one!) will clearly show which button does what.

We can now understand what was going wonky in the first example, where the visually-apparent "Log in" button was being announced as "Sign in": this was becuase an aria-label attribute had been set to override the text within the <button> element. You might think this is a contrived example—and, technically, this one is, because I made it on purpose—but this sort of thing happens loads in the wild; partly becuase many frameworks get a bit over-the-top about setting attributes like aria-label.

Frameworks do this in an effort to be helpful, no doubt, but as the saying goes: "ot of sight, out of mind" and this is especially true if you're not aware that your framework is doing this, nor the huge impact doing this could have if—or rather when, inevitably—the two competing "labels" go out of synch.

This is why it's such good practice to:

• Try to keep all important text visible on the page, for everyone. Don't make things just for people you think are using some sort of assistive technology (quite often this leads to wrong assumptions of all kinds, as helpfully as it may be intended).

• If you must provide an invisible accessible name, like in the table example above, which referenced the row header: again, try to use aria-labelledby to ensure that the association is made to another visible element on the page, to avoid repetition, and synchronisation issues in future. Or, at the least, be sure that your framework or back-end code is architected in a clean, "don't repeat yourself" manner.

The DevTools are awesome, but there are some things browsers don't show you—or at least don't show you in much detail (yet).

For example, there are a set of HTML elements that automatically create invisible regions of the page, called "landmark regions". These landmarks provide a broad overview of the content on the page, and thus can be really helpful for people using assistive technologies, because they can help users do things like skip over the navigation links, straight to the main content, or otherwise quickly access the part of the page they're after. Check out my a11yTO talk on Landmarks for more info. Anyway, those elements are:

Whilst DevTools does show you the role that an element is exposing, there's currently no way to highlight landmarks visually (for debugging), nor is there a way to bring up a tree of landmarks on the page. Such debugging tools would be helpful, because some elements only form landmark regions if they're given accessible names, or in other circumstances.

It's also of note that browsers don't currently expose landmark regions to keyboard users who are not using some sort of assistive technology, which would also be pretty cool, but that's outside the scope of DevTools.

To acheive all of the above today, you can use extensions—which could become part of the browser, as well as part of the DevTools, in future.

Remember that it's vital to consider accessibility from the inception of a project, and at all stages—exactly as Geri has outlined in her talk on "shifting left".

Please listen to Geri's story; it's great! But, brutally briefly, a couple of ways to think about accessibility in design include…

• As a designer, think about the heading hierarchy and landmark structure of your pages.

• Also think about what the keyboard interaction would be with any interactive widget.

In addition, it's really important to…