Accessibility statement
If a system is going to write about automating science, its own website should at least be usable by everyone who wants to read it. This page states the standard we aim at, what we have actually built, what we know is still imperfect, and how to tell us when something does not work.
1. Our target
We aim for conformance with the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, as published by the W3C. We treat that as the floor rather than the goal: a page that technically satisfies a success criterion but is unpleasant to use with a screen reader has not really passed.
This site is not currently certified against that standard, and this page does not claim full conformance. What follows is an honest account of where things stand.
2. What we have done
- Structure. Every page has one
h1, headings in a logical order, amainlandmark, a labelled navigation region, and a breadcrumb trail on interior pages. - Colour contrast. Body copy is Inkwell Navy on a warm light canvas, and muted text stays at a contrast ratio above 4.5:1 rather than relying on a fashionable grey.
- No colour-only meaning. Statuses, badges and table rows always carry a word as well as a colour.
- Motion. Every animation — the revealing sections, the floating shapes, the marquee, the live experiment console — is disabled under
prefers-reduced-motion: reduce. - Content without JavaScript. Reveal animations are scoped behind a scripting class, so nothing is hidden permanently if JavaScript fails or is blocked.
- Keyboard operation. The mobile menu toggle reports its state with
aria-expanded, links and controls are reachable in a sensible order, and focus styles are visible. - Decorative art. Every doodle, blob, mascot and diagram is marked
aria-hiddenor given a text alternative, so it does not clutter a screen reader's output. - Images. Illustrations carry descriptive alternative text rather than filenames, and long tables scroll horizontally instead of squeezing into unreadable columns.
- Forms. The contact form uses real
labelelements, marks required fields in text as well as style, and announces its status message through a live region. - Language and zoom. The document language is declared, layouts are fluid, and nothing breaks at 200% zoom or on a 320px-wide viewport.
3. Known limitations
These are the gaps we are aware of. If you find one that is not listed, we would genuinely like to hear about it.
| Area | Limitation | Status |
|---|---|---|
| Hand-drawn illustrations | The SVG artwork is decorative and conveys no information on its own; descriptions are deliberately short. The diagrams on the technology page carry longer alternatives because they do carry meaning. | known, acceptable |
| Wide data tables | Tables scroll horizontally on narrow screens rather than reflowing. On a small screen this can require two-dimensional scrolling. | being improved |
| Live console on the homepage | The simulated experiment log updates on a timer. It is marked as decorative and its container is hidden from assistive technology, because a stream of changing text is not useful to announce. | by design |
| Third-party typeface | Fonts load from Google Fonts. If that request is blocked, the site falls back to system fonts; spacing is tuned but not pixel-identical. | open |
| Independent audit | No third-party accessibility audit has been carried out. Our checks are internal and manual. | not yet |
4. Compatibility
The site is built on standards rather than on a framework's rendering quirks, and is checked in current versions of Chrome, Firefox, Safari and Edge on desktop, and in Safari on iOS. It does not depend on hover for any essential function, does not require a pointing device, and works with browser text-resizing and with operating-system high-contrast settings.
We do not provide a separate simplified version of the site, because we would rather have one version that works than two, one of which is maintained.
5. Tell us
If something blocks you — a link you cannot reach by keyboard, text you cannot read, a diagram whose description does not help, a form that does not tell you what it wants — please write to accessibility@autoscientia.com.
- Please include the page and, if you can, the assistive technology or browser you were using.
- We aim to acknowledge within 5 working days.
- Blocking problems are triaged as bugs rather than as feature requests, and get a fix or an explanation.
- Where a fix takes time, we will say what the interim workaround is rather than leaving you waiting in silence.
6. How we test
Every new page goes through the same checklist before publication: heading structure, landmarks and labels; contrast of the text and interactive colours actually used; keyboard traversal of every control; image alternative text; table headers; reduced-motion behaviour; and rendering with JavaScript disabled. Content is then read once with a screen reader and once at 200% zoom.
That is a manual process on a small site, and it is not infallible. This statement is reviewed twice a year, and the date at the top of the page is the date it was last checked rather than the date it was last edited.
This statement is written in direct reference to our own site, not as a generic policy. Where the site falls short, the limitation is named above rather than omitted for tidiness.
Something here doesn't work for you?
Tell us which page and what blocked you. Accessibility bugs get fixed like any other bug, because that is what they are.