How to test for missing form labels

Imagine arriving on a website and tabbing to a form field. Instead of hearing "Search, edit, blank" or "Email address, required, edit, blank", your screen reader simply announces "edit field". You know there's somewhere to type, but you don't know what the website wants. Is it a search box? An email field? A postcode field? A coupon code? A bird? A plane? Superman, sorry, got carried away. The user is left guessing. WTF is going on? By the way, if you want to know more about using a screen reader, check out my article, How to test with a screen reader. 

In my previous WonderProxy articles, I explored the two biggest accessibility issues on the web. How to test colour contrast and How to test alternative text (alt-text). According to the latest WebAIM Million report, low contrast remains the most common accessibility problem, while missing alternative text ranks second. The third most common issue might sound less dramatic, but it creates a seriously frustrating experience for screen reader users. Missing form labels. WebAIM found that 51% of home pages had missing form input labels. 

Why do missing labels matter? 

A missing label can seem like a small thing. You can see the page. You recognise search boxes, right? A blind or low-vision person doesn't have the visual clues you and I rely on. They need labels announced so they can understand what a field is for, what it does, what state it is in, and how it fits into the surrounding form. 

The problem isn't limited to text inputs either. Missing labels affect search bars, login fields, registration forms, feedback forms, dropdown lists, date pickers and other interactive controls. A select field without a proper label can leave users wondering what options they're choosing between. A search box without a label might as well be completely invisible to someone navigating by form controls. It may appear as ‘edit’ or similar, which, if there are a few of them, is arguably worse than being invisible! These issues create unnecessary friction when users are trying to complete tasks quickly. 

What is the ARIA specification and aria-labels? 

I’ll try to keep this as simple as possible. ARIA stands for Accessible Rich Internet Applications. It is a technical specification published by W3C (World Wide Web Consortium) to help people increase the accessibility of web pages. It covers roles, states, and properties that make web content accessible. An aria-label gives an element an accessible plain-text name when there is no visible text label on the screen. 

While aria-label is useful, it should not automatically replace visible labels. A properly associated HTML <label> element is usually the best solution because it helps all users understand the field's purpose. The simplest way to put it is. Use native HTML first and add ARIA only when it can’t do the job. That is literally the first rule of ARIA. The others are: 

• Do not change the semantics of native HTML (unless you really have to)
• All interactive ARIA controls must be usable with the keyboard. 
• Do not remove semantics or hide focusable elements (using role="presentation" or aria-hidden="true" on a focusable element) 
• Ensure all interactive elements have an accessible name (Accessibility API accessible name) 

How to test

Quality engineers and developers can catch many of these issues quickly. Navigate forms with a screen reader, inspect for associated labels and ask yourself a simple question. If I couldn't see this page, would I know what information belongs in this field? 

A practical testing checklist for form labels

You don't need to be an accessibility specialist to find form bugs like missing or wrong labels. Start with these checks and questions. 

Automated (Linters, axe-core, WAVE scan, DOM inspectors) 

• Fields without visible labels have an appropriate accessible name using aria-label or aria-labelledby. 

Visual and interactive checking 

• Every form field has a visible label that clearly describes its purpose. 
• Clicking or tapping a label places focus into the associated field. (properly associated) 
• Search boxes have a descriptive label such as "Search products" or "Search the knowledge base" rather than simply relying on placeholder text. (context matters) 
• Are required fields clearly identified? Asterisks * or similar. (more context, and saving a user from going wrong) 
• Do dropdowns, select fields and date pickers have meaningful labels? (did I mention context?) 
• Checkboxes and radio buttons have labels that explain their purpose. (duh!) 
• Can you still find out what the field is after you start typing? 
• Labels make sense on their own? For example, "Search", "Email address" and "Promo code" are much more useful than generic labels such as "Field 1, 2, and 3". 
• Do error messages say which field has the problem? 

Screen reader and keyboard checks 

• Are populated fields announced correctly by a screen reader?
• Do screen reader users know where they are and what’s going on when tabbing through the page?  
• Test your most common user journeys such as registration, login, checkout, etc. using only the keyboard. 
• Use a screen reader such as NVDA, JAWS, or VoiceOver to hear what is said for yourself, rather than relying only on automated accessibility tools. 
• Are required fields announced to screen reader users? 

To sum up  

Remember, a screen reader user cannot necessarily glance around the page to understand what a field does. If a form only makes sense when you can see it, then it doesn’t make sense to all. A few minutes spent testing labels can be the difference between a task that feels easy and one that feels like a poorly designed game. Now you know. So use your new knowledge and get stuck in.