Web accessibility is the practice of building websites and applications that everyone can use, including people with visual, auditory, motor, or cognitive disabilities. Accessibility is not just a nice-to-have — it is a legal requirement in many jurisdictions and a fundamental aspect of quality web development.
An accessibility audit identifies barriers that prevent people from using your site effectively. Starting with automated auditing tools is the fastest way to catch the most common issues, though manual testing and testing with real assistive technologies is also essential.
The Four Principles of Accessibility (POUR)
The Web Content Accessibility Guidelines (WCAG) organize accessibility requirements around four principles:
Perceivable — Information must be presentable to users in ways they can perceive. Images must have alt text. Videos must have captions. Content must have sufficient color contrast.
Operable — Users must be able to operate the interface. Every interactive element must be keyboard accessible. There must be enough time to complete tasks. Content must not flash in ways that could cause seizures.
Understandable — Information and operation must be understandable. Language must be declared in HTML. Error messages must explain what went wrong. Navigation must be consistent.
Robust — Content must be robust enough to be interpreted by a wide range of assistive technologies. This means using semantic HTML and ARIA correctly.
Common Accessibility Issues
Missing or poor alt text
Every informative image must have a descriptive alt attribute. Decorative images should have alt="" so screen readers skip them.
<!-- Bad --> <img src="user-avatar.jpg"> <img src="decorative-divider.svg" alt="decorative divider"> <!-- Good --> <img src="user-avatar.jpg" alt="Profile photo of Alice Smith"> <img src="decorative-divider.svg" alt="">
Insufficient color contrast
Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text — 18px+ or 14px+ bold). Many designs fail this on light grey text on white backgrounds.
Missing form labels
Every <input>, <select>, and <textarea> must have an associated <label> (or aria-label / aria-labelledby):
<!-- Bad --> <input type="email" placeholder="Enter email"> <!-- Good --> <label for="email">Email address</label> <input type="email" id="email" placeholder="alice@example.com">
Keyboard trap
Users who navigate by keyboard (Tab, Shift+Tab, arrow keys, Enter, Space) must be able to move freely through the page. Modal dialogs must trap focus inside while open, and return focus to the trigger when closed.
Missing focus indicator
Browsers provide a default focus ring, but many designs remove it with outline: none or outline: 0. Remove this only if you provide an equally visible custom focus indicator.
/* Bad */
:focus { outline: none; }
/* Good — custom focus indicator */
:focus-visible { outline: 2px solid #6366f1; outline-offset: 2px; }Wrong heading structure
Screen reader users navigate pages using headings. Heading levels must be sequential — do not skip from H1 to H3. There should be exactly one <h1> per page.
Interactive elements not using semantic HTML
Buttons should be <button>. Links that navigate should be <a href="...">. Using <div> or <span> as interactive elements requires ARIA and keyboard event handling that is easy to get wrong.
ARIA Roles Reference
ARIA (Accessible Rich Internet Applications) provides attributes that enhance HTML semantics for assistive technologies.
| Role / Attribute | Use |
|-----------------|-----|
| role="button" | Custom interactive element that acts as a button |
| role="dialog" | Modal or popup dialog |
| aria-label | Provides an accessible name when visible text is absent |
| aria-labelledby | Points to an element that labels this one |
| aria-describedby | Points to an element that describes this one |
| aria-expanded | Whether a collapsible element is open or closed |
| aria-hidden="true" | Hides element from screen readers |
| aria-live="polite" | Region that announces updates to screen readers |
| aria-required="true" | Marks a form field as required |
| aria-invalid="true" | Marks a form field as having an error |
Using the DevHexLab Accessibility Audit Snippet Generator
Enter a URL or paste HTML. The tool generates runnable JavaScript snippets that you can paste into your browser console to audit specific aspects:
- Alt text checker — lists all images missing or with empty alt text
- Heading structure — prints the heading hierarchy of the page
- Focus order — highlights all focusable elements in tab order
- ARIA audit — checks for invalid ARIA role/attribute combinations
- Color contrast — reports elements with insufficient contrast ratios
- Form label checker — finds inputs without associated labels
Run these snippets in your browser's DevTools console on any page.
Testing with Real Assistive Technologies
Automated tools catch approximately 30-40% of accessibility issues. Manual testing is essential:
- Screen readers — NVDA + Firefox (free, Windows), VoiceOver (built into macOS and iOS), TalkBack (Android)
- Keyboard-only navigation — Tab through your entire page. Can you reach and operate every feature?
- Browser zoom — Test at 200% and 400% zoom. Does content reflow correctly?
Conclusion
Accessibility auditing does not need to be overwhelming. Start with automated tools to catch the obvious issues — missing alt text, low contrast, missing labels — and layer in manual testing. The DevHexLab Accessibility Audit Snippet Generator gives you browser-runnable snippets to quickly check the most important accessibility properties on any page.