Accessibility is Non-Negotiable

Build for everyone from the start. Accessibility is a baseline, not a bonus.

Accessibility is treated as a core requirement from the first line of code, not retrofitted before release.

Semantic HTML is used to provide meaningful structure for assistive technologies.
All interactive elements are fully keyboard navigable.
Screen reader support is verified as part of development, not deferred to a separate phase.
WCAG 2.1 AA compliance is the minimum target for all user-facing work.
Colour contrast, focus indicators, and text sizing meet documented standards.
Accessibility considerations are included in design reviews and component specifications.

Retrofitting accessibility is expensive, error-prone, and often incomplete.

Users who rely on assistive technologies are excluded when accessibility is an afterthought.
Legal and regulatory obligations (such as the Equality Act and EN 301 549) require accessible digital services.
Accessible design often improves usability for all users, not just those with specific needs.
Addressing accessibility late in delivery increases rework and delays releases.
Teams that build accessibly from the start develop stronger front-end fundamentals overall.

Use semantic HTML elements (headings, landmarks, lists, buttons) rather than generic containers with ARIA overrides.
Include keyboard navigation and focus management in component acceptance criteria.
Run automated accessibility checks (such as axe or Lighthouse) as part of the CI pipeline.
Perform manual screen reader testing on key user journeys during development.
Document accessibility requirements alongside functional requirements in stories.
Use sufficient colour contrast ratios and do not rely on colour alone to convey meaning.
Include accessibility in code review checklists.
Conduct periodic accessibility audits against WCAG 2.1 AA.

A project meets this principle when:

All user-facing components use semantic HTML and are keyboard accessible.
Automated accessibility checks run in the pipeline with no unresolved critical issues.
Key user journeys have been verified with at least one screen reader.
WCAG 2.1 AA compliance is demonstrated and documented.
Accessibility requirements are visible in story acceptance criteria, not treated as a separate workstream.
Accessibility regressions are caught before release, not reported by users.