Accessibility Engineering

WCAG 2.1 / 2.2 AA on products built for people with disabilities — audited, automated, and then actually fixed.

Client: Codesage · EnAble India
Role: Accessibility lead — audit, automation and remediation
Period: Apr 2026 — Present

WCAG 2.1 / 2.2 conformance target: AAWCAG 2.1 / 2.2 conformance target
narrowest supported viewport: 320pxnarrowest supported viewport
zoom reflow verified: 400%zoom reflow verified
products audited (MEL, DISH): 2products audited (MEL, DISH)

Overview

Practice · Automation framework + in-product remediation

When the people using your product are blind, low-vision, deaf, or navigating with one hand on a switch device, accessibility stops being a compliance checkbox and becomes the feature. I run this as three connected pieces: an automated scan framework, a manual audit discipline that catches what scanners cannot, and the remediation work in the product itself.

The accessibility pipeline — automated scans catch the mechanical failures, manual passes catch the ones that matter most.

The automation layer

A Playwright and TypeScript framework built around axe-core, running against staging and production on demand.

Axe-core scans per route, asserted at WCAG 2.0 / 2.1 Level A and AA
Dedicated keyboard specs: tab order, focus trapping, and OTP-field navigation
HTML and JSON reporters so a run is both human-readable and machine-diffable
Environment switching between stage and production from one config
A second, custom Node checker that emits per-module Excel and HTML reports for stakeholders who do not read test output
In the product itself: eslint-plugin-jsx-a11y in CI, @axe-core/react in development, and a dedicated Playwright a11y project

What automation cannot catch

Axe-core will tell you an input has no label. It will not tell you that after a user activates “View All” and comes back, focus has been dumped at the top of the document and they have lost their place. Those failures are the ones that make a product unusable, and they only surface under manual keyboard and screen-reader passes.

Focus continuity — every dashboard link needs its own restore target when the user comes back
Focus round-trips through “View All” and detail pages, including when the restore target sits inside a collapsed section that must be expanded first
Live-region announcements for values that change without a navigation, such as a statistics total
History-aware Back behaviour, so Back does what the user meant rather than what the router defaulted to
Table semantics — headers, scope and captions a screen reader can actually navigate
Landing focus on the page, not the shell, when a tab opens

Remediation, not just reporting

I did not hand the findings over and move on. The accessibility fixes across the dashboard, Master Data, Centres, Reports, Support Requests and Notifications are in my own merged commits — focus order, table semantics, announcement regions, and the restore logic that makes them hold.

Responsive coverage

Every breakpoint from 320px to 1920px verified per module, with evidence captured
Reflow verified at 200% and 400% zoom — no horizontal scrolling, no clipped content
Longer Hindi and Kannada strings verified against tight layouts
Mobile card layouts introduced where wide tables could not reflow honestly

Stack

Scanning

axe-core
@axe-core/playwright
@axe-core/react
eslint-plugin-jsx-a11y

Framework

Playwright
TypeScript
HTML + JSON reporters
Custom Node checker

Manual

Screen readers
Keyboard-only passes
Zoom reflow
Colour-contrast verification

Standards

WCAG 2.1 AA
WCAG 2.2 AA
POUR principles
Compliance checklists