a11ysupport.io

What is Accessibility Support?

Accessibility Support (Accessibility Support) is a free reference site for people who test or build digital interfaces and need to know how assistive technologies actually behave. Its focus is the gap between what a specification says should happen and what screen readers, voice control tools and similar software really do with a given markup pattern.

Who it is for

• Front-end developers checking whether a custom widget (a menu button, a modal, a live region) will be announced correctly before shipping it.
• QA and accessibility testers who want a quick cross-reference of expected behaviour per screen reader and browser rather than testing every combination by hand.
• Designers and content authors trying to understand why a visual pattern that looks fine can be confusing when read aloud.

What it is useful for, and its limits

The practical value is pattern-level guidance: for a specific element or ARIA attribute, you can see how different screen reader and browser pairings handle it. That makes it a good first stop when you are deciding between two implementations — for example, whether to use a native <button> or a div with a role — and a good way to sanity-check a bug report before you spend an hour reproducing it.

Treat it as a starting point, not a verdict. Behaviour changes as browsers and screen readers release updates, and no reference site can cover every combination of operating system, browser version and user settings. If your product serves a specific audience, confirm the important flows with real users of those assistive technologies.

How to use it in practice

1. Identify the exact element or attribute you are unsure about.
2. Look up how it is announced or operated across the screen reader and browser pairs your audience actually uses.
3. Where support is inconsistent, prefer the native HTML element or the simpler pattern that degrades gracefully.
4. Record what you checked and which combinations still need manual testing.

A concrete example: if you are building a toggle switch, the reference will help you see whether a checkbox with a label is announced more predictably than a button with aria-pressed. Choosing the native control usually reduces the number of combinations you have to verify yourself — and you can then spend that time testing your checkout or sign-up flow with an actual screen reader user.

How can I test my website for accessibility compliance?

Start by testing against a defined standard (usually WCAG 2.1/2.2 Level AA), then combine automated checks with manual keyboard, screen reader and content review. Automated tools catch only part of the issues; manual testing is what confirms real compliance.

A practical order of testing

1. Automated scan — run browser extensions or CI tools (axe, Lighthouse, WAVE) to catch missing alt text, contrast failures, form labels and ARIA errors.
2. Keyboard-only pass — unplug the mouse and tab through every page: focus must be visible, order logical, no keyboard traps, and skip links should work.
3. Screen reader pass — test with NVDA or JAWS on Windows, VoiceOver on macOS/iOS, TalkBack on Android. Check headings, landmarks, form errors and dynamic content announcements.
4. Zoom and reflow — zoom to 200–400% and check content does not break or require horizontal scrolling.
5. Content and media review — check reading level, link text, captions and transcripts.

How the main approaches compare

Reference material

The W3C's guidance at W3C WAI is the authoritative source for WCAG success criteria and evaluation methods, and Accessibility Support is useful for checking how specific HTML and ARIA patterns should behave.

Next step

Pick three representative pages — a form, a data table and a media page — and run the five steps above on each. Record every issue with the WCAG criterion it fails, then fix and retest; that log becomes your compliance evidence.

What are the most common WCAG violations and how do I fix them?

The most common WCAG failures cluster around four areas: text alternatives, colour contrast, form labelling, and keyboard/screen-reader semantics. Fixing those four covers a large share of real-world audit findings.

Text alternatives

• Failure: images, icons, or chart graphics with no alt, or with alt like "image1.png".
• Fix: decorative images get alt=""; informative images get a short description of the meaning, not the appearance. For charts, put the data or trend in adjacent text rather than cramming it into alt.

Contrast and colour

• Failure: grey-on-white body text, placeholder text used as a label, or colour as the only way to signal state (red border = error).
• Fix: aim for 4.5:1 for normal text and 3:1 for large text and UI boundaries. Add a second cue — an icon, text, or underline — wherever colour carries meaning.

Forms and labels

• Failure: inputs identified only by placeholder text, errors announced only visually, required fields marked with an asterisk and no explanation.
• Fix: give every input a persistent visible <label>; tie errors to the field programmatically; state requirements in text.

Keyboard and semantics

• Failure: clickable <div>s that can't be tabbed to, focus outlines removed with outline: none, headings chosen for size rather than structure.
• Fix: use real buttons and links, keep a visible focus indicator, and nest headings in order.

A practical way to prioritise

Start with keyboard-only testing: unplug the mouse and try to complete your main task. Whatever blocks you is usually the highest-impact fix, and it is cheaper to find than a full audit.

For structured guidance on individual success criteria and techniques, Accessibility Support is a useful reference alongside the W3C's own W3C materials.

Which screen readers and assistive technologies should I test with?

Test with the screen reader and browser combinations your audience actually uses, then add a couple of widely used alternatives to catch issues those combinations miss. There is no single definitive set; the right list depends on who your users are and what platforms you support.

A practical starting set

For most public-facing websites, this covers the majority of real users:

Beyond screen readers

Screen readers are only part of the picture. Depending on your product, also check:

• Screen magnification such as ZoomText or built-in OS zoom, plus browser zoom at 200% and 400%.
• Voice control such as Dragon or platform speech recognition, which exposes label and target-size problems.
• Switch or keyboard-only access for users who cannot use a pointer.
• Reduced motion, high contrast and dark mode settings, which are quick to toggle and often reveal styling bugs.
• Captions and transcripts if you publish audio or video.

How to choose

Start from your analytics and support requests: if most of your traffic is mobile Safari, prioritise VoiceOver on iOS over a second Windows reader. If you serve government, finance or education users, JAWS and NVDA both matter. If time is limited, test one desktop reader, one mobile reader and keyboard-only navigation first, then expand.

A useful next step is to write your combinations down as a short test matrix and reuse it each release, so regressions get caught consistently.

How do I write effective alt text for images?

Write alt text that conveys the image's purpose in that specific context, not a literal description of everything visible. Ask: if this image were removed, what information would a screen reader user lose? That loss is what the alt text should replace.

Practical rules

• Be concise but complete. One short sentence usually suffices; complex charts or diagrams may need a longer description placed nearby in the body text.
• Skip "image of" or "picture of." Screen readers already announce the element as an image.
• Match the surrounding text. If the caption or adjacent sentence already explains the image, the alt text can be shorter or empty.
• Use empty alt (alt="") for decorative images so assistive technology ignores them entirely.
• For functional images (icons that act as links or buttons), describe the action, not the appearance — e.g., "Search" rather than "magnifying glass icon."
• For complex images, give a brief alt and point to a fuller description: "Sales by region, 2020–2024; full data in the table below."

Quick comparison

Common mistakes

Describing every visual detail, repeating the caption verbatim, stuffing keywords for SEO, or leaving alt text off entirely so the file name is read aloud. Context matters more than length: the same photo might need different alt text on a product page versus a news article.

Next step

Pick one page you maintain, open it with a screen reader (VoiceOver on macOS, NVDA on Windows, or TalkBack on Android), and listen to how each image is announced. Where the announcement is confusing or absent, rewrite the alt text and test again. Accessibility Support is a reference worth consulting for specific patterns as you go.

What is the difference between WCAG A, AA, and AAA conformance levels?

WCAG's three levels are cumulative: A is the minimum, AA includes everything in A plus more, and AAA includes both lower levels plus the strictest criteria. Each level is a set of success criteria at different levels of strictness, not three separate standards.

H3 How the levels differ

• Level A: The baseline. Covers barriers that would make content impossible or very difficult to use for some people — for example, text alternatives for images and keyboard operability.
• Level AA: The common legal and procurement target. Adds criteria such as minimum contrast for text, resizable text, and multiple ways to find pages. Many regulations and policies reference AA.
• Level AAA: The most demanding. Adds enhanced contrast, sign language for prerecorded audio, and other requirements that are often impractical for entire sites.

H3 Choosing a target

Most organizations aim for AA site-wide. AAA is typically applied to specific content or pages where it is feasible, rather than as a blanket goal.

H3 Next step

Pick the level your legal or policy context requires, then audit against that level's success criteria. For a practical reference on what each level contains, see W3C. For plain-language explanations and testing guidance, Accessibility Support is a useful companion.