Accessibility training module

Purpose

This is the role-specific accessibility training module for personnel who design, build, review, test, approve, or support HiringCoachAI user-facing interfaces, accessibility statements, VPAT / ACR materials, or accessibility issue remediation.

Complete this module before taking accessibility or user-interface delivery responsibilities and annually while those responsibilities remain assigned.

1. Maintain Current Standards Knowledge

Personnel assigned accessibility or UI responsibilities must stay current on:

• WCAG 2.1 Level AA as HiringCoachAI's current verified conformance level and the customer-contract and HECVAT baseline.
• WCAG 2.2 Level AA as the stated forward-looking target.
• Section 508 and EN 301 549 concepts when responding to institutional customers.
• WAI-ARIA authoring practices for custom controls.
• Common accessibility risks in modern web applications, including keyboard traps, missing names, poor focus order, insufficient contrast, missing status announcements, and motion sensitivity.

No external accessibility certification is currently required. If a customer requires certified personnel or third-party testing, that requirement is handled through the enterprise review process.

2. Build Accessibility Into Design And Development

Accessibility is not a post-launch overlay or alternate mode. Personnel assigned UI work must:

• Use semantic HTML and landmarks where practical.
• Provide accessible names for links, buttons, form controls, and non-decorative images.
• Maintain visible focus indicators and logical tab order.
• Support keyboard operation for interactive controls.
• Avoid color-only meaning.
• Preserve 320 px reflow and 200% text resizing.
• Respect prefers-reduced-motion.
• Use ARIA only when semantic HTML is insufficient, and verify ARIA roles, states, and properties.

3. Verify Accessibility

For material UI changes, assigned personnel use the applicable verification methods documented in secure development lifecycle and the accessibility evidence set:

• npm run lint:a11y for jsx-a11y coverage.
• npm run test:a11y for jest-axe coverage.
• npm run test:playwright:a11y for Playwright + Axe coverage.
• Keyboard-only walkthroughs for core flows.
• Focus-management checks for dialogs, drawers, modals, and custom components.
• Accessibility-tree inspection where names, roles, landmarks, or headings are in doubt.
• 320 px reflow checks for responsive pages.

Automated tools do not prove accessibility alone. Manual review remains required for keyboard flow, focus order, meaningful labels, status announcements, and user-flow context.

4. Triage And Remediate Accessibility Findings

Accessibility findings are tracked in the accessibility remediation log or an equivalent change record. Each finding should identify:

• Affected route or component.
• WCAG criterion or accessibility risk.
• Severity and user impact.
• Owner.
• Status.
• Evidence of closure.

Critical blockers are prioritized under the public accessibility-statement remediation commitments.

5. Maintain Customer-Facing Accessibility Materials

Personnel assigned accessibility ownership must keep the following materials aligned with actual implementation:

• Public accessibility statement at /accessibility.
• Public ACR / VPAT at /vpat.
• Internal verification snapshot and evidence checklist.
• Accessibility remediation log.
• HECVAT accessibility answers.

Do not represent internal self-assessment as third-party audit, certification, or external attestation.

Acknowledgment

By acknowledging this module in /admin/onboarding, I confirm that I completed the role-specific accessibility training, understand the expectations above, and will maintain current accessibility knowledge for any HiringCoachAI accessibility or user-interface responsibilities assigned to me.