Accessibility & quality
Designed around WCAG 2.2 AA practices.
Accessibility is treated as a product requirement, not a decorative statement. The interface is designed for keyboard navigation, visible focus, sufficient contrast, responsive reflow, readable forms, and reduced-motion preferences.
Implemented in the current build
- Skip-to-content navigation and semantic landmarks.
- Persistent labels for form controls and accessible names for buttons.
- Visible keyboard focus and minimum 44px interactive targets.
- Color choices designed to exceed WCAG AA contrast for normal text.
- Responsive layouts that reflow at narrow widths without horizontal scrolling.
prefers-reduced-motionsupport for transitions and reveal effects.- Status regions for form and workflow feedback.
- No core information conveyed through color alone.
Build-time verification and deployed-domain validation
Build-time checks confirm local-link integrity, unique IDs, image alt attributes, JavaScript/PHP syntax, CSS structure, native keyboard-focusable controls, and reduced-motion support. Formal accessibility certification is not claimed. After deployment, the live site still requires keyboard-only, NVDA + Chrome, VoiceOver + Safari, 200%/400% zoom, forced-colors/high-contrast, and an automated axe/WAVE-style scan because hosting scripts and integrations can change results.
Rendered-browser screenshot automation was attempted in the current build environment but Chromium did not complete because of the container runtime/DBus limitation; this is not treated as visual accessibility validation.
Report an accessibility issue
Use the project feedback form on the About page and identify the page, control, device/browser, and observed barrier.
Project feedbackQuality documentation
Accessibility is part of the project governance model alongside transparent methodology and version history.
Related resource →