Accessibility is component behavior
A visible, testable contract.
Gummy UI targets WCAG 2.2 AA for the public website and shipped component states. Automated checks support—but never replace—keyboard, screen-reader, zoom, contrast, touch, RTL, and reduced-motion review.
What every component must provide
- Native semantics first, with Base UI where managed focus or composite behavior is required.
- Visible labels, instructions, validation, and non-colour-only state cues.
- Complete keyboard paths, visible focus, 44px touch targets where applicable, and focus restoration.
- Light and dark contrast, 200% zoom/reflow, RTL, and reduced-motion behavior.
- Automated axe coverage plus behavior tests against real rendered source.
Current evidence
The local catalogue test suite covers all nine dependency groups, including representative axe checks, native relationships, focus movement, controlled state, RTL keys, and clean registry installation. Manual browser and assistive-technology smoke tests are recorded as a release gate rather than represented as already complete.
How to review an installed component
Begin with the task a person must complete, not the component's appearance. Confirm that names, roles, descriptions, headings, labels and error relationships still make sense when the component is read in document order. Then complete every action with a keyboard, checking focus entry, movement, activation, dismissal and restoration. Managed composites such as menus and tabs should follow their documented key contract; ordinary controls should retain native browser behavior.
Repeat the task at 200% zoom and a narrow viewport, in light and dark themes, with a right-to-left boundary, and with reduced motion enabled. Check that content reflows without hiding actions, focus remains visible, status is not conveyed by colour alone, and animation is removed or simplified where motion is not essential.
Automated tests can find missing names, invalid relationships and some contrast failures, but they cannot prove that instructions are understandable or that a workflow is usable. Record the browser, assistive technology, viewport and exact task with each manual result so a future release can reproduce it.
Report a barrier
Email support@kreydlabs.com with the page, component or task, what happened, and the browser or assistive technology involved. We aim to send a first reply within two UK business days. This is a target, not an SLA.