Accessibility

Last updated: July 2026

I am committed to engineering atulchoudhary.com as an inclusive digital platform. Accessibility (a11y) is not treated as an afterthought or a compliance checklist; it is a fundamental architectural requirement built into the frontend infrastructure from day one.

1. Target Conformance Level

The UI component library and core layout target strict conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standard. The design system is systematically audited to ensure it exceeds baseline functional requirements for assistive technologies.

2. Engineered Accessibility Features

The following technical implementations are strictly enforced across the codebase:

• Command Palette Navigation: Complex navigation and AI interactions are accessible entirely via keyboard shortcuts (`Ctrl+K` / `Cmd+K`), ensuring rapid, mouse-free traversal of the site.
• Semantic DOM Structure: Strict adherence to HTML5 landmark regions (`nav`, `main`, `aside`, `footer`) and hierarchical heading structures (h1–h6) to construct a logical DOM tree for screen readers.
• Assistive Tech Hooks: WAI-ARIA 1.2 attributes, hidden screen-reader (`sr-only`) utility classes, and descriptive `aria-label` tags are applied to all interactive and stateful SVG elements.
• Measured Color Contrast: The text ramp is defined as discrete design tokens in globals.css. The Playwright suite asserts the numeric contrast ratio of each token against the base background, and Lighthouse asserts a color-contrast score of 1.0 on the primary routes. Because several surfaces are translucent, contrast is verified on the composited result rather than assumed from the token value.
• Reduced Motion Fallbacks: framer-motion is configured globally with reducedMotion="user", and the Lenis smooth-scroll layer disables wheel interpolation when prefers-reduced-motion is set, so scroll falls back to native behaviour.
• Focus Management: Custom, high-visibility focus rings are managed globally to ensure clear visual feedback for keyboard-driven `Tab` navigation.

3. Testing & CI/CD Validation

Accessibility regressions are blocked in CI rather than reviewed by hand. The following gates run on every push and pull request against the production build:

• axe-core (npm run test:a11y): Runs in Playwright against the home, projects, blog, schedule, contact, and status routes, failing on serious and critical violations, plus numeric contrast assertions for the text ramp.
• Lighthouse CI (npm run lighthouse): Asserts category scores, Core Web Vitals, and individual audits including heading-order, color-contrast, image-alt, label, link-name, and button-name. Current measured scores on those routes are 0.96–0.98 performance, 1.00 accessibility, and 1.00 SEO.
• Responsive regression suite: A viewport matrix from 320px upward asserts no horizontal overflow on every primary route.
• Manual Tabbing: Keyboard navigation is verified by hand, with particular attention to focus containment inside modals and the Command Palette.
• Screen Reader Validation: Periodic audits utilizing NVDA (Windows) and VoiceOver (macOS).

4. Edge Cases & Limitations

While the core infrastructure is highly accessible, certain edge cases exist:

• Interactive Code Visualizations: Some WebGL/Canvas elements used to demonstrate complex ML architectures may lack full keyboard interrogability.
• Third-Party Iframes: Embedded content from external platforms (e.g., Kaggle notebooks, YouTube) is constrained by the respective vendor's accessibility implementation.

Feedback & Support

If you encounter an accessibility barrier or experience degraded performance while utilizing assistive technology, please open an issue with me directly at dev@atulchoudhary.com. I aim to triage and push patches for critical accessibility bugs within 48 hours.