Navigation and search
Skip links, menu disclosure, route labels, site search, focus order, and descriptive link purpose across public pages.
QA scope
What accessibility review covers first
Forms and filters
Labels, instructions, validation messages, keyboard operation, and error recovery for account, offer, registry, matching, and onboarding flows.
Evidence and review
Review cards, status badges, proof language, challenge paths, disputes, and appeal states with understandable names and text alternatives.
Private matching controls
Opportunity cards, consent dialogs, source-summary review, notification settings, privacy grants, export, and deletion with keyboard and screen-reader scenarios.
Mobile and recovery states
Responsive layouts, loading indicators, errors, and recovery controls that do not trap focus or hide the primary action.
Current practices
Controls already in place
- Every main public route exposes a skip link target at the primary content.
- Primary navigation uses a small, consistent set of descriptive destinations.
- Critical proposal and review states use visible text rather than color alone.
- Forms use programmatic labels and preserve server-side error messages after redirects.
- Support, safety, privacy, data-request, and incident routes remain available from public trust surfaces.
Known limitations
What the service does not overclaim
- A full manual screen-reader report has not yet been published for every authenticated workflow.
- Automated accessibility scores are not treated as a substitute for keyboard and assistive-technology testing.
- Some authenticated workflows require seeded account states to test every review, payment, dispute, and disclosure branch.