Why Your Website Fails WCAG: 6 Myths That Break UI/UX

95.9% of home pages fail WCAG 2. And it's not because the designers are lazy. It's because they're repeating myths that sound reasonable but wreck the user experience. (WebAIM Million)

That number comes from the WebAIM Million study of the top 1,000,000 home pages. Nearly all of them have at least one detected accessibility error. The most common? Low-contrast text, present on 83.9% of pages. Missing alt text, missing form labels, empty links, empty buttons, missing document language—these six issues account for 96% of all errors. (WebAIM Million)

You can fix most of these in a weekend. But first, you have to stop believing the myths that got you here.

Accessibility is just for disabled people

That's like saying seatbelts are just for people who crash. Accessibility helps everyone. The ADA Title II rule now requires state and local governments to meet WCAG 2.1 AA by April 24, 2026, or 2027 for smaller entities. (Federal Register) But beyond legal compliance, think about your users. One in 12 men has color vision deficiency. (NEI) That's a huge chunk of your audience—and they're not “disabled.”

Also, accessibility overlaps with good UX. Clear labels, logical structure, readable text—those benefit every user. The user who's tired, the one on a slow connection, the one with a broken arm. It's not a niche; it's the human condition.

I can just use color to show status

No. Red for error, green for success—that's a classic, and it's a classic failure. If you rely on color alone, you're failing users with color blindness. WCAG 2.1 requires that color is not the only visual means of conveying information. (WCAG 2.1) Pair color with text, icons, or patterns. A red border plus “Required” text is fine. A red border alone is not.

This also applies to links. If your links are just a different shade of gray, users can't tell. Add an underline or an icon. Simple fix, big impact.

I don't need to worry about keyboard users

Think about it: power users often prefer keyboard navigation. And WCAG 2.1 Level A requires all functionality to be operable via keyboard. (WCAG 2.1) That means every button, link, and form field must be reachable and usable without a mouse.

And when you navigate by keyboard, you need to see where you are. A visible focus indicator is required at Level AA. (WCAG 2.1) Not just a faint outline—something clear. And it shouldn't get hidden by sticky headers or modals. WCAG 2.2 adds that the focus indicator can't be entirely obscured. (WCAG 2.2) Test it: tab through your site. If you lose focus, you've got a problem.

Touch targets just need to be big enough to tap

How big is “big enough”? WCAG 2.2 requires a minimum of 24 by 24 CSS pixels. (WCAG 2.2) But that's the bare minimum. Apple recommends 44 by 44 points. (Apple) Android says 48 by 48 dp. (Android) Those are the sizes that feel comfortable for thumbs.

But size isn't everything. Spacing matters too. If two 24-pixel buttons are crammed together, you'll miss taps. Give them breathing room. A good rule: at least 8 pixels between targets. That's not in the guidelines, but it's common sense.

Responsive design is just about resizing

Resizing is part of it, but true responsive design is about adapting the layout. Fluid grids, flexible images, media queries—that's the toolkit. (MDN) And you should build mobile-first, starting with the smallest screen and adding breakpoints when the content demands it. (MDN) Don't target specific devices; target the content.

But there's a deeper issue: reflow. WCAG 2.1 Reflow requires that content be usable at 320 CSS pixels wide without scrolling in two directions. (WCAG 2.1) That's roughly a 1280x1024 screen at 400% zoom. (WCAG 2.1) So your layout has to collapse to a single column, and tables have to transform. If you're just scaling down, you're not doing it right.

Performance is a technical issue, not a UX issue

Performance is UX. If your page takes over 2.5 seconds to load, you're losing users. Google's Core Web Vitals measure LCP, INP, and CLS. (web.dev) LCP should be 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less. (web.dev) These aren't just metrics; they're how users feel about your site.

And it's not just about speed. Perceived responsiveness: 0.1 second feels instant, 1 second keeps the flow, 10 seconds loses attention. (Nielsen Norman Group) So every delay matters. Optimize images, use lazy loading, set width and height to avoid layout shifts. (MDN) That's not just tech; that's caring about your users.

What I'd actually do

Stop chasing trends. Start with the fundamentals. Run an automated audit—the WebAIM Million would be a good starting point. Fix the low-contrast text, add alt text, label your forms, make your links and buttons accessible. That will knock out most of your errors.

Then, test with real users. Not just screen reader users—though definitely include them—but also keyboard-only users, and people with color blindness. You'll be surprised what you find.

Finally, build accessibility into your process from the start. It's easier to design an accessible button from the beginning than to retrofit one. And it's not just about compliance; it's about respect. Respect for your users, and respect for your craft.

Sources

• WebAIM Million - https://webaim.org/projects/million/
• WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
• W3C WCAG 2.2 Understanding Target Size (Minimum) - https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• Apple Human Interface Guidelines - https://developer.apple.com/design/human-interface-guidelines/accessibility
• Android Developers (accessibility) - https://developer.android.com/guide/topics/ui/accessibility/apps
• web.dev (Web Vitals) - https://web.dev/articles/vitals