WCAG 2.2 in Practice: The Top Accessibility Mistakes Agencies Still Make
The web was supposed to be the great equalizer. But even today, as WCAG 2.2 becomes the new standard, many digital agencies continue to launch inaccessible websites—often with glossy interfaces and modern designs that silently shut out millions of users.
“If your design excludes people, it’s not good design. It’s just incomplete.”
This article explores the most common accessibility mistakes that agencies still ship in their projects, despite WCAG 2.2 being in place. We’ll look at real-world failures, why they happen, and how to fix them—for the sake of usability, compliance, and most importantly, human dignity.
What Is WCAG 2.2 and Why It Matters
WCAG stands for Web Content Accessibility Guidelines, and version 2.2 builds on WCAG 2.1 by adding new success criteria aimed at improving the web experience for people with cognitive impairments, mobility limitations, and low vision.
- WCAG 2.2 helps ensure keyboard navigation, screen reader compatibility, and mobile accessibility.
- Non-compliance can lead to lawsuits, brand damage, and lost users.
Top Accessibility Mistakes Agencies Still Make
1. Ignoring Focus Visibility (WCAG 2.4.11)
Many designers remove or obscure keyboard focus outlines for aesthetic reasons. But people who rely on keyboards to navigate can’t use your site without them.
Fix: Ensure every interactive element has a visible, high-contrast focus indicator.
2. Inaccessible Touch Targets (WCAG 2.5.8)
WCAG 2.2 introduces a new criterion: target size must be at least 24×24 pixels. Tiny tap targets are a major barrier for mobile users and people with motor impairments.
Fix: Increase padding around buttons and links.
3. Overusing ARIA – and Using It Wrong
“If you can do it with HTML, don’t use ARIA.”
Many agencies throw ARIA attributes everywhere without understanding them, often breaking screen readers.
Fix: Use semantic HTML first. Only use ARIA when necessary and with proper testing.
4. Lack of Error Identification in Forms
Common form problems include no labels, no error feedback, and using placeholder text instead of visible labels.
Fix: Use <label> elements, clear error messages, and never rely on color alone.
5. Poor Color Contrast and Use of Color Alone
Low contrast text and buttons leave many users—especially those with low vision—completely in the dark.
Fix: Use tools like Contrast Checker to ensure proper contrast ratios (min 4.5:1 for normal text).
6. Missing Accessible Names for Controls
Elements must have accessible names so screen readers can announce them.
Fix: Use aria-label, aria-labelledby, or visible text.
7. No Skip Navigation Link
Without a “Skip to main content” link, users must tab through full menus on every page.
Fix: Add a skip link that’s visually hidden but keyboard-visible.
8. No Testing With Real Assistive Tech
Automated tools only catch 30–40% of problems. Manual testing is critical.
Fix: Test with screen readers, keyboard-only navigation, and mobile tools.
9. Failing New Focus Appearance Requirements
WCAG 2.2 requires better visibility and contrast for focus indicators.
Fix: Ensure focus styles are highly visible and distinguishable.
10. Relying on Accessibility Overlays
“Accessibility isn’t a plugin. It’s a process.”
Overlays promise quick fixes but often interfere with assistive tech and hide deeper issues.
Fix: Build accessibility into your code from the start. Don’t rely on shortcuts.
Why Agencies Keep Shipping Broken Accessibility
- Rushed deadlines → no time for testing
- Lack of training → unaware of WCAG 2.2 updates
- Design over function → aesthetic choices override usability
- Accessibility as “extra” → not part of the core workflow
Who Gets Hurt by These Mistakes?
- A job seeker can’t submit a form due to inaccessible buttons
- A student with dyslexia struggles with poor layout and contrast
- A person with Parkinson’s can’t tap small icons on mobile
How Agencies Can Build Accessible Websites
1. Start with Semantic HTML
Use native elements like <button>, <label>, <nav>, <header>.
2. Design for All Abilities
Include contrast, readability, layout flexibility—not just visual flair.
3. Include Accessibility in QA
Make it a standard part of your testing, not a post-launch patch.
4. Educate Your Team
Train everyone—developers, designers, content creators—on WCAG 2.2.
5. Conduct Real Accessibility Audits
Hire experts or testers with disabilities for genuine feedback.
Quick Accessibility Checklist for Agencies
- ✅ Semantic HTML elements
- ✅ Visible focus indicators
- ✅ Full keyboard navigation
- ✅ Labelled forms and errors
- ✅ Sufficient color contrast
- ✅ Skip navigation links
- ✅ Avoid color-only indicators
- ✅ Alt text for media and controls
- ✅ Screen reader and mobile testing
- ✅ Team-wide WCAG training
Frequently Asked Questions About WCAG 2.2 Failures
1. What is WCAG 2.2?
The latest version of the Web Content Accessibility Guidelines, focused on better inclusivity.
2. What are the new requirements?
Focus appearance, minimum target size, cognitive and mobile support features.
3. Why do agencies fail at accessibility?
Due to time pressure, lack of knowledge, or treating accessibility as optional.
4. Are accessibility overlays good?
No—they can block assistive tech and mislead users about compliance.
5. Biggest WCAG 2.2 failure?
Still lack of proper keyboard focus and navigation.
6. How to check accessibility?
Use tools like Axe/WAVE and manual testing with screen readers/keyboards.
7. Do I need to update from WCAG 2.1?
Yes, to stay compliant and inclusive moving forward.
8. Risks of non-compliance?
Legal penalties, user loss, and brand harm.
9. Who benefits?
Users with disabilities, mobile users, aging populations—everyone.
10. Whose job is accessibility?
Everyone’s—designers, devs, content creators, and managers.