Accessibility statement

1. Commitment

I want this website to be usable by everyone, including visitors using assistive technology, keyboard-only navigation, or who have reduced-motion preferences. The target is WCAG 2.2 AA where practical.

2. What I do

• Semantic HTML — header, nav, main, section, article, footer.
• A logical heading hierarchy on every page (one h1, then h2s, then h3s).
• A skip-to-content link as the first focusable element.
• Visible focus indicators on every interactive element.
• Keyboard-accessible navigation and mobile menu (Escape to close, focus management).
• Keyboard-accessible project filters (aria-pressed state).
• Explicit labels on every form field.
• Descriptive alt text on meaningful images; decorative images hidden from AT.
• Colour-contrast checked against WCAG AA.
• prefers-reduced-motion short-circuits every animation.
• Minimum 44×44px touch targets on mobile.
• aria-current states on the active navigation item.

3. Known limitations

The original SVG editorial project frames are decorative — they carry an aria-label describing the project they represent, but the visual composition itself is not a meaningful image. If you need a textual description of any project, the case-study narrative covers it in full.

The website audit feature is currently being migrated (see the /audit page). The migration page is itself accessible.

4. Reporting an issue

If you encounter an accessibility barrier on this site, please email work@dev-aditya.com with a description of the issue and the page it occurred on. I take accessibility reports seriously and will investigate.

5. Testing

The site is tested manually across viewports (360, 390, 768, 1024, 1280, 1440, 1920) and with keyboard-only navigation. Automated checks run via ESLint (next-eslint accessibility rules) and the build's type system. Lighthouse Accessibility is run on the production build — see docs/qa-report.md for the most recent scores.