Where we stand
We are working toward the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, as our target. We have not yet completed a formal, independent accessibility audit, so we do not claim full conformance today. What follows describes the accessibility features already built into the platform and the work we know is still ahead.
How we build
Accessibility is part of our normal development. In practice, that includes:
- A "skip to main content" link and semantic landmarks (a main content region, plus header, navigation, and footer) so assistive technology can move around a page quickly.
- A visible keyboard focus indicator on interactive controls, so you can see where you are when navigating without a mouse.
- Honoring your operating system's reduce-motion setting: when it is turned on, we reduce animation and motion across the site.
- Layouts that reflow, with breakpoints measured in relative units, so the interface responds to your browser's base text size.
- Light, dark, and high-contrast themes, and reading ink in the manuscript reader that is adjusted automatically for legibility against the page behind it.
- Labels on form fields, and status and error messages that are announced to assistive technology rather than signalled by color alone.
- Modal dialogs that keep keyboard focus inside them, return focus to where you were when they close, and dismiss with the Escape key.
The reading experience
Most reading happens in the manuscript reader, so it gets particular attention. You can adjust text size, line spacing, and margins; switch between light, dark, and e-ink (black-on-white) reading modes; and choose a typeface, including one selected for readability. In paged mode you can turn pages with the arrow keys, and the reader's menus and dialogs are operable from the keyboard.
The reader also applies per-reader watermarking to protect authors' work. The watermark is drawn as a visual layer that is hidden from assistive technology and is not part of the page text, so it does not reach screen-reader output. Some of the reader's other content-protection features can affect certain assistive-technology workflows (for example, text selection is intercepted); improving how those work with assistive technology is part of our ongoing review.
Known limitations
We would rather be honest than overstate. Because we have not finished a formal audit, we are not publishing a verified conformance report yet. From our own review, we already know these areas need work:
- In Windows High Contrast and other forced-colors modes, some focus indicators may not appear.
- Parts of the interface use fixed text sizes that do not grow with your browser's font-size setting; the reader has its own text-size control, and browser page zoom works throughout.
- Not every control is fully labelled for assistive technology yet, and some icon-only buttons still need accessible names.
- Some custom controls, such as tabbed navigation and drag-and-drop reordering, do not yet support every keyboard interaction people may expect.
- Color contrast is adjusted automatically in the reader, but we have not yet verified it everywhere in the interface.
As we complete our audit, we will keep this list current and add target dates for fixes.
Testing and assistive technology
We have not yet run a formal round of assistive-technology testing. As we carry out our accessibility review, we plan to test with common screen readers on current versions of the major browsers, and we will note the specific combinations here. In the meantime, real-world reports from people using assistive technology are some of the most valuable testing we can get.
Tell us about a barrier
If you run into an accessibility barrier anywhere on Thing.pub, email contact@thing.pub with the page you were on and what happened. We treat accessibility barriers as a high priority and will get back to you.
Other formats
If you need this statement, or any of our policies, in a different format, email contact@thing.pub and we will provide one.