Skip to main content

Accessibility

Description​

Record uses WCAG 2.2 Level A and AA as its technical accessibility baseline. This matches the project's QA guidance and provides a reproducible engineering target for the Brazilian MVP. Automated checks are evidence of tested behavior, not a legal certification.

Automated Tests​

Assemble for Web includes an Accessibility validation process inside the different validation processes included as part of the Continuous Validation.

We include automated validations for:

  • Playwright: pnpm test:accessibility scans critical deployed routes with the Playwright-recommended @axe-core/playwright integration. The scan is restricted to WCAG 2.0, 2.1 and 2.2 A/AA tagged rules.

  • Lighthouse: Integrated into the Lighthouse CI validation process, we have configured the lighthouse:no-pwa assert to validate accessibility rules amongst all the other related validations done within Lighthouse as documented in main site

  • Storybook: We have integrated a component level accessibility validation using @storybook/addon-a11y, @storybook/test-runner, axe-playwright as described in the official documentation . This integration is included both in the Storybook UI deployed but also as part of our PR validations.

warning

Automated accessibility tests can detect some common accessibility problems such as missing or invalid properties. But many accessibility problems can only be discovered through manual testing. We recommend using a combination of automated testing, manual accessibility assessments, and inclusive user testing. For manual assessments, we recommend Accessibility Insights for Web, a free and open source dev tool that walks you through assessing a website for WCAG 2.1 AA coverage.

Manual Tests​

Run a deployed-route audit with:

ACCESSIBILITY_BASE_URL=https://preview.example.com \
ACCESSIBILITY_PATHS=/,/login,/signup \
pnpm test:accessibility

ACCESSIBILITY_PATHS is optional and defaults to /, /login and /signup. Authenticated routes can be tested by setting ACCESSIBILITY_STORAGE_STATE to a local Playwright storage-state file. Storage-state files can contain session credentials and must never be committed or uploaded as public artifacts.

Manual release checks​

Automation cannot evaluate every WCAG success criterion. Before release, QA must complete and retain evidence for:

  • Keyboard-only completion of sign-in, registration, profile selection, search, content details and playback, with no focus trap and a visible focus indicator.
  • Screen-reader names, roles, states, errors and live-region announcements in Brazilian Portuguese.
  • Reflow and readable content at 200% browser zoom and text-only zoom where supported.
  • Captions discovery and operation for assets that provide caption tracks.
  • Contrast, target size, orientation, reduced motion and timeout behavior.
  • VoiceOver/Safari and TalkBack/Chrome spot checks on representative devices.

Caption files, audio-description tracks, Libras content, CMS alternative text and independent legal review remain content, operations or legal responsibilities. A green automated scan does not prove full WCAG conformance.