Guides / Concepts explained

What Is Web Accessibility? WCAG and Inclusive Design Explained

Web accessibility means people with disabilities can use your site. What WCAG 2.2 asks for, common failures in AI-built apps, and what to ask your AI builder.

Mythex Team · 2026-09-29 · 6 min read

Web accessibility means building websites and apps so that people with disabilities can use them — whether they're blind and use a screen reader, can't use a mouse, have low vision or colour blindness, are deaf, or have cognitive or learning disabilities. In practice it comes down to things like text alternatives for images, enough colour contrast, forms with proper labels, and everything working with a keyboard alone. The international standard for it is WCAG, the Web Content Accessibility Guidelines from the W3C.

Accessibility is often shortened to a11y — "a," then 11 letters, then "y."

Why accessibility matters when you build with AI

AI builders are good at producing apps that look right. Accessibility is mostly about what you can't see in a screenshot: whether a button is really a button, whether an input has a label a screen reader can announce, whether you can reach the menu with the Tab key.

That's why it matters to ask:

• It's easy to miss. A custom-styled dropdown can look perfect and be impossible to use without a mouse. You won't notice unless you test for it.
• It's cheaper to get right early. Asking for accessible components from the first prompt costs almost nothing. Retrofitting a finished app means touching every screen.
• It helps everyone. Captions help people in noisy places, good contrast helps people on phones in sunlight, and clear labels help everyone fill in forms faster.
• It overlaps with SEO. Proper headings, descriptive links and alt text help search engines understand your pages too — see SEO for AI-built websites.
• It may be required. Depending on where you operate and who you serve, accessibility can be a legal obligation.

An everyday analogy

Think of the entrance to a building.

Steps work fine for many people. A ramp works for wheelchair users — and also for parents with prams, delivery workers with trolleys and travellers with suitcases. Automatic doors, clear signs, braille on lift buttons and good lighting each remove a barrier for someone.

Web accessibility is the same idea for digital spaces: the ramps, signs and handrails of your app. And just like a building, it's far easier to include a ramp in the plans than to add one after the concrete sets.

WCAG in a nutshell

WCAG is published by the W3C's Web Accessibility Initiative. The current version is WCAG 2.2, first published in October 2023. It's backwards compatible: content that meets WCAG 2.2 also meets 2.1 and 2.0, and the W3C encourages using the latest version. WCAG 2.2 is also approved as an international standard, ISO/IEC 40500:2025. A very different WCAG 3 is in development as an early draft, not a finished standard.

WCAG is organised under four principles, often remembered as POUR:

Each guideline has testable success criteria at three levels:

• Level A — the minimum. Failing these blocks some people completely.
• Level AA — the standard target, and the level most laws and policies point to.
• Level AAA — the highest level. Useful to aim for in places, but the W3C doesn't recommend requiring it for entire sites, as some content can't meet it.

WCAG 2.2 added nine success criteria to 2.1, including Target Size (Minimum) at level AA — clickable targets should generally be at least 24 by 24 CSS pixels, with exceptions — and Accessible Authentication (Minimum), which limits login steps that rely on memory or puzzles, such as having to retype a password without being allowed to paste it. It also removed the old "Parsing" criterion as obsolete.

A worked example: a sign-up form

Here's a sign-up form an AI might produce, and what an accessibility check finds:

None of these fixes changes how the form looks much. All of them change whether some people can use it at all.

Key terms

Common misconceptions

• "Accessibility only matters for blind users." It covers visual, motor, hearing, speech and cognitive disabilities, plus temporary situations like a broken arm.
• "Accessible sites look plain." Accessibility constrains a few things — contrast, focus styles, text size — but good-looking accessible sites are the norm, not the exception.
• "An automated checker says 100, so we're done." Automated tools catch only some issues. Whether alt text is actually meaningful, or a flow makes sense with a screen reader, needs a person to check.
• "An overlay widget will make us compliant." Toolbars bolted on top can't fix missing labels or broken keyboard access in your code. Fix the source.
• "We have no disabled users." You may simply not know. Many disabilities aren't visible, and people who hit a barrier usually just leave.

What to ask your AI builder

• "Build this to meet WCAG 2.2 level AA."
• "Use semantic HTML: real buttons, links, headings in order, and labels for every form field."
• "Make sure every interactive element works with the keyboard alone and has a visible focus style."
• "Check all text and icon colours for contrast — 4.5:1 for normal text, 3:1 for large text and icons."
• "Add meaningful alt text to informative images and empty alt text to decorative ones."
• "Show form errors as text, linked to the field, not just with colour."
• "Respect the user's reduced-motion setting for animations."
• "Run an automated accessibility check and list what it can't test, so I can check that by hand."

Then test it yourself: put the mouse aside and try to complete your main flow using only Tab, Shift+Tab, Enter and Space. Try your phone's built-in screen reader on the main page. Zoom the browser to 200% and see if anything breaks.

Accessibility in Mythex

Mythex doesn't include a dedicated accessibility checker, so treat accessibility as part of your prompts and your testing. Ask for WCAG 2.2 AA from the first prompt, check the result in Preview with the keyboard, and use /test to have the agent click through your main flows before you publish — see App Testing. The SEO recipe also asks for semantic headings and meaningful alt text, which serve both goals.

For a hands-on checklist, see how to make your website accessible. For design, read how to design a good-looking app with AI, and before launch, how to test your app before launch. The W3C's own WCAG overview is the authoritative source.