Accessibility

Accessibility is a constraint to design against from the first sketch, not a checklist applied to a finished interface. Treating it only as an audit means discovering structural problems at the point they are most expensive to fix.

What we commit to

rhizae’s website and interface prototypes target WCAG 2.2 AA. This website runs automated checks across its routes in continuous integration, supplemented by manual review.

Automated tooling catches only part of the problem. Keyboard traversal and screen-reader review are also required. Claims of usability by a specific group require direct testing with people in that group.

How we test

Three layers, in increasing order of cost and value:

• Automated rule checks across every prerendered route
• Keyboard-only traversal of each primary task
• Assisted user review when the project scope and claims require it

The same evidence standard applies here as elsewhere in the research practice: a claim about who can use something needs to be backed by observation, not intention.

Where it shows up

Accessibility shapes data work too, not just interfaces. Color choice in a chart, the reading level of a finding, and whether a dataset can be consumed without a proprietary tool are all access questions. See Data for how that should be applied.