An accessibility programme: WCAG 2.2 AA checked in the browser tests, and an audit of every page #41

New issue

Closed

opened 2026-09-05 18:10:34 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-05 18:10:34 +00:00

Owner

Why

Postulo now states inclusion as a mission: usable by everyone, at its fullest, including people with disabilities. Much of the interface already behaves (server-rendered HTML that works with scripts off, keyboard-operable menus, aria-hidden icons with labels where an icon stands alone, live regions on the tables, aria-sort on headers) but none of it is checked, and what is not checked drifts.

Shape

Automated checks in the browser tests. Inject axe-core (vendored under static/js/vendor/ like htmx, or loaded from node_modules in the test only) into every page the Playwright suite visits and fail on any violation at WCAG 2.2 level A and AA. Add the pages the critical path does not visit: settings, server settings, insights, the interview form, the tables with filters open, the account menu, sign-in and sign-up.
Keyboard audit, by hand, once: every control reachable in a sensible order, focus visible everywhere (outline-none grep as a start), no keyboard traps in the <details> menus, Escape closes what opened, a skip link to the main content.
Screen-reader audit with NVDA and VoiceOver on the critical path: the board's status select announces what it will do, the table's live count is heard after a filter, the timeline reads in order, form errors are associated with their fields (aria-describedby), and the theme switch says which theme it will apply.
Colour and motion. Contrast at 4.5:1 for text in both themes (the ink and brand palettes checked, not assumed); nothing conveyed by colour alone (the status badge already carries its label; check the quiet and interview markers); respect prefers-reduced-motion in the little animation there is.
Forms: every input has a label (not a placeholder standing in for one), required fields are marked in text as well as with an asterisk, and error messages say what to do.
Documents: the PDFs Postulo renders should be tagged PDFs where WeasyPrint allows, so a CV a blind person produces is one a blind recruiter can read.
An accessibility statement in the wiki: what is covered, what is known not to be, how to report a barrier, and the rule that a feature somebody cannot use is a bug, filed with the accessibility label.

Classification

Enhancement, and a standing commitment. 1, 5 and 7 close this issue; 2 to 4 are audits whose findings become bugs; 6 is its own issue if WeasyPrint's tagging turns out to be involved.

## Why Postulo now states inclusion as a mission: usable by everyone, at its fullest, including people with disabilities. Much of the interface already behaves (server-rendered HTML that works with scripts off, keyboard-operable menus, `aria-hidden` icons with labels where an icon stands alone, live regions on the tables, `aria-sort` on headers) but none of it is *checked*, and what is not checked drifts. ## Shape 1. **Automated checks in the browser tests.** Inject `axe-core` (vendored under `static/js/vendor/` like htmx, or loaded from `node_modules` in the test only) into every page the Playwright suite visits and fail on any violation at WCAG 2.2 level A and AA. Add the pages the critical path does not visit: settings, server settings, insights, the interview form, the tables with filters open, the account menu, sign-in and sign-up. 2. **Keyboard audit**, by hand, once: every control reachable in a sensible order, focus visible everywhere (`outline-none` grep as a start), no keyboard traps in the `<details>` menus, Escape closes what opened, a skip link to the main content. 3. **Screen-reader audit** with NVDA and VoiceOver on the critical path: the board's status select announces what it will do, the table's live count is heard after a filter, the timeline reads in order, form errors are associated with their fields (`aria-describedby`), and the theme switch says which theme it will apply. 4. **Colour and motion.** Contrast at 4.5:1 for text in both themes (the `ink` and `brand` palettes checked, not assumed); nothing conveyed by colour alone (the status badge already carries its label; check the quiet and interview markers); respect `prefers-reduced-motion` in the little animation there is. 5. **Forms**: every input has a label (not a placeholder standing in for one), required fields are marked in text as well as with an asterisk, and error messages say what to do. 6. **Documents**: the PDFs Postulo renders should be tagged PDFs where WeasyPrint allows, so a CV a blind person produces is one a blind recruiter can read. 7. **An accessibility statement** in the wiki: what is covered, what is known not to be, how to report a barrier, and the rule that a feature somebody cannot use is a bug, filed with the `accessibility` label. ## Classification Enhancement, and a standing commitment. 1, 5 and 7 close this issue; 2 to 4 are audits whose findings become bugs; 6 is its own issue if WeasyPrint's tagging turns out to be involved.

tiagoagueda added this to the 0.2.0 milestone

2026-09-05 18:10:34 +00:00

tiagoagueda added the

accessibility

enhancement

tier

labels

2026-09-05 18:10:34 +00:00

tiagoagueda referenced this issue from a commit

2026-09-05 18:11:13 +00:00

State two more commitments: security, and usability for everyone

tiagoagueda referenced this issue from a commit