Accessibility
Built accessible, on purpose.
Most sites treat accessibility as a checklist at the end. For AbleVerse it is the point of the whole project. This page says what we build to, how we test it, and how to tell us when we miss.
Our commitment
AbleVerse exists for people with disabilities. So the people this site is for are the people this site has to work for, first, not eventually. Every page is built to WCAG 2.2 AA, the current Web Content Accessibility Guidelines, and we treat that standard as the floor, not the goal. When a design choice and an access choice conflict, access wins.
What that means in practice
- The site works with screen readers, and every image that carries meaning has a text description.
- Everything can be reached and used with a keyboard alone. No mouse required, ever.
- Pages stay readable and usable at 400 percent zoom, on any screen size.
- Motion is optional. The site honors your device's reduced motion setting, and the Calm motion button at the top of every page turns animation off entirely.
- Every video we publish carries captions.
- The text size, high contrast, and calm motion controls work without an account, and your choices are saved on your own device, never sent to us.
- We write in plain language, because a page you cannot understand is a page you cannot use.
How we test it
Accessibility checks are run on every page before a change ships, and the live site has been verified programmatically, page by page. The standard for human testing is set: NVDA, JAWS, and VoiceOver, keyboard only, 400 percent zoom, and reduced motion, with testers with disabilities always paid. That human testing round has not happened yet, and until it has, we will not claim it has.
No overlays. Ever.
You will never see an accessibility overlay on this site, the kind of third party widget that promises to make a site accessible with one line of code. Overlays sit on top of a page and interfere with the tools people have already set up the way they need them, and they hide problems instead of fixing them. When something here is not accessible, we fix our own HTML. There is no shortcut, and we are not looking for one.
Who builds this
AbleVerse pays disabled people to test what we build, and that is the smaller half of the commitment. As we hire, we actively recruit disabled people onto the team that builds the platform itself. A product for people with disabilities should be made with and by people with disabilities.
Known limitations
Honesty is part of access. If a newer page is rough for you, that is exactly the kind of thing we want to hear about.
As of September 4, 2026:
- Human screen reader testing has not happened yet, on any page. The standard for it is set, testers with disabilities will always be paid, and the first round is being scheduled. Until it has happened, we will not claim it has.
- Our application at app.ableverse.org now carries this site's accessibility controls (text size, high contrast, calm motion, listen), on every page. What it does not have yet is this site's page by page check, where every page is verified and none is skipped: some of the application's pages are checked on every change, and not all of them are. Until that is all of them, we will not say the two are held to the same standard.
Tell us what is broken
If any part of this site is hard or impossible for you to use, email hello@ableverse.org. Tell us what happened and what you were using, in whatever words work for you. You do not need the technical terms. A human reads every message, and you will get an answer. An accessibility barrier here is a bug, and we treat it like one.
This statement was last reviewed on September 4, 2026. Each time we review it, this date changes.