Access is part of the work.

Accessibility is treated as an operating requirement, not a finishing step. Clear language, logical structure, keyboard access, visible focus, readable contrast, responsive reflow, useful image alternatives, restrained motion, and understandable form states all work together.

The following practices are implemented in the current code and reviewed through route-level browser and automated accessibility checks.

• Semantic landmarks, one H1 per page, skip navigation, labeled navigation, keyboard-operable controls, and visible focus treatment.
• Responsive layouts through 320 pixels, descriptive or decorative image handling, reduced-motion support, labeled disabled-form explanation, and no color-only state communication.
• Automated Axe checks run across public routes; focused browser checks cover navigation, accordions, search, and narrow-viewport overflow where those patterns appear.

This page reflects the latest internal review, not a guarantee that no barrier exists. The site still needs ongoing testing with people who use assistive technologies and with future services before any public launch claim could be considered.

• No monitored accessibility feedback channel is active today. A formal channel requires a monitored destination, clear response ownership, a documented handling process, privacy alignment, and accessible confirmation behavior.
• Accessibility review is required when new pages, shared components, forms, media, diagrams, or third-party services are introduced.
• Release checks include keyboard and focus review, contrast and responsive review, screen-reader spot checks, reduced-motion review, automated audit, and manual content review.