In many situations, too, a single control would not be made directly accessible. The element that contains all the controls would be the accessible element, as in the following example:

<div role="group" tabindex="0">
    <img role="button" … />
    <img role="button" … />
</div>

Access to the individual controls inside the grouping div would be script-enabled. This would allow the reader to quickly skip past the control set if they aren’t interested in what it does (otherwise they would have to tab through every control inside it).

A last note for this section concerns event handlers. Events are what are used to trigger script actions (onclick, onblur, etc.). How you wire up your events can impact on the ability of the reader to access your controls, and can lead to keyboard traps (i.e., the inability to leave the control), so you need to pay attention to how you add them.

We could add an onclick event to our image button to start playback as follows:

<img src="controls/start.png"
        id="audio-start"
        alt="Start"
        role="button"
        tabindex="0"
        onclick="startPlayback('audio01')"/>

But, if we’d accidentally forgotten the tabindex attribute, a reader navigating by keyboard would not have been able to find or access this control. Even though onclick is considered a device-independent event, if the reader cannot reach the element they cannot use the Enter key to activate it, effectively hiding the functionality from them.

You should always ensure that actions can be triggered in a device-independent manner, even if that means repeating your script call in more than one event type. Don’t rely on any of your readers using a mouse, for example.

But again, it pays to engage people who can test your content in real-world scenarios to help discover these issues than to hope you’ve thought of everything.

Forms

Having covered how to create custom controls, we’ll now turn to forms, which are another common problem area ARIA helps address. To repeat myself for a moment, though, the first best practice when creating forms is to always use the native form elements that HTML5 provides. See the last section again for why rolling your own is not a good idea.

When it comes to implementing forms, the logical ordering of elements is one key to simplifying access and comprehension. The use of tabindex can help to correct navigation, as we just covered, but it’s better to ensure your form is logically navigable in the first place. Group form fields and their labels together when you can, or place them immediately next to each other so that one always follows the other in the reading order.

And always clearly identify the purpose of form fields using the label element. You should also always add the new HTML5 for attribute so that the labels can be located regardless of how the reader enters the field or where they are located in the document markup. This attribute identifies the id of the form element the label element labels:

<label id="fname-label" for="fname">First name:</label>

<input type="text"
          id="fname"
          name="first-name"
          aria-labelledby="fname-label" />

I’ve also added the aria-labelledby attribute to the input element in this example to ensure maximum compatibility across systems, but its use is critical if your form field is not identified by a label element (only label takes the for attribute). As the label element can be used in just about every element that can carry a label, there’s little good reason to omit using it.

For example, if you have to use a table to lay out your form, don’t be lazy and use table cells alone to convey meaning:

<table>
    <tr>
        <td>
            <label id="fname-label" for="fname">First name:</label>
        </td>
        <td>
            <input type="text"
                      id="fname"
                      name="first-name"
                      aria-labelledby="fname-label" />
        </td>
    </tr>
    …
<table>

Note that you also should include the for attribute regardless of whether the label precedes, follows or includes the form field.

Another pain point comes when a reader fills in a form only to discover after the fact that you had special instructions they were supposed to follow. When specifying entry requirements for completing the field, include them within the label or attach an aria-describedby attribute so that the reader can be informed right away:

<label for="username-label">User name:</label>

<input type="text"
          id="uname"
          name="username"
          aria-labelledby="username-label"
          aria-describedby="username-req" />

<span id="username-req">User names must be between 8 and 16 characters in length and contain only alphanumeric characters.</span>