65 lines
3.3 KiB
Markdown
65 lines
3.3 KiB
Markdown
# Campaign Accessibility Review
|
|
|
|
The Campaign WebUI uses Core's semantic `Button`, `Dialog`, `DataGrid`, form,
|
|
alert, and segmented-control components. Core owns focus trapping, focus return,
|
|
Escape handling, labels, disabled state, and keyboard behavior for those shared
|
|
primitives.
|
|
|
|
## Repeatable review matrix
|
|
|
|
Run this matrix for Campaign overview, wizard, sender and recipients,
|
|
attachments, template editing, review and send, operator queue, and reports:
|
|
|
|
1. Navigate all actions with Tab and Shift+Tab; focus must remain visible and
|
|
follow the visual reading order.
|
|
2. Activate buttons and links with Enter, and native buttons with Space.
|
|
3. Open every dialog, verify initial focus remains within it, close with Escape,
|
|
and verify focus returns to the opener.
|
|
4. Use DataGrid sorting, filtering, pagination, row selection, and action menus
|
|
without a pointer.
|
|
5. At 200 percent browser zoom and a 320 CSS-pixel viewport, verify that content
|
|
reflows or scrolls without hiding actions.
|
|
6. With reduced motion enabled, verify that workflow state does not depend on
|
|
animation.
|
|
7. With a screen reader, verify page headings, field labels, validation errors,
|
|
workflow states, message navigation, and attachment evidence.
|
|
|
|
## Automated structural guard
|
|
|
|
`npm run test:accessibility-contract` rejects non-semantic click handlers,
|
|
unlabelled icon-only buttons in the message preview, and Campaign-local modal
|
|
implementations that bypass Core's `Dialog`. It complements rather than replaces
|
|
browser and assistive-technology testing.
|
|
|
|
The guard also verifies that Campaign retains narrow-viewport layouts, visible
|
|
keyboard focus for domain-specific controls, and an explicit reduced-motion
|
|
override. Shared dialog focus trapping and restoration are tested in Core;
|
|
Campaign tests verify that overlays continue to use that shared primitive.
|
|
|
|
## Release evidence
|
|
|
|
The feature implementation can be closed once the structural contract, shared
|
|
Core component tests, TypeScript graph, and representative responsive overlay
|
|
tests pass. The seven-step matrix above remains a release-candidate checklist:
|
|
it must be repeated for the exact browser, language packages, theme, density,
|
|
and assistive-technology combination being certified. Closing the implementation
|
|
ticket does not make a general WCAG-conformance claim for future releases.
|
|
|
|
Implementation closure evidence recorded on 2026-08-03 used headless Chromium
|
|
against the configured development system. It covered all 13 Campaign routes at
|
|
1440 CSS pixels, the list, overview, recipients, and review routes at 320 CSS
|
|
pixels, reduced-motion rendering, semantic accessibility-tree snapshots, HTTP
|
|
500/page-error capture, and 42 sampled Tab stops across desktop and narrow
|
|
Review & Send. The run found no unnamed interactive controls, hidden focus,
|
|
page-level horizontal overflow, titlebar overlap, or unhandled runtime errors.
|
|
Representative list, overview, review, and narrow-review screenshots were also
|
|
inspected. This is implementation evidence; release certification still uses
|
|
the complete matrix above with the selected screen reader and browser versions.
|
|
|
|
## Known boundary
|
|
|
|
Translation keys may be visible in source because Core resolves them at runtime.
|
|
The review must use a built application with current language packages. WCAG
|
|
conformance is a release-level claim and still requires a bounded manual audit
|
|
of the release candidate.
|