Accessibility Statement

Our commitment

Accessibility is a build requirement here, not a compliance exercise added at the end. Every interface ships against the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, and a regression against that standard is triaged like any other broken feature.

We are stating a commitment and a working standard — not a certificate. This site has not been through an independent accessibility audit. We would rather say so than imply a conformance level nobody has verified, which is its own kind of accessibility failure.

Conformance status

Partially conformant with WCAG 2.2 Level AA. Partially conformant means most of the site meets the standard, and the exceptions are the ones named under "Known gaps" below. We assess against WCAG 2.2 AA and, for European visitors, the equivalent requirements of EN 301 549.

What already works

Keyboard and focus

• Every interactive control can be reached and operated without a mouse.
• The focus indicator is visible and deliberately styled — never suppressed with outline: none.
• Focus order follows the visual reading order.
• Menus, dialogs and accordions can be opened, operated and dismissed from the keyboard, and Escape closes them.
• No keyboard traps: you can always tab back out of a component.

Structure and semantics

• Real headings in a logical order, so screen-reader users can navigate by heading rather than reading linearly.
• One <h1> per page.
• Landmark regions — header, navigation, main, footer — so assistive technology can jump between them.
• Lists marked up as lists and tables as tables, with header cells identified.
• Native buttons and links used for their real purpose, so they behave as expected without JavaScript patching.

Colour and contrast

• Body text meets or exceeds the 4.5:1 ratio; large text meets 3:1.
• Both light and dark themes are contrast-checked. Dark mode is a designed theme, not an inverted filter.
• Colour is never the only way information is conveyed — status is carried by an icon or a label as well as a hue.

Text and zoom

• Layouts use relative units, so browser zoom and a larger default font size reflow the page instead of clipping it.
• Content works at 200% zoom, and reflows to a single column at 400% without horizontal scrolling.
• Wide content such as data tables scrolls inside its own container so the page itself never scrolls sideways.
• Text is never rendered as an image.

Motion and timing

• Animation is gated behind prefers-reduced-motion. Switching it on in your operating system removes the movement without removing any function.
• Nothing flashes more than three times per second.
• No content moves, auto-advances or auto-plays audio without a control to stop it.
• No time limits on reading or completing a form.

Forms and errors

• Every field has a real, programmatically associated label — not a placeholder standing in for one.
• Errors are described in text, not signalled by colour alone, and are announced to assistive technology.
• Required fields are identified before submission, not only after it fails.
• Icon-only buttons carry an accessible name.

Images and media

• Meaningful images carry alternative text that conveys their purpose.
• Decorative images are hidden from assistive technology rather than announced as noise.
• Icons used as decoration are marked aria-hidden; icons that carry meaning have a text alternative.

Known gaps

An honest statement names what does not work yet. These are the areas we are aware of and actively working on:

• Embedded third-party content. Advertisements, video players and payment frames are rendered by external providers. We choose partners with care but cannot guarantee their internal accessibility. Where a payment frame is a barrier, contact us and we will take the payment another way.
• Older archive content. Some long-standing articles predate our current standards and may have imperfect heading order or missing alt text. We fix these as we find them and as they are reported.
• Complex comparison tables. A handful of wide tables scroll horizontally on small screens. They remain readable and keyboard-scrollable, but the experience is not equivalent to the desktop one.
• AI-generated output. Tool output is produced by a language model. We control the container, its formatting and its labelling; we cannot guarantee the internal structure of the generated text.
• Third-party embeds in user submissions. Guest posts may include embeds we did not build.

What we test with

We test against the combinations people actually use, not just an automated checker:

• Screen readers — NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
• Keyboard only — every flow completed without touching a pointing device.
• Zoom — 200% and 400% browser zoom, plus increased OS-level font size.
• Colour — contrast ratios checked against the token palette in both themes.
• Reduced motion and dark mode — both OS preferences honoured.

Automated tooling catches roughly a third of accessibility issues. The rest needs a person, which is why reports from real users matter more to us than a passing scan.

Reporting a barrier

If something here stops you doing what you came to do, we want to know. A barrier you hit is worth more to us than a checklist we passed.

Write to accessibility@aitoolsay.com, use the report an issue form, or the contact page. It helps enormously if you can tell us:

• The page URL.
• What you were trying to do.
• What happened instead.
• Your browser, operating system and any assistive technology you were using.

None of that is required — a one-line "the cookie banner traps my keyboard" is a perfectly good report and we would still rather have it.

What happens next

1. Acknowledgement within 2 business days.
2. An assessment of what is failing and which success criterion it falls under.
3. A fix or a timeline in the same reply. Where a fix will take time we will offer a way to get the same result in the meantime.
4. Confirmation when it ships, so you know it is done rather than having to re-test on spec.

Accessibility bugs are prioritised above feature work. A barrier that locks someone out entirely is treated as urgent.

If we do not resolve it

If our response does not fix things, say so directly and ask for it to be escalated — we would rather hear it twice than lose you. Depending on where you live you may also have the right to raise the matter with a national accessibility or equality body, and we will not treat your doing so as a reason to stop helping you.

Changes to this statement

This statement is reviewed whenever the site changes materially, and at least annually. The last-updated stamp at the top of the page reflects the current version.

Contact

Accessibility: accessibility@aitoolsay.com. General enquiries: the contact page.