Quick summary
- WCAG 2.2 Level AA is the standard worth targeting. It adds nine fresh success criteria on top of WCAG 2.1, covering keyboard focus, dragging, target size and authentication.
- Accessibility carries legal weight too. The DOJ’s ADA Title II rule now sets compliance dates of April 2027 for larger entities and April 2028 for smaller ones. The EAA applies across the EU.
- Automated scanning tools alone won’t catch enough. Pair axe, WAVE or Lighthouse with hands-on keyboard testing and a screen reader.
- Treat accessibility as an ongoing part of product quality rather than a task you finish once. Sort issues into quick fixes and higher-risk barriers first, then fold checks into your regular workflow.
Designing websites and digital services according to accessibility standards means making the content accessible to people with disabilities and helping them to perceive, navigate, understand, and use the content. By 2026, accessibility will no longer be just an ethical or legal issue. It will become a matter of user experience, search visibility, conversion, and trust for your brand.
A good first step is the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. WCAG 2.2 incorporates 9 new success criteria and builds upon WCAG 2.1. Areas of focus include keyboard focus, interactions that involve dragging, target sizes, help, data entry, and user authentication.
The importance of accessibility
Based on World Health Organisation statistics, approximately 16% of the world’s population has a disability that makes access to web content difficult and usability of technology impossible. These individuals may use browser extensions, screen magnifiers, virtual assistants, and other assistive technologies.
A site that is not accessible prevents users from completing simple tasks (i.e. reading, form completion, scheduling, purchase). Fixes to accessibility issues often benefit all users and are not just for the disabled. Readability is improved with descriptive headings. Captions improve comprehension in noisy environments. Keyboard interfaces are used by power users and those on mobile or alternative input devices.
There is a legal side, too. Public agencies in the US fall within the Department of Justice’s ADA Title II rule on website and mobile app accessibility. In April 2026, the DOJ published an interim final rule with a compliance date of April 26, 2027, for larger state and local governments. The European Accessibility Act supplies similar mandates for certain goods and services, including digital offerings in the EU market.
Investing in legal compliance only is not a smart approach. A site that works for more people expands the audience size, reduces support queries, enhances customer trust and reduces avoidable legal risk.
WCAG and the POUR principles
WCAG structures accessibility across principles that form the acronym POUR.
- Perceivable means users must have ways to receive information through sight, hearing, or any other mode.
- Operable means users must have ways to interact with and control the different elements on the site and traverse the site.
- Understandable means content, instructions, and interfaces must be rational and simple.
- Robust means the site must maintain its functionality across the myriad of technologies that assist users as well as whatever might come in the future.
WCAG has three levels of conformance. Level A covers requirements that address the majority of accessibility barriers. Level AA is the level that most organizations and regulatory agencies target. Level AAA is generally too high a level for many types of content.
Level AA has been proven to be reasonably achievable for many, if not most, websites. Checking off a list will not make a website usable. Accessibility has to do with design and development as much as it does with content and testing.
WCAG 2.2 has introduced nine new success criteria. What do they mean?
| Criterion | Level | Description |
|---|---|---|
| Focus Not Obscured, Minimum | AA | All content, including sticky headers, dialogs, etc. should not completely cover keyboard focus. |
| Focus Not Obscured, Enhanced | AAA | Focused control must be completely visible. |
| Focus Appearance | AAA | Focus indicators must be visible and distinguishable. |
| Dragging Movements | AA | If completing a task or action requires dragging etc., there must be an alternate means of performing the task or action. |
| Target Size, Minimum | AA | Interactive targets should be large enough to be used with a reasonable degree of accuracy. |
| Consistent Help | A | Repeated help mechanisms should be in a predictable location. |
| Redundant Entry | A | Users should not be required to enter the same information multiple times during the same task or process. |
| Accessible Authentication, Minimum | AA | The authentication must not depend on a memory or cognitive test. |
| Accessible Authentication, Enhanced | AAA | User must not be subject to additional exceptions to inaccessible authentication methods. |
Practical Techniques
Write relevant alt text
Alt text on images that communicate a concept or message needs to be relevant and not be empty. An image of a black hiking backpack could have “Black waterproof hiking backpack with two front pockets”. An image that is used strictly as a divider could have no alt text, and a screen reader would skip over it.
Please don’t stuff alt text with keywords. Explain what the relevant image is communicating in its context.
Make sure you keep color contrast as high as possible
As per the WCAG guidelines, the minimum contrast ratio of normal sized text should be 4.5:1, while large text could be 3:1. Do not utilize colors to convey critical information. An error message, for instance, should have a red border along with text or an icon.
| : root { –text: #1f2937; –background: #ffffff; –focus: #005fcc;} body { color: var(–text); background: var(–background);} :focus-visible { outline: 3px solid var(–focus); outline-offset: 3px;} |
Use a Strict Heading Hierarchy
A single page should have one main heading, with lower-order headings which should follow a logical order. Avoid using header tags just because the font size looks good. Let HTML take care of semantics and structure.
A page should generally flow from <h1> to <h2>, <h3>, and so on. Skipping levels in a heading hierarchy can mess up a screen reader’s ability to help users navigate the page.
Make sure the page supports keyboard navigation
Each interactive element on the page should be accessible to keyboard navigation. Users should be able to navigate links, buttons, menus, dialogue boxes, forms, and all types of user interfaces and controls with the Tab key, Shift+Tab, Enter, Space and the arrow keys.
Browser focus outlines should not be stripped unless a replacement is added that is as visible. Test sticky navigation bars, cookie banners, modals, carousels, and menus to make sure they do not trap or hide keyboard focus.
Properly Label Forms
Each form field needs to have a label that is programmatically linked to it. Placeholder text does not replace a label because it disappears when the user types.
Email address
Error messages should identify the field, describe the problem, and give instructions to the user on how to correct it. Required fields must be indicated visually and through accessible text.
Native HTML over ARIA
Native HTML elements have accessibility features built in. When building a clickable element, use a <button>, not a <div>. For navigation links, use an <a> element.
While ARIA components can be used to improve custom components, poorly used ARIA components can make an interface worse, not better. Skip ARIA where built-in HTML elements can be used.
Set Priorities
Long lists of results from accessibility audits make prioritizing work necessary. Work can be separated into three distinct categories.
- Quick fixes include adding form labels, fixing heading order, restoring focus guides and alt text, and obvious contrast errors.
- Higher risk barriers cover problems relating to keyboard traps, broken checkout flows, locked out login systems, dialogues that act in unexpected ways and controls that assistive tech is unable to operate.
- Structural work involves processes to replace inaccessible widgets, improve component libraries, and add accessibility check tools to your practice of design and development.
Address problems that impact critical user journeys first. A missing alt attribute on a decorative image is less important than a keyboard user who is unable to complete a payment form.
Accessibility Testing of Websites
Tools such as axe, WAVE, and Lighthouse find a good amount of common issues. They can be useful during the development phase and continuous integration scans, but they can’t assess everything.
Automated scans can find missing labels, broken ARIA, and some structural issues. They can’t determine whether the alt text is sensible, whether the instructions are clear, or whether a complex process is usable in practice.
An effective testing process consists of multiple aspects:
- Automated scans need to be used during the development cycle and deployed.
- Testing with a keyboard and no mouse is also important.
- Testing at varying levels of zoom with different browser engines is needed.
- Testing with assistive technology such as JAWS, VoiceOver, Talkback, and Narrator is important.
- Testing a website on mobile devices also needs to be done.
- If possible, test your website with people with disabilities that use assistive technology.
Automation may check for button accessibility name, but only a human can evaluate whether the name “Continue” is actually helpful to the customer because the customer needs to know if the button progresses them to shipping or payment.
Platform specific examples
WordPress
Look for a pre-made theme as a starting point and check page builder elements and components before publishing. Accessibility plugins can raise issues, but an overlay or toolbar won’t fix the issue.
Shopify
Check the functionalities of the theme including filters, variant selectors, checkout content, etc. Also check if screen reader users are notified of any dynamically updated content and if they can place an order without using the mouse.
Webflow and other similar design tools
Look at the HTML output and not design canvas. Check page structure, heading hierarchy, link names, form labels, and check focus order.
Custom applications
Include accessibility as a requirement in initial component specifications and user acceptance criteria. Test components that will be used repeatedly like dialogs, tabs, and menus before they are integrated throughout the application.
Accessibility statements and VPATs
Draft a statement on accessibility commitments, standards, use case examples, known issues, how to report barriers, contact information, and feedback procedures. Be truthful and always update the statement.
A Voluntary Product Accessibility Template (VPAT) offers vendors a method of communicating the product and/or service offered and how much of it complies with accessibility standards. It is vitally important to procurement when a software or service is being sold to the government or enterprise clients. A VPAT may not indicate full accessibility. It should state what is supported, what is unsupported, and what workarounds are available.
Accessibility, SEO, and AI search
Accessibility and search optimization usually work in sync. Semantic HTML helps assistive technologies and search engines read a page and understand it, respectively. Headings, image descriptions, descriptive link texts, and well-structured content make a page scannable, and it usually helps search engines understand the content and index the page.
The same principles apply to AI search systems. The content must have enough semantics to be answered by an AI system. Answer systems rely on a page’s content that is easy to access and interpret as the answer to a query.
Although accessibility alone doesn’t guarantee that a page will be adopted in an AI Overview or a chatbot, content that is logically organized, accessible, and useful tends to be easy to understand for both people and machines.
FAQ
What is WCAG 2.2?
This version of the Web Content Accessibility Guidelines from the W3C outlines nine new success criteria and is an update of WCAG 2.1.
What are the differences between WCAG 2.1 and 2.2?
This version adds nine new accessibility standards. This version includes standards with focus visibility, mobile accessibility, and login accessibility.
Is web accessibility a legal mandate in 2026?
Yes, for US state and local government sites. The Department of Justice’s ADA Title II requires WCAG 2.1 AA by April 2027 and April 2028. Digital service offerings in the EU fall under the European Accessibility Act. Private organizations that don’t fall under these requirements still face potential liability from ADA Title III lawsuits.
How can I check if my website is accessible?
Use axe, WAVE, or Lighthouse web accessibility scanners and test with a keyboard and a screen reader like NVDA or VoiceOver. Automated tools should never be used alone because they will miss so much.
What do the accessibility levels mean?
A, AA, and AAA are levels. A is the baseline. AA is the level most organizations target. AAA is the highest level most organizations don’t need to meet.
How often should I test for accessibility?
When offering a new website or completing a redesign, conduct a full accessibility audit. Ensure automated accessibility checks are incorporated into your deployment pipeline, and complete a full accessibility audit manually at least once a year.
2026 accessibility checklist
When publishing or redesigning your website, do the following:
- Alt text is present on all images.
- Controls and text meet contrast requirements.
- Headings and grouped content have an order that makes sense.
- All functionality is activated by the keyboard.
- Focus states are apparent.
- Forms must include labels, messages, and instructions that describe errors.
- Links and buttons have meaningful names.
- Videos include captions and audio descriptions as needed.
- Custom components adopt correct keyboard and ARIA interaction.
- Mobile layouts work effectively with zoom and reflow.
- Automated, manual, and assistive technology testing are performed.
- Accessibility issues are logged and have the fix retested.
- An accessibility statement with defined contact information is included.
Accessibility should be a standard of quality for all product development. When developers and content publishers work together with designers and decision makers, web products become useful for a greater variety of people.
