Skip to content
Mutual Team

Common Accessibility Problems to Avoid

Accessibility Web Development

Note: This article was last updated on January 2, 2020 and may contain outdated information.

This blog post explores web accessibility best practices, drawing from the author’s experience improving their accessibility knowledge throughout 2020. The article identifies common pitfalls and practical solutions for building more inclusive websites.

Testing Tools and Methods

The author recommends two primary tools:

  1. Google Lighthouse - “an auditing tool” that offers basic accessibility testing alongside performance metrics
  2. Microsoft Accessibility Insights Extension - provides both fast-pass scanning and detailed assessment checklists organized by category (keyboard navigation, focus management, landmarks, etc.)

Why Automated Tests Aren’t Enough

A critical finding: passing automated audits doesn’t guarantee accessibility. The author discovered keyboard-navigation issues with slider images that Lighthouse missed—elements weren’t properly wrapped in interactive tags, and the slider’s aria-hidden="true" attribute violated focus requirements.

Manual Testing Matters Most

First-hand testing using keyboard-only navigation revealed issues automated tools overlooked. Key questions to ask:

  • “Is the page fully functional without a mouse?”
  • “Is focused element visibility obvious?”
  • “Does keyboard navigation flow logically?”

Essential Practices

Never Remove Focus Styles - Removing :focus outlines eliminates keyboard navigation visibility. Modify outline styling instead if necessary.

Trap Focus in Modals - When dialogs open, focus should stay within them. The author recommends David Clark’s Focus Trap library.

Clarify Link Context - Generic link text like “click here” confuses screen readers. Using aria-label or rewording improves accessibility.

Leverage ARIA Semantics - Employ aria-label, aria-labelledby, and role attributes to help screen readers understand page structure.

Conclusion

Effective accessibility requires combining automated testing with hands-on keyboard and screen reader testing—audits alone provide insufficient verification of true accessibility.

Recent Posts