Access is part of the experience.

Our accessibility aim

We aim for WCAG 2.2 AA. That is a design and testing target, not a certification. We use readable text, visible focus indicators, labelled inputs, responsive layouts and reduced-motion support. No automated test can establish that every person can complete every task.

Ways to use the interface

Navigate links and forms with a keyboard. The journal has a skip link, headings and a table of contents. Form feedback is announced through status areas. Article layouts adapt to smaller screens, and illustrations include alternative text where they convey information.

Tell us about a barrier

If something blocks a task, send the page URL, what you were trying to do, your browser/device and any assistive technology involved. Share only the details you are comfortable providing. We will investigate without requiring a diagnosis or medical information.

Report an accessibility issue, read help, or return to the journal.

Participation depends on clear content

Organizers should write direct titles, distinct comparable options and plain instructions. Include the full date and named timezone where timing matters. Explain what a saved response means and what happens after the deadline. A color, emoji or visual position should not be the only identifier for an option or status.

Use descriptive image text where an image matters. Place a readable link and purpose near a QR code, and title an embedded frame. Do not ask participants to disclose a diagnosis publicly in order to request access. Offer a practical private contact route for needs that cannot be addressed in the ordinary request.

Controls across devices

The interface adapts to phone, tablet and wide desktop layouts with keyboard-operable standard controls and visible focus. The assistant supports Escape to close, Enter to submit and Shift+Enter for a line break. Privacy preferences remain available through a persistent control. Receipt extraction requires an explicit review before it can fill the bill builder.

Brand accents are checked for sufficient contrast against white text. Local worker processing can still depend on browser capabilities and available memory. A slower device or blocked script should have an appropriate manual-entry or direct-help fallback. Avoid treating optional enhancement failure as a reason to exclude a participant from the underlying group decision.

Report an actual barrier

Send the URL, browser, device size and affected control through Contact. Describe whether the issue concerns focus order, a missing label, screen-reader output, zoom, contrast or unclear instructions. Do not include private participant content or medical information that is unnecessary to reproduce the problem.

Automated checks can detect certain barriers but cannot certify every assistive-technology experience. The operator should combine them with manual and user testing as the site changes. When participation is time-sensitive, ask the organizer for an accessible alternate route while preserving the same response meaning and privacy expectations.

Your next useful step

Read the product guides · Compare current plans · Contact Onact