When people hear that a page has 25 accessibility violations, the first reaction is usually:
"Wow... that's a lot of bugs."
Sometimes it is.
But sometimes it isn't.
Recently, while reviewing a public page on NASA.gov, I came across an interesting example.
Instead of finding 25 unrelated issues, I found one implementation pattern repeated 25 times.
That's an important difference.
The finding
On the Recently Published page, automated testing reported 25 link-name violations.
At first glance, it looked like a long list of separate accessibility problems.
After reviewing the page manually, it became clear that every violation originated from the same UI pattern.
The page contains a list of article cards.
Each card includes an image that acts as a link.
Those image links don't have a discernible accessible name.
As a result, every card produces the same accessibility issue.
One pattern...
Instead of fixing:
- Issue #1
- Issue #2
- Issue #3
- ...
...you fix the component once.
Every instance improves automatically.
This is exactly why design systems and shared UI components are so powerful—not only for consistency, but also for accessibility.
Why automated testing is valuable
One criticism I often hear is:
"Automated tools only catch 30–40% of accessibility issues."
That's true.
Automated testing can't evaluate things like:
- whether alt text is meaningful;
- whether keyboard navigation feels logical;
- whether the overall experience makes sense.
But automation is excellent at spotting repeated implementation patterns.
And repeated patterns often have the biggest impact.
One shared component.
Dozens of pages.
Hundreds of users.
One fix.
Shift Left isn't just about finding bugs earlier
People often describe Shift Left like this:
Find accessibility issues during development instead of QA.
I think there's another benefit.
When accessibility is checked early, repeated implementation patterns are discovered before they spread throughout the application.
Finding one issue before a component is reused hundreds of times is far cheaper than fixing every instance after release.
A simple mindset shift
Instead of asking:
"How many accessibility issues do we have?"
Try asking:
"How many unique implementation patterns are responsible for them?"
The answer is often much smaller.
And that's good news.
Final thoughts
Accessibility reports can look overwhelming.
But the number of reported issues doesn't always reflect the amount of work required.
Sometimes one well-designed fix removes dozens—or even hundreds—of violations.
After verifying the findings, I shared them with NASA's accessibility team in case they found them useful. My goal wasn't to perform a formal accessibility audit, but to contribute a real-world observation that might help improve the experience for users.
I believe sharing observations like these is an important part of improving the web.
Open source isn't just about publishing code.
Sometimes it's also about giving something back to the web we all use.
Have you ever found a single fix that eliminated dozens of accessibility issues?
I'd love to hear your experience.
Top comments (0)