Accessibility statement
Accessibility at Ovenbird
We want everyone on a team to be able to use Ovenbird: with a keyboard, a screen reader, magnification, or reduced motion. Our target is WCAG 2.2 Level AA for the website and the application.
What is in place
- Every control works with the keyboard: tabs use arrow keys, options and toggles are real buttons with their pressed state announced, dialogs trap focus and close with Escape.
- A "Skip to content" link on every page; one main landmark; labelled navigation regions; headings in order.
- Visible focus on every interactive element; text contrast of at least 4.5:1 on all surfaces, 3:1 for large text; information never conveyed by colour alone (status pills carry text, charts have numbers).
- Results that appear after an action (answers, marking, simulation verdicts, form status) are announced to screen readers through live regions.
- Moving content can be paused (the animation on the home page has a pause button; the simulation has play/pause), and the system "reduce motion" preference turns animations off.
- Forms have visible labels, required fields are marked in text as well as with a symbol, errors are announced and keep the data you typed.
- Touch targets are at least 24×24 CSS pixels; the layout works at 320 px wide and at 400% zoom without horizontal scrolling.
- The interface is available in English, Spanish, Italian and German, with the page language declared for assistive technology.
Known limitations
- The queue simulation's live chart is a visual summary; the same figures are given in the table beneath it and in the verdict line, which are what screen readers read.
- The Design studio's workflow diagram (SVG) is exported for slides and documents and is not fully navigable by keyboard; the same process is available as a text list in the Builder and as Markdown.
- Process documents and Confluence pages shown inside Ovenbird keep their authors' structure; we cannot fix headings or alt text in content we read from elsewhere.
- Third-party pages we send you to (Stripe Checkout, Atlassian consent, Google and Microsoft sign-in) are governed by those providers' accessibility statements.
How we test
Automated checks (axe-core, WCAG 2.2 AA rules) run on the public pages before a release; keyboard and screen-reader passes (VoiceOver on macOS and iOS, NVDA on Windows) on the main flows: sign in, ask for a next step, take a course, change a plan. We fix accessibility defects with the same priority as functional ones.
Tell us about a barrier
If something is hard or impossible to use, write to [ACCESSIBILITY EMAIL] with the page and what happened. We answer within five business days and say what we will change and when. If you need a document or an answer in another format, ask and we will provide it.
Standards and law
This statement follows the model of the EU Web Accessibility Directive and the European Accessibility Act (Directive (EU) 2019/882) and the Americans with Disabilities Act's expectations for digital services. Conformance target: WCAG 2.2 AA. Last reviewed: 2026-10-09.