Accessibility statement

Our commitment

Motif is built to be usable by researchers regardless of how they read, hear, or operate a computer. We treat accessibility defects as defects, and we would rather describe a real limitation plainly than claim a conformance we have not established.

Conformance status

Motif partially conforms to Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. Partially conforms means most of the product meets the standard, and the parts that do not are listed below. Conforming to WCAG 2.2 also satisfies WCAG 2.1 and 2.0 at the same level.

The claim covers the Motif chat application and the Motif dashboard, including all pages served from their respective domains. It relies on HTML, CSS, JavaScript, WAI-ARIA and, for the two visualisations named below, the HTML canvas element. Assistive technology that does not support these will not render the product correctly.

What we do to keep it accessible

• Accessibility is measured against the running product, not reviewed from the source after the fact. Before a release the whole automated suite is run against a seeded environment: a strict jsx-a11y lint, an axe-core scan, a walk of the tab order, a measurement of every pointer target, and a check of every design token against the contrast threshold for its role. A release does not go out with a serious or critical finding open.
• Pages are scanned in light and dark themes at 320px and 1280px wide, so contrast and reflow are both covered.
• The scan is not limited to pages as they first load. Panels, dialogs, menus and drawers are opened and scanned in the state a user actually sees them in, because that is where most of the defects were.
• Keyboard operation is measured rather than assumed: an automated pass walks the whole tab order of every page and every opened panel, and checks that focus advances, follows the reading order, stays visible, and is never covered by something else.
• Panels that slide in over the page either share the space with what is behind them or block it — never both. On a wide screen a library panel narrows the page beside it, so nothing is hidden; on a narrow one it takes the full width and the content behind it is switched off, so you cannot tab into something you cannot see.
• Every pointer target is measured against the 24x24px minimum, with the spacing and inline exceptions applied as the standard defines them.
• Colour is never the only carrier of meaning: status is shown by an icon and a label as well as a hue, and links in body text are underlined rather than coloured alone.
• Contrast is checked in the states a colour actually appears in, not just as a pair of values. A colour is never laid over a faint tint of itself, white text is never revealed on hover over a surface too pale to carry it, and a control never borrows the faint border used for dividers — all three are rejected by that check, because a scanner that only looks at a page sitting still cannot see them.
• Dialogs, menus, tabs, selects and tooltips are built on WAI-ARIA compliant primitives rather than hand-rolled, so focus containment, Escape handling and focus restoration behave consistently.

Known limitations

Despite our efforts, the following are known not to be fully accessible. If one of these stops you completing your work, please tell us and we will find another way to get you the data.

Knowledge graph

The graph is drawn on a canvas, which cannot be read by a screen reader. The same entities and associations are available as text in a keyboard-navigable data grid: press T from the graph to reach Table View, and T again to return. From the graph itself, Enter opens an entity search that jumps to any node. What the grid does not reproduce is the spatial clustering the drawing conveys — which entities sit near which.

Molecular structure viewer

Protein structures are rendered on a canvas. A text description of the chains, residue counts and bound components is exposed to assistive technology, but the three-dimensional view cannot be explored non-visually.

Screen reader testing

Conformance is currently established by automated testing and code review. Structured manual passes with NVDA, JAWS and VoiceOver are planned and not yet complete, so defects that only manifest in a specific screen reader may remain.

Independent audit

This is a self-evaluation. No third-party accessibility audit has been carried out yet.

Feedback

If you hit an accessibility barrier in Motif, email hello@motif.bio with the page and what went wrong. We aim to respond within 5 business days, and we will tell you what we plan to do and when.

How this was assessed

Self-evaluation, carried out by the Motif engineering team using axe-core, eslint-plugin-jsx-a11y, measured keyboard traversal, a check that reads the accessibility tree the browser actually builds and requires every interactive node in it to carry a name, and manual code review against each WCAG 2.2 Level AA success criterion. Automated tooling detects roughly a third of accessibility barriers, which is why the limitations above name the manual testing that is still outstanding rather than implying the automated result is the whole picture.