Practical Accessibility Tips for Developers
Labels: Automatic Checks and Manual Validation
Labels are essential for screen reader users and overall accessibility. While automated tools can verify that labels are present on interactive elements, determining whether a label is meaningful and contextually appropriate still requires manual testing.
Screen reader testing can be challenging for developers and testers who aren’t regular users. Practical alternatives include:
- Inspecting labels and roles through the browser DevTools accessibility tree.
- Using voice navigation to verify that elements are reachable and operable by spoken commands.
Tip
If you do test with a screen reader, the results will only be reliable if your environment is correctly set up. The right screen reader depends on both your operating system and the browser you’re testing with. Sara Soueidan’s guide to setting up an accessible testing environment covers screen reader and browser pairings for macOS and Windows, virtual testing, mobile screen readers, and keyboard configuration.
DevTools Accessibility Tree
For developers who aren’t regular screen reader users, browser DevTools offer a practical way to inspect how labels and roles are exposed to assistive technologies. Both Chromium-based browsers (like Edge and Chrome) and Firefox include an Accessibility Tree view that mirrors what screen readers perceive.
This tree shows the semantic structure of your page - including roles, names, states, and relationships - allowing you to verify whether interactive elements are properly labeled and accessible.
Inspecting accessibility like a pro: Both Edge (Chromium) and Firefox offer built-in tools to explore the accessibility tree. Just open DevTools and follow the arrow to find the menu - it’s easier than you think.
How to access the Accessibility Tree
Edge / Chrome:
- Open DevTools (
F12orCtrl+Shift+I) - Open DevTools settings through the 3-dot menu
- Go to the experiments tab and activate the Enable full accessibility tree view in Element panel option
- Go to the Elements tab
- Click the floating Accessibility button in the top right of the pane
Firefox:
- Open DevTools (
F12orCtrl+Shift+I) - Go to the Accessibility tab directly
- Navigate the tree or select elements to inspect roles, names, and states
The screenshot above compares both views using a demo from this CodePen, showing how a checkbox labeled “Read” is exposed in the accessibility tree. You can see its role, name, and state - all critical for screen reader compatibility.
Voice Navigation
Screen readers aren’t the only way to validate whether labels are meaningful and usable. Voice navigation tools let you interact with a page the way users relying on speech commands would - asking the system to “click,” “open,” or “select” elements by name. This is a powerful way to check if your labels are both present and practical in real-world use.
Why it matters
- If a button or link can’t be activated by its label, it’s a sign the label isn’t descriptive enough.
- Voice navigation highlights issues that automated checks often miss, such as ambiguous or duplicated labels.
- It helps ensure that your interface works for users who rely on voice control for accessibility or convenience.
How to test with voice navigation
Desktop
Windows (Voice Access)
- Enable Voice Access in Accessibility settings.
- Use commands like “Click Read” or “Open Settings” to test if elements respond correctly.
macOS (Voice Control)
- Turn on Voice Control in System Settings (or System Preferences in older versions) → Accessibility.
- Try commands such as “Click Log In” or “Select checkbox”.
Mobile
Android (Voice Access)
- Go to Settings → Accessibility and enable Voice Access (you may need to install it from the Play Store first).
- Tap Open in the Voice Access notification to start a session — numbered overlays will appear on interactive elements.
- Try commands like “Tap Read” or “Scroll down” to verify that elements are reachable by their label.
Tip
Android also shows interactive element numbers on screen during a Voice Access session. If an element only gets a number but no spoken label, it is a strong signal the accessible name is missing or unclear.
iOS (Voice Control)
- Go to Settings → Accessibility → Voice Control and toggle it on.
- Try commands like “Tap Log In” or “Tap checkbox” to verify that elements respond to their visible or programmatic label.
Voice Navigation as a Developer Tool
Voice navigation isn’t just for end users with accessibility needs. Developers themselves may benefit from it at some point in their careers. For example, those experiencing hand mobility issues such as carpal tunnel syndrome can use voice commands as an alternative input method.
Building with accessibility in mind ensures that these options are available when you or your users need them most.
Wrapping Up
Properly associating labels with interactive elements isn’t just a screen reader concern. As this article shows, labels are the backbone of voice navigation, the anchor for DevTools inspection, and a key signal for any assistive technology or automated agent, whether it’s a switch device, a browser extension, an AI assistant filling out a form on your behalf, or a future input method we haven’t seen yet.
When a label is clear and correctly linked, everyone benefits: screen reader users hear the right name, voice control users can activate elements by speaking them, and sighted keyboard users get a larger click target for free.
You have more testing tools at your disposal than you might think. Use whichever fits your workflow — open the accessibility tree, try a voice command, or both. The important thing is to make label validation a deliberate step, not an afterthought.