DEV Community

Sachin Maurya
Sachin Maurya

Posted on

Accessibility Audits (STQC, Axe, and Beyond)

🧠 “Performance is how fast your site feels; accessibility is how many people can use it.”

👨‍🔬 Why Accessibility (A11y) Audits Matter

Accessibility isn't just about screen readers and color contrast—it’s a legal and ethical obligation. Government and enterprise projects often undergo formal audits (like STQC or Sugamya Bharat) that test your UI across:

  • WCAG 2.1 guidelines
  • Screen readers (JAWS, NVDA)
  • Keyboard navigation
  • Semantic markup
  • Color contrast ratios
  • Assistive tech compatibility

As a frontend developer, it becomes your job to fix every issue flagged in those reports — often with minimal documentation and strict deadlines.

🛠️ How to Run a Developer-Focused Audit

Here's how I usually start accessibility debugging:

✅ Tools I Use:

  • Axe DevTools (Browser Extension)
    Great for basic checks like ARIA roles, color contrast, and semantic structure.

  • WAVE Tool
    Simple to validate alt text, labels, and heading structures.

  • Lighthouse Accessibility Audit
    Gives a quick score and pinpoints violations like missing labels.

  • Manual Testing

    • Tab through the site for keyboard navigation
    • Use screen readers to navigate forms, modals, buttons
    • Verify focus states visually

🧩 Common Accessibility Issues & Fixes

Here’s a breakdown of some frequent errors from audits I’ve fixed on real-world React/Next.js projects:

1. Missing Form Labels

Issue: Input fields without <label> or aria-label

Fix:

<label htmlFor="email">Email</label>
<input id="email" name="email" type="email" />
Enter fullscreen mode Exit fullscreen mode

2. Improper Heading Structure

Issue: Skipping heading levels or using <div>s instead of semantic tags.

Fix:

<h1>Main Title</h1>
<h2>Section</h2>
<h3>Subsection</h3>
Enter fullscreen mode Exit fullscreen mode

3. Non-Accessible Modals

Issue: Modals that trap focus or aren’t announced by screen readers.

Fix: Use a library like @reach/dialog or ensure the following:

  • aria-modal="true"
  • Focus is trapped inside modal
  • Escape key closes it
  • role="dialog" or alertdialog

4. Buttons Without Accessible Text

Issue: Icon buttons without text or aria-label

Fix:

<button aria-label="Close">
  <CloseIcon />
</button>
Enter fullscreen mode Exit fullscreen mode

5. No Keyboard Navigation

Issue: Interactive elements not reachable by Tab

Fix:

  • Use native elements (<button>, <a>)
  • For custom components, ensure tabIndex="0" and handle onKeyDown

📈 My Checklist Before Any Accessibility Audit Submission

✅ Use semantic HTML (<main>, <nav>, <header>, <footer>)
✅ All form fields have associated labels
✅ Headings follow a logical structure
✅ Color contrast passes WCAG AA
✅ Keyboard navigation is smooth
✅ Screen readers announce dynamic content
✅ Error messages are accessible
✅ aria-live used for real-time status updates
✅ Modals trap focus
✅ Custom dropdowns & tabs are navigable via keyboard

🧠 Final Thoughts

Accessibility work may not always be visible in the UI — but it makes your app usable for everyone.

Whether it's a government audit or your own product, passing these standards builds credibility and opens your app to a wider audience.

It's not extra work — it’s inclusive design.

Top comments (0)