Web Accessibility: How to Build Equal-Opportunity Websites
Raghad Eid
April 18, 2024
Updated on:
June 7, 2026
Accessibility has been a design priority since the birth of the web. Sir Tim Berners-Lee, inventor of the World Wide Web, put it clearly: "the power of the web is in its universality. Access by everyone regardless of disability is an essential aspect."
Two decades later, the web is still failing that test. And in 2026, the failure is getting worse, not better.
Vardot's view: the organizations we see succeed at accessibility long-term are not the ones chasing legal compliance. They are the ones treating accessibility as an operating discipline: built into the platform, automated where possible, owned by a clearly defined team, and measured continuously. The legal risk is real. But the deeper problem is that accessibility degrades silently between launches unless governance and tooling are in place to catch it.
What Is Web Accessibility, and Why Does It Matter?
Web accessibility means designing and building websites that can be used by everyone, including people with disabilities, through conformance with the Web Content Accessibility Guidelines (WCAG) 2.2 published by the W3C. The current baseline for most enterprise organizations is WCAG 2.2 Level AA. Three major regulatory frameworks now apply: the European Accessibility Act (EAA), enforced in EU member states since 28 June 2025; the Americans with Disabilities Act, with Title II requiring WCAG 2.1 Level AA for US state and local government sites since April 2024 and Title III driving private-sector litigation; and country-specific laws, including the UK Equality Act and Canada's AODA.
The Current State of Web Accessibility
Statistics on web accessibility are notoriously inconsistent, but the most reliable annual benchmark comes from WebAIM, which has scanned the top one million home pages every year since 2019.
The 2026 WebAIM Million report found 56,114,377 distinct accessibility errors across the one million home pages studied, an average of 56.1 errors per page. That's a 10.1% increase over 2025, reversing a trend of gradual improvement. 95.9% of home pages had detectable WCAG failures, up from 94.8% in 2025.
The regression has a clear cause: page complexity. Home pages now contain an average of 1,437 elements, a 22.5% increase in a single year. ARIA usage has grown sixfold since 2019. Both correlate strongly with accessibility errors. The most likely drivers are heavy reliance on third-party frameworks and the rise of AI-assisted coding practices, which tend to generate visually impressive interfaces without accessibility guardrails built in.
The more encouraging finding: six error categories account for 96% of all detected failures, and they've been the same six for seven consecutive years:
Low contrast text (83.9% of pages).
Missing alt text on images (more than half of the pages).
Missing form input labels (51%).
Empty links.
Empty buttons.
Missing document language.
These are not obscure edge cases. They are the basics. Which means the highest-leverage accessibility work for most organizations is not exotic, it's disciplined execution on fixable problems.
The Global Legal Landscape of Web Accessibility
Web accessibility has transitioned from a best practice to a mandatory legal requirement across major global markets. Most regulations now center on compliance with WCAG 2.1 Level AA standards.
Key Regulatory Frameworks
European Accessibility Act (EAA)
Status: Legally applicable as of 28 June 2025.
Scope: Extensive. Covers private and public sectors, including e-commerce, apps, and digital services.
Impact: Applies to any organization serving EU consumers, making it an urgent priority for global entities (nonprofits, universities, and financial services).
Americans with Disabilities Act (ADA)
Status: A primary driver for private-sector litigation in the US.
Compliance: As of April 2024, the Department of Justice mandates WCAG 2.1 Level AA for state and local government websites under Title II, shifting it from recommended to a federal compliance requirement.
Regional Legislation
UK: Equality Act 2010 and Public Sector Bodies Accessibility Regulations mandate WCAG 2.1 AA for the public sector.
Canada: The Accessibility for Ontarians with Disabilities Act (AODA) requires WCAG 2.0 AA.
Australia: The Disability Discrimination Act references WCAG 2.1 AA.
Future Outlook
The landscape is dynamic; as international standards evolve, most of these frameworks are expected to transition from WCAG 2.1 to WCAG 2.2 compliance in the near future.
Vardot's view: for organizations operating in multiple jurisdictions, targeting WCAG 2.2 Level AA today is the lowest-risk path. It satisfies every current regulatory framework (WCAG 2.2 is backwards compatible with 2.1 and 2.0) and future-proofs your site against the next wave of regulatory updates. Building to WCAG 2.1 AA and retrofitting later costs more.
Why Accessibility Is Hard to Sustain
Building an accessible website is not especially difficult. Any competent agency working on a platform like Drupal can deliver a site that meets current WCAG standards at launch.
Maintaining accessibility over time is the real challenge. Once a site is handed to the client, it lives or dies by the content creators, editors, and teams adding pages to it every week. A single uploaded image without alt text, a heading hierarchy broken by a well-meaning editor, a third-party script added to track a campaign, or a framework update that changes ARIA behavior: any of these can push a compliant site back into failure.
This is why 95.9% of home pages fail WCAG today. The initial build is rarely the problem. Continuous governance is.
Enterprise organizations that sustain accessibility share three practices:
They treat accessibility as an operating capability, not a project. There's a named owner. There's a budget. There's a recurring review cadence.
They instrument continuous monitoring. Automated accessibility scanning runs in CI pipelines for code changes and on rendered content for editorial changes. Manual review happens on a schedule, not only when something breaks.
They train editors and authors. The people who add most of a site's content understand how their choices affect accessibility, and they have tools that flag issues before publication.
Without these three, accessibility regresses. Every time.
Vardot's Approach
Everything we build adheres to WCAG 2.2 Level AA and Authoring Tool Accessibility Guidelines (ATAG) 2.0. Because our work starts on Drupal, we start with an accessibility foundation that most competing platforms cannot match. Drupal has treated accessibility as a core commitment through every major version, with accessibility-supporting modules shipped in core since Drupal 8 and continuing through Drupal 10, Drupal 11, and Drupal CMS 2.0.
When we build, we consider a wide range of assistive technologies: screen readers, Braille devices, alternative and on-screen keyboards, word prediction tools, and voice recognition. We implement the Accessible Rich Internet Applications (WAI-ARIA) suite for dynamic content and advanced UI components, where the 2026 WebAIM data confirms most teams are getting it wrong.
Accessibility testing runs at multiple stages of every project: automated scanning integrated into development, manual testing by humans, and assistive-technology validation before launch. Automated testing alone isn't enough. It catches measurable issues but misses the ones that only show up when someone actually tries to use the site. That's why manual testing remains essential.
Vardot's view: automated accessibility tooling has genuinely improved in the last two years, particularly with AI-assisted scanners that can flag context issues static rules miss. But no tool replaces testing with the assistive technologies your users actually use. The organizations we see fail accessibility most often are the ones that treat a green automated scan as the finish line.
What Content Editors Own
Technical architecture sets the ceiling for accessibility. Content editors set the floor. The six most common accessibility failures in the WebAIM Million report are all editorial decisions, not development decisions.
Alt text on every image
Missing alt text affects more than half of all home pages. Write alt text that describes the image in context, not generic labels. "Photo" is not alt text. "Students walking across campus during orientation week" is.
Correct heading hierarchy
Headings create the structural map that screen reader users rely on to navigate a page. Don't skip levels (H1 to H3 with no H2) and don't use headings for visual styling when they don't represent document structure.
Semantic HTML
Use the right element for the job. Buttons are buttons, links are links, lists are lists. The semantic structure of the page is what assistive technology reads; it is not optional styling.
Captioning and audio descriptions for video
Auto-generated captions are a starting point, not a finish line. Review them for accuracy, especially for proper nouns, technical terms, and non-English content. Provide audio descriptions for videos where visual content carries meaning beyond the spoken track.
Plain language and descriptive link text
"Click here" and "read more" fail accessibility because they carry no meaning out of context. Use link text that describes the destination: "read our 2025 impact report" rather than "read more here." For cognitive accessibility, write at a reading level appropriate to your audience and use dyslexia-friendly sans serif typefaces where possible.
Tools and the Drupal Accessibility Ecosystem
A disciplined accessibility practice depends on tooling that runs continuously, not just at audit time.
Editoria11y
An open-source Drupal module that runs automated accessibility checks on rendered content directly in the editorial interface. It catches the editorial-side issues that cause most accessibility regressions: missing alt text, poor heading structure, contrast problems in inline styles, and uninformative link text. For most Drupal sites, Editoria11y is the single most cost-effective accessibility investment.
Drupal core accessibility modules
Ship with the platform and handle the foundational layer: ARIA output, keyboard navigation, focus management, and semantic markup.
Continuous monitoring platforms
Siteimprove, CivicPlus Monsido, Accessibility Checker, axe DevTools, and others provide ongoing scanning across large sites and track accessibility scores over time. These matter most for organizations managing hundreds or thousands of pages where manual review cannot scale.
Varbase and AI-Powered Accessibility
Varbase, Vardot's enterprise distribution built on Drupal CMS 2.0, ships with accessibility configurations pre-set. The default Gin admin theme is WCAG-compliant, Drupal core accessibility modules are enabled out of the box, and editorial workflows are designed to flag accessibility issues before content publishes.
Varbase AI adds an AI capability layer that directly targets the most common accessibility failures at scale:
Automatic alt text generation produces context-aware alt text on image upload, with bulk update capability for existing media libraries. Given that missing alt text affects more than half of all home pages, this is the highest-leverage automation available.
AI-powered taxonomy tagging improves content structure and discoverability, which benefits assistive technology users who rely on structured navigation.
CKEditor 5 AI assistant supports editors writing clearer, more readable content, aligned with WCAG's plain-language and cognitive accessibility criteria.
Vardot's view: AI is both an opportunity and a risk for accessibility. The WebAIM 2026 data shows AI-assisted coding is correlated with rising accessibility errors when used without accessibility guardrails. The answer is not to avoid AI but to use it inside a platform that treats accessibility as a default: generated content should pass accessibility checks before it publishes, not after a user files a complaint.
Make Accessibility a Capability, Not a Compliance Project
Web accessibility is everyone's work: developers, designers, editors, marketers, and leaders setting priorities. It's a non-negotiable for enterprise organizations operating under EAA, ADA, or any of the expanding roster of national frameworks. And the WebAIM 2026 data is a warning that without sustained discipline, the web is getting less accessible, not more.
The organizations that get this right are not the ones that bought the most accessible CMS or ran the most thorough audit. They are the ones that built governance, training, and monitoring into how their organization operates every day.
Ready for an accessibility audit against WCAG 2.2 AA?
WCAG 2.2 adds nine new success criteria to WCAG 2.1, focused primarily on cognitive accessibility, mobile accessibility, and users with low vision. WCAG 2.2 is backwards compatible, so content meeting 2.2 also meets 2.1 and 2.0. For organizations operating across multiple jurisdictions, targeting WCAG 2.2 Level AA is the lowest-risk path because it satisfies every current regulatory framework and future-proofs against upcoming updates to standards like EN 301 549.
The European Accessibility Act (EAA) became legally applicable on 28 June 2025 and applies to websites, mobile apps, e-books, e-commerce platforms, and a broad range of digital products and services offered to consumers in EU member states. It applies to private-sector organizations as well as public sector. Critically, it also applies to organizations based outside the EU if they serve EU consumers. A US-based nonprofit running a fundraising campaign in Germany or a university recruiting students from France falls under EAA scope.
Accessibility testing should run continuously, not annually. Automated accessibility scans should run in your development pipeline on every code change and on rendered content for editorial changes through tools like Editoria11y. Manual testing with assistive technologies should run at least twice a year on enterprise sites and before every major release. A full third-party accessibility audit is worth running annually or before major launches. Organizations that only test at audit time consistently regress between audits.
Drupal has treated accessibility as a core commitment since Drupal 8, with accessibility modules shipped in core and accessibility-supporting patterns built into the platform's default behavior. Competing platforms typically require extensive configuration or third-party plugins to reach the same baseline.
Both, depending on how it's used. AI-powered tools can automate the highest-volume accessibility work: generating alt text for images, flagging readability issues, catching contrast problems, and suggesting link text improvements. Varbase AI's automatic alt text generation directly addresses one of the most common accessibility failures at scale.
