Business and software teams are often overwhelmed at the mention of accessibility. The assumption is clear: accessibility adds an exponential amount of complexity to already challenging projects that everyone is struggling to control the scope for. This assumption is wrong.
When considered from the outset, accessibility becomes a natural part of the software development process that doesn’t require additional resources. Sticking to best practices and HTML standards can fix many issues.
The Data: What 1 Million Websites Reveal
The 2025 WebAIM Million report analyzed the top 1,000,000 homepages across the web. It found that 94.8% of these homepages had WCAG 2 errors. The average number of errors per homepage is 50.
This sounds like an insurmountable problem, but the data actually demonstrates how an incredible amount of accessibility problems stem from surprisingly simple oversights. It also found that 96% of these errors fall into 6 simple categories:
1. Low Contrast Text
2. Missing Alt Text on Images
3. Missing Form Labels
4. Empty Links
5. Empty Buttons
6. Missing Language Declaration
Did you catch that? 6 basic errors cause the vast majority of accessibility errors!
In addition, the following were found to be extremely common HTML errors by WebAIM:
- Incorrect use of HTML headings – found in roughly half of the homepages)
- Non-descriptive links -“Click Here”, “More”, “Continue”, etc.
- Missing Skip Links – to allow users of screen readers and keyboards to skip past the header and main navigation on each page to reach the main content
No Quick Fixes, Including ARIA
Today, when teams need to make something accessible, their first reaction is often to layer on ARIA attributes. While ARIA attributes are provided to improve accessibility, relying on them first is often a misguided approach that is not accessible-first.
When ARIA is used as a quick fix after the fact, it only adds complexity that makes accessibility feel risky and expensive. This band-aid approach reinforces beliefs that accessibility is a burden rather than a fundamental part of good development.
The WebAIM data found that homepages using ARIA had more than twice as many errors than pages without ARIA. The more ARIA is used, the more errors are to be expected.
This isn’t because ARIA is bad; it’s because it’s not being used as it was intended. When you start with semantic HTML, ARIA becomes the specialized tool it is intended to be, and not a replacement for accessible design and code. Accessibility built on semantic HTML principles is neither complex nor costly – it’s simply good code.
Building Accessibility into the Foundation
The WebAIM Million data demonstrates that accessibility doesn’t require complex or expensive changes to your workflow. When teams approach accessibility as an afterthought requiring specialized tools and workarounds, it becomes exactly that—complex and expensive. But when semantic HTML and inclusive design principles are built into the foundation from day one, accessibility becomes invisible infrastructure that benefits everyone.
Start with the basics: semantic HTML, sufficient contrast, descriptive labels. These aren’t accessibility features—they’re simply good web development. Your users, your team, and your bottom line will all benefit from getting the fundamentals right from the start.
These small changes will have an outsized impact. When 96% of accessibility errors stem from basic HTML and design oversights, getting the fundamentals right isn’t just good accessibility—it’s good business.