Web Accessibility: A Plain Guide to WCAG, Testing and Compliance Dates

Web accessibility means building websites, documents and tools so people with disabilities can use them. In the W3C’s words, people should be able to "perceive, understand, navigate, and interact with the Web," and also contribute to it. The shared yardstick for that work is WCAG, the Web Content Accessibility Guidelines, and the current version is WCAG 2.2.

This guide is for agencies and site owners serving nonprofits, associations, colleges and public agencies. It covers who web accessibility helps, how WCAG 2.2 works, what "AA" means in a contract, WCAG 3, the main US and EU dates, testing, common failures, PDFs, and WordPress and Drupal. It links to our deeper posts along the way.

The short version: build and test to WCAG 2.2 Level AA, which covers the WCAG criteria the main US rules name. Scanners find part of the problems, never all, so every audit needs a person with a keyboard and a screen reader. The most common failures are old and fixable: low contrast, missing alt text, unlabeled fields and empty links. Dates change, so they sit in one dated section.

What web accessibility means, and who it helps

The W3C’s introduction to web accessibility says it covers "all disabilities that affect access to the Web." It lists six groups: auditory, cognitive, neurological, physical, speech and visual.

In practice, that means:

• A blind member uses a screen reader that reads the page aloud, so images need text alternatives and links need clear names.
• A donor with a tremor uses a keyboard instead of a mouse, so every button must work from the keyboard.
• A deaf student watches a recorded lecture, so the video needs captions.
• A volunteer with a cognitive disability fills out a long form, so labels and error messages need to be clear.

The same work helps people without a disability. The W3C names older people with changing abilities, people with a temporary injury such as a broken arm, people reading a phone in bright sunlight, and people on slow or costly connections.

For our readers, that list describes the audience. Public agencies serve everyone. Colleges enroll students who use assistive technology every day. Web accessibility is part of whether the site does its job for the people it exists to serve.

How WCAG 2.2 is organized: four principles, three levels

WCAG 2.2 is a W3C Recommendation. It was first published on October 5, 2023, and the current version is dated December 12, 2024. It is also an ISO standard, ISO/IEC 40500:2025, according to the W3C’s WCAG overview.

The structure has three layers.

Four principles. Content must be perceivable, operable, understandable and robust, often shortened to POUR. People must be able to sense it, use it and understand it, and it must work with assistive technology.

Thirteen guidelines. These sit under the principles. One example is "Keyboard Accessible."

Success criteria. These are the testable rules, each numbered and assigned a level: A, AA or AAA.

The W3C’s conformance guidance defines the levels plainly. Level A is the minimum. Level AA means a page meets every A and AA criterion. Level AAA means it meets all three sets.

The W3C says "It is not recommended that Level AAA conformance be required as a general policy for entire sites," because some content cannot meet every AAA criterion. Individual AAA criteria can still be used where they help.

WCAG 2.2 is backwards compatible. Content that conforms to 2.2 also conforms to 2.1 and 2.0, and the W3C says it "encourages you to use the latest version of WCAG."

The nine new success criteria in WCAG 2.2

WCAG 2.2 added nine success criteria to WCAG 2.1 and removed one, 4.1.1 Parsing, which the W3C now lists as obsolete. The W3C’s What’s New in WCAG 2.2 page explains each one.

Six of the nine count toward a 2.2 AA target. On membership and donation sites, three deserve early attention.

Accessible Authentication. The Understanding page names password manager support and copy and paste as acceptable ways to meet it. Blocking paste in a password field, or blocking autofill, fails it unless another method is offered.

Redundant Entry. Multi-step renewal and registration forms often ask for the same address twice.

Focus Not Obscured. Sticky headers and cookie banners often cover the item a keyboard user has just tabbed to.

What "WCAG 2.2 AA" usually means in a contract

"The site will meet WCAG AA" is a common line in proposals and RFPs. On its own, it leaves out the details that decide whether a project passes. A clear web accessibility clause answers five questions.

1. Which version? WCAG 2.0, 2.1 and 2.2 each have a different set of AA criteria.
2. Which level? AA includes every Level A criterion. Whole-site AAA is a target the W3C advises against.
3. What is in scope? Public pages, member portals, PDFs, video, embedded forms and third-party tools such as event or donation platforms.
4. How is it tested? Automated scans, manual review, assistive technology testing, or all three.
5. What evidence is delivered? Often an Accessibility Conformance Report.

Two WCAG rules matter for scope. Conformance applies to full pages, so a page with one inaccessible widget does not conform. It also applies to complete processes. If one step in a checkout or registration flow fails, the whole process fails at that level.

WCAG allows a statement of partial conformance when a failure is "legitimately outside the author’s control," such as a third-party widget. The W3C notes that this "is a statement of non-conformance."

For products, buyers often ask for an Accessibility Conformance Report built on the VPAT template from the Information Technology Industry Council. As of October 2026, the current template is VPAT 2.5Rev, with editions for Section 508, the EU standard EN 301 549, WCAG 2.2, and an international edition that combines all three.

Where WCAG 3 stands

WCAG 3 is a separate, longer-term project. The W3C published a new Working Draft in September 2026. Its WCAG 3 introduction calls it "an incomplete draft that will change" and says it is "not expected to be a completed W3C standard for a few more years."

The same page says "WCAG 2 will not be deprecated for several years after WCAG 3 is finalized." Its advice is direct: "The best way to prepare for WCAG 3 in the future, is to meet WCAG 2.2 success criteria now."

The draft also proposes changes to how conformance is scored. Our breakdown of the September WCAG 3 draft covers its proposal for one conformance level plus reporting tiers. For contracts signed today, WCAG 2.2 AA remains the target.

Web accessibility requirements and dates, as of October 2026

This is the one section of this guide that will date. It lists scope and dates only. How a rule applies to a specific organization is a question for its lawyer.

ADA Title II. The Justice Department’s 2024 rule set WCAG 2.1 Level AA for state and local government websites and mobile apps. An interim final rule published April 20, 2026 moved the compliance dates. Larger entities moved from April 24, 2026 to April 26, 2027. Smaller entities moved from April 26, 2027 to April 26, 2028. The ADA.gov fact sheet lists public schools, community colleges, public universities and public libraries among covered entities. It also lists five exceptions, including archived content and some documents posted before the compliance date.

Section 508 and the European Accessibility Act

Section 508. According to Section508.gov, the law "applies to all federal agencies when they develop, procure, maintain, or use electronic and information technology." The U.S. Access Board’s Revised 508 Standards, published in 2017, require electronic content to meet Level A and Level AA of WCAG 2.0.

European Accessibility Act. The EU’s summary of Directive (EU) 2019/882 says EU countries must apply it from June 28, 2025. Covered services include e-commerce, consumer banking, e-books, telephony and parts of passenger transport such as websites and e-tickets. The directive does not apply to "microenterprises providing services." The summary also lists transition periods, including one that runs to June 28, 2030 for some services already in use before the act applied.

Both US rules point to WCAG, at version 2.0 or 2.1. Building to WCAG 2.2 AA meets the WCAG criteria in each of those versions, since 2.2 is backwards compatible. One wrinkle: 4.1.1 Parsing was removed in 2.2, and the W3C notes that teams required to meet 2.0 or 2.1 may still need to test and report it.

How to test: what automated tools find and what they miss

Automated scanners are the starting point for most web accessibility audits. They are fast, run across thousands of pages, and catch the same mistake repeated on every page. They also miss a lot. The W3C’s evaluation guidance says "no tool alone can determine if a site meets accessibility standards" and "Knowledgeable human evaluation is required."

The best-known test of this is from the UK Government Digital Service. In 2017, it built a page with 143 deliberate failures and ran a set of automated tools against it. In its write-up of the results, the best single tool found 41% of the barriers when its prompts for manual checks were counted. Counting only errors and warnings, the top tool found 37%. All the tools together found 71%. The team’s conclusion was that tools "are most effective when combined with manual testing."

The study is from 2017, and tools have changed since. The pattern still holds. A scanner can tell that an image has no alt text. It cannot tell whether the alt text describes the image. It can confirm a form field has a label. It cannot tell whether the label makes sense.

We have covered the main platforms in detail: Deque’s axe, Siteimprove, Silktide and Level Access. Overlays, scripts that try to fix a site in the browser, are covered in our AudioEye explainer.

A manual web accessibility check you can run in an hour

The W3C’s Easy Checks are a good first pass, which the W3C calls "quick and easy, rather than definitive." Pick five pages: home, a content page, a form, search results and a page with video.

Keyboard. Put the mouse away and press Tab through each page. Can you reach every link, button and field? Can you always see where you are? Can you leave every menu and pop-up? Then complete one full donation or registration form by keyboard.

Screen reader. Turn on a screen reader, such as NVDA, which is free and open source, or the one built into your phone. Listen to the title, headings and links. Do link names make sense alone? Does the form say what each field is and what went wrong?

Zoom. Zoom the browser to 200%. Text should get bigger without content overlapping or disappearing.

Contrast and color. Check text against its background. WCAG 2.2’s AA contrast rule is 4.5:1 for normal text and 3:1 for large text. Make sure no instruction depends on color alone.

Media. Check that videos have accurate captions. Automatic captions need a person to review them. Our post on transcription model retirements covers the caption pipelines many sites rely on.

Write down what fails, with the page and the step. A developer can act on that list.

The most common web accessibility failures

Each year, WebAIM scans the home pages of the top one million websites for web accessibility errors. The WebAIM Million 2026 report, using data collected in February 2026, found detected WCAG failures on 95.9% of home pages. That is up from 94.8% in 2025. The average was 56.1 detected errors per page, up from 51.

These were the six most common failure types.

Two cautions apply. These are only errors a tool can detect, so the real rate is higher. WebAIM says "Absence of detected errors does not indicate that a page is accessible or conformant." And these are home pages, which are often the most polished page on a site.

Most of these fixes belong in the theme or component library, where one fix covers every page.

PDFs and other documents

Nonprofit, college and government sites often hold large libraries of PDFs: annual reports, minutes, forms and agendas. Web accessibility covers those documents too. The DOJ’s Title II rule addresses PDF, Word, PowerPoint and spreadsheet files directly.

The WCAG 2.2 techniques library includes 23 PDF techniques. Among them are alt text for images, correct tab and reading order, a set document language and a document title. Like all WCAG techniques, they are informative, showing one way to pass.

Three habits prevent most PDF problems:

• Publish HTML first. A web page is easier to make accessible, update and read on a phone. Offer the PDF as an extra download.
• Fix the source file. Headings, alt text and table headers set in Word or InDesign carry into the export.
• Inventory and retire. Remove documents nobody needs. Check any archive exception with counsel before relying on it.

Our accessible PDF checklist covers documents that have to stay PDFs. Our post on Guided Vision in Gemini Live explains why a phone’s AI describer does not replace an accessible file.

WordPress: where web accessibility comes from, and where it breaks

The WordPress accessibility coding standards say code in the WordPress ecosystem "is expected to conform to the Web Content Accessibility Guidelines (WCAG), version 2.2, at level AA."

Most of what visitors see comes from the theme, plugins and content, which our WordPress guide explains. Web accessibility tips for WordPress:

• Check the theme first. The accessibility-ready tag means a theme passed a review against set requirements. WordPress updated them on May 6, 2026, adding checks for reflow, text spacing, hover and focus content, and an accessibility statement. Treat the tag as a starting filter for your finished site.
• Test form plugins and page builders. Run the keyboard check on a real form after every major update.
• Set editor habits. Use real heading blocks in order, fill in alt text in the media library, and write link text that says where the link goes.
• Watch custom blocks and patterns. A block reused on hundreds of pages repeats its errors hundreds of times.

The WebAIM Million found WordPress home pages averaged 52.8 detected errors, 5.8% below the overall average. WebAIM cautions that errors cannot always be tied to a platform.

Drupal: accessible defaults, and the deadline that comes first

Drupal’s accessibility page, updated in October 2026, says "Drupal core targets the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA" for both public pages and the admin interface. The community also uses ATAG 2.0, the W3C’s authoring tool guidelines, for the editor experience. Web accessibility tips for Drupal:

• Start from Olivero and Claro. These are core’s default public and admin themes. Custom themes need their own testing.
• Turn on Inline Form Errors. It ships with core, off by default, and puts error messages next to their fields.
• Review contributed modules. Drupal.org says contributed modules do not pass through core’s accessibility gate, and contributed themes are not certified for accessibility.
• Configure CKEditor for language changes if your content mixes languages.

In the WebAIM Million, Drupal home pages averaged 41.2 detected errors, 26.5% below the overall average.

We explain the deadline in what Drupal 10 end of life means for your site. Our plain-language guide to the Drupal Webform advisories shows why patching matters on forms-heavy sites.

A web accessibility plan for agencies and in-house teams

A workable web accessibility plan has six steps.

1. Set the target in writing. WCAG 2.2 Level AA, with the scope listed: pages, forms, documents, video and third-party tools.
2. Get a baseline. Run an automated scan across the site and a manual check on your five most important pages and flows.
3. Fix at the source. Colors, focus styles, form components and heading structure belong in the theme or design system.
4. Train the people who publish. Alt text, headings, link text and captions are editors’ daily decisions.
5. Check vendors. Ask donation, event, AMS and learning platform vendors for a current Accessibility Conformance Report, and test their forms yourself.
6. Publish an accessibility statement with a way for people to report problems, and answer those reports.

Then keep it going. Add accessibility checks to the release process, rescan after major updates, and repeat the manual review on a schedule. Web accessibility is easier to keep than to win back.

Frequently Asked Questions