Firefox's Accessibility panel in DevTools is one of the best tools for auditing and debugging ARIA implementation. Here's a practical guide to accessible web development with Firefox.
The Accessibility Panel
DevTools → Accessibility tab (may need to enable in the … menu → toggle Accessibility)
When enabled, the Accessibility panel shows the accessibility tree — how screen readers and assistive technology interpret your page.
The accessibility tree is different from the DOM:
- Decorative elements (empty divs,
aria-hidden="true"elements) are excluded - Semantic structure is shown with roles, names, and states
- ARIA overrides are applied
Navigating the Accessibility Tree
The accessibility tree sidebar maps to DOM nodes:
- Select any DOM node in the Inspector → see its accessibility properties in the Accessibility panel
- Click in the accessibility tree → highlights the corresponding DOM element
Key properties shown:
-
Role: What type of element this is (
button,link,heading,list,combobox, etc.) - Name: The accessible name — what a screen reader announces
- Description: Additional description text
-
States: Current states (
focused,expanded,checked,invalid,required) - Value: Current value for form elements
Finding Accessible Name Issues
The accessible name is what gets announced. Common problems:
Button without a name:
<button><svg>...</svg></button>
The SVG has no text. Screen reader announces "button" with no context.
Fix: Add aria-label or a visually hidden span:
<button aria-label="Close dialog">
<svg>...</svg>
</button>
In Firefox Accessibility panel, the button shows Name: "Close dialog" after the fix.
Image without alt text:
<img src="chart.png">
In the Accessibility panel, no Name is shown. Screen readers announce the filename.
Fix: <img src="chart.png" alt="Revenue chart showing 20% growth Q3-Q4">
Or for decorative images: alt="" marks it as decorative, excluded from accessibility tree.
Contrast Ratio Checker
In the Accessibility panel → Properties section → Contrast Ratio for text elements.
Firefox calculates the ratio between text color and background color and shows:
- The ratio (e.g., 4.8:1)
- WCAG AA pass/fail (4.5:1 minimum for normal text, 3:1 for large text)
- WCAG AAA pass/fail (7:1 minimum)
For testing dynamically: Click the "Color" swatch next to any element in the Inspector to open the color picker, which shows real-time contrast ratios as you adjust colors.
Checking for Accessibility Issues
DevTools → Accessibility → "Check for Issues" button.
Runs an automated audit and shows a list of issues:
- No keyboard focus order
- Missing ARIA labels
- Low contrast
- Missing landmark regions
- Form inputs without labels
This doesn't replace manual testing but catches structural issues.
Keyboard Navigation Testing
Without a screen reader:
- Close DevTools
- Press Tab to start keyboard navigation
- Verify each interactive element (links, buttons, forms) is reachable
- Verify focus is visible (your focus ring CSS)
- Verify logical tab order
Firefox's Accessibility panel shows focused state when you tab to elements — you can watch the tree as you navigate.
Testing keyboard traps: If Tab stops going anywhere useful (modal dialogs should trap focus, but general pages shouldn't), that's a bug.
ARIA Roles: Common Mistakes
Using wrong roles
<!-- Bad: div with button role, not keyboard accessible -->
<div role="button" onclick="doSomething()">Click me</div>
<!-- Good: semantic button element (keyboard accessible natively) -->
<button onclick="doSomething()">Click me</button>
In the Accessibility panel, both show role: button, but the <div> version won't respond to Enter key by default without additional JavaScript.
Redundant ARIA
<!-- Bad: aria-label overrides the visible text -->
<button aria-label="Submit">Submit Form</button>
<!-- Screen reader announces "Submit", not "Submit Form" -->
<!-- Better: use aria-label only when adding information -->
<button aria-label="Submit contact form">Submit</button>
aria-hidden misuse
<!-- Problem: hidden element but still interactive -->
<button aria-hidden="true">Close</button>
aria-hidden="true" removes from accessibility tree but doesn't prevent keyboard focus. Screen reader users can tab to it but can't understand what it is.
Fix: also add tabindex="-1" to prevent focus, or better — actually hide the element.
Live Regions
Dynamic content updates (notifications, loading states) need aria-live to be announced:
<div role="status" aria-live="polite" id="notification">
<!-- Content inserted here is announced to screen readers -->
</div>
document.getElementById('notification').textContent = 'Your changes have been saved.';
Test in Firefox: enable a screen reader (Orca on Linux, NVDA on Windows) → trigger the update → hear the announcement.
Landmark Regions
Screen reader users navigate by landmarks (skipping to main content, navigation, etc.):
<header>Navigation and logo</header> <!-- landmark: banner -->
<nav>Main navigation</nav> <!-- landmark: navigation -->
<main>Page content</main> <!-- landmark: main -->
<aside>Sidebar</aside> <!-- landmark: complementary -->
<footer>Footer info</footer> <!-- landmark: contentinfo -->
Firefox Accessibility panel shows each landmark. The "Check for Issues" tool flags pages without a main landmark.
Testing with Actual Screen Readers
Firefox works well with:
- Orca (Linux): Built into GNOME, works with Firefox natively
- NVDA (Windows): Free, widely used, excellent Firefox support
- JAWS (Windows): Commercial, industry standard
To test with Orca:
# Start Orca with Firefox
orca --no-registry & firefox
Navigate with keyboard only. Orca announces what you interact with.
For quick testing without installing Orca: Firefox's Accessibility panel with "Check for Issues" catches many structural problems before you need full screen reader testing.
The Accessible Development Workflow
- Build: use semantic HTML first (headings, buttons, forms, lists)
- Check: Accessibility panel → Check for Issues during development
- Test: Keyboard navigation testing (Tab + Enter + Space)
- Verify: Contrast ratio checker for text
- Audit: Screen reader test for critical user flows before release
Firefox's accessibility tools make the first three steps fast enough to do on every significant change, not just before shipping.
Top comments (0)