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-motion support 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 feedback

Quality documentation

Accessibility is part of the project governance model alongside transparent methodology and version history.

Related resource →