One of the most important keys to creating accessible forms is ensuring that each of your input elements has an accessible name. The easiest, most reliable method of doing this is by using a
<label> tag. For example, the ubiquitous “log in” form:
<form action="#" method="post"> <fieldset> <legend>Log in</legend> <label for="user">Username:</label> <input id="user" type="text" /> <label for="pass">Password:</label> <input id="pass" type="password" /> <button>Submit</button> </fieldset> </form>
You should notice that each input element has a corresponding
<label> tag, that is associated with an input element by way of the “for” attribute referencing the input element’s `id` attribute.
It’s a very easy tip, and absolutely essential in achieving an accessible form. It’s not only so that you can click on the label and automatically focus the field. That’s usually where the accessible form lessons stop. Nobody ever explained to me why/ how this actually made a form accessible, but understanding why makes this even more important to get right. The answer lies in how screen readers handle interaction via keyboard.
How screen reader users navigate a page
As a visual user, you rarely read a page from top to bottom/ left to right your first time around a page. Usually, you will scan the page in a random order looking for things that are relevant to your purpose on the page. You may scan for available links or buttons or may scroll down the page to sections and headings. You will most likely skip over ads and other parts of the page you are familiar with, like the main navigation.
Screen readers give users the same functionality via keystrokes, or keyboard shortcuts. This is accomplished by hijacking, or intercepting, all keyboard interactions. Now users, with JAWS for example, can use the `H` key to navigate headers or INSERT+F6 to list all headers, `B` to navigate buttons or INSERT+CTRL+B to list all buttons. Up/Down arrow is used to read line by line, and left/ right arrow is used to read character by character. This is where things get interesting.
When a screen reader encounters a form, it switches into “forms mode.” In forms mode, the screen reader stops intercepting keystrokes because they need to be passed directly to the form input. `B` actually means the letter `B` and not button. The down arrow is literally moving your cursor down one line or selecting a drop down item instead just reading the next line. Essentially, the keystrokes used to navigate and explore the page are gone. In this context, keystrokes are used for data entry purposes and the ability to discover/ read content is gone. So, with no way to navigate the page except for tab to move/ focus between elements how else would a user know what form elements are *for*? See what I did there?
Without an explicit label associated with the input, the information is completely lost. As a consequence, your users will be as well. Using an explicit label for all your form inputs will ensure all users have the proper information and context needed to complete their task. It only takes a few extra keystrokes but makes a huge difference.