Labelling like a pro

Let's clarify, first: “labelling” doesn't refer only to <label> tag, but to the techniques to properly put descriptions to various elements. Consider that a lot of accessibility audit problems are linked to this topic, especially those provided by automatic tools (you should take a look at the intro to accessibility debugging, by the way, an article soon available), so understand these guidelines will help you resolve (or avoid) a great number of problems.

We have already discussed labelling form elements, here we'll take a look at all the others.

Titles

It may seem obvious, but let's begin with the first step. Document title, the one between <title> tags in the document <head> must be specified, and its content is super important when dealing with SEO and search engines. Make sure that contains both the main company name, but update it accordingly with the actual page content. It will help you dramatically with search engine indexing and will help all users immediately understand the page content, even if they're on another page and can see only your page tab in their browsers, or if they rapidly glimpse the window title.

Headings

I'll be quick here since we've already seen how to manage headings in another article. Make absolutely sure that your headings contain text (even if "visually-hidden"): it helps web crawlers to understand the main structure of your content and those using assistive technologies to jump straight to specific sections of your content. All technologies in general (in the present or that will come in the future) can potentially leverage properly subdivided content for semantics and navigation purposes.

Semantic regions

Just like headings, they help you as developer in organizing your code, the software to understand the document's general structure and the user to quickly navigate between sections using assistive technologies. They also make your document future-proof: future tools and software will not have to struggle to understand what is your main navigation or content sections, consuming the document without errors in the proper way they're meant to and without the need for patches or refactorings.

A more in-depth article is soon to come.

Contents with images

For each <img> image (or image-like element as <canvas>, <area>, <map> or <object> and <input> of type=”image”) you should ask yourself:

does this image provide content? Then use “alt” for the image description

    <img src="meaningful-image-filename.jgp"
      alt="Black and white close-up photo of milkweed flowers" />

does it have purely decorative purposes? Use role=”none”

  <img src="meaningful-image-filename.jgp" role="none" />

Toolbars (at least if there are more than one)

If you're coding a web application surely you'll have to deal with one or more elements with role=”toolbar”. The good practice here is to add a label to each one, even if it's required only if you have more than one.

Buttons Without a text value

Sometimes you have to deal with buttons containing only an icon or an image. In this case, you need to give a textual explanation of the button action with an "aria-label" or it will be impossible to know what the button action will be.

<button type=”button” aria-label=”You have 5 messages to read” title=”You have 5 messages to read”><span class=”envelope--unread”></button>

<button type=”button” aria-label=”Play” title=”Play”><span class=”icon-play”></button>

Here I've also added a "title" attribute, resulting in a small tooltip when the user focuses or moves the mouse over it.

Label overrides textual content

This behaviour could be really helpful on a couple of occasions, the first really common, the second lesser common but however useful.

adding further info than the text already there: many elements with the same aspect can disorient the user that cannot visually link them to surrounding content. Consider the “play button” of the previous example: if you have only one audio file to play it's obvious what will be played, but if you have lots of audio files arranged in a list, all the buttons will tell you only “play”, leaving to you the burden to remember the filename (if you've already specified it before!). You can add additional info to the label

  <ul class=”song-list”>
      <li class=”song”>
          <span class=”song__title”>Mirror Mirror</span>
          <button type=”button” class=”song__play-button” aria-label=”Play Mirror Mirror”>Play</button>
      </li>
      <li class=”song”>
          <span class=”song__title”>The Bard's song</span>
          <button type=”button” class=”song__play-button” aria-label=”Play The Bard's song”>Play</button>
      </li>
      ... your other great songs ...
  </ul>

reduce the text read for elements with too long content to be useful as a label. Think of an element that can have a label containing your last article: you want it to contain the cover image, the title and the first 30 words of the article itself. Then you realize that reading all the text is not a great idea for assistive technology users. A label can help you reduce useless “content noise”.
```
  <td aria-labelledby=”article-18__title”>
      <img src=”article-18.jpg” alt=”...”>
      <h3 id=”article-18__title”>Yep, my last article!</h3>
      <p>This is an extract from the article main body, too long to be of some utility and inserted here just because of reasons...</p>
  </td>
```

Less-used tags that need labels

Image maps are not so common nowadays. However, if you're about to use one, remember to give each <area> element an “alt” attribute describing the resource the area is about.

<img
  src="floor-plan.jpg"
  usemap="#floor1"
  alt="Floor plan" />
<map id="floor1" name="floor1">
  <area shape="rect" coords="11,12,45,35" href="kitchen.html" alt="Kitchen" />
  <area shape="rect" coords="44,54,90,89" href="livingroom.html" alt="Living room" />
</map>

When Not to Use an Accessibility Label

Not every time is needed adding labels: applying useless labels, describing every single element of your document, could end up rising noise in communication, making your user experience less optimized and navigation time longer.

Avoid repetitions: Avoid using labels when the same text has been read many times;
Avoid labelling decorative elements: there's no need to describe an icon already next to its label, or an image used just for its appeal and not for its explicit meaning.

There could be the chance to have an element that should be only visible to those not using assistive technologies but completely silenced to screen readers. For these you can use the “aria-hidden” attribute set to true, thus forcing screen readers to skip them.