Small Wins, Big Change: Incremental Accessibility on an Active Codebase

#a11y #designsystem #frontend #webdev

Accessibility is often framed as a massive, scary project: audit everything, rip out the design system, ship a new accessible theme, repeat. That's demoralizing and rarely realistic for teams shipping features. In practice, accessibility improves fastest when it's framed as a steady cadence of small, deliberate fixes - the sort of work you can ship with a single PR. This article lays out a pragmatic, repeatable approach: how to find the most valuable fixes, how to use tools and agent skills to automate the boring parts, and how to batch system-level problems without blocking day-to-day product work. I'll show the workflow we use on a pre-launch short-form news project and give templates you can use tomorrow.

On Newdle - the small, evidence-first news startup I'm rockin' at - we build tools that prioritize evidence over noise. Newdle's mission is to break barriers between headlines and meaningful context, so accessibility can't be a one-off project. It has to be part of how we ship, test, and iterate. The practices below reflect work we've used at Newdle to keep shipping, keep the UI usable, and keep the product grounded in research.

Why incremental wins matter

Rewrites are expensive: lost context, regressions, and long timelines that kill momentum. Incremental work minimizes risk, produces measurable impact, and creates psychological momentum. Small fixes are testable and reversible - easier to measure, easier to defend to stakeholders. Real teams ship features; choose signals that make accessibility part of shipping, not a separate project.

The audit mindset: what to look for

Per-feature checklist: keyboard support, focus order & visible focus indicators, semantic markup (buttons/links/form controls), labels & ARIA where appropriate, announcements for dynamic content, contrast checks for text and UI elements.

Prioritization strategy: impact x frequency. Fixes that help many users and appear frequently (forms, nav) first. Low effort, high impact is the sweet spot.

Quick triage: run Lighthouse/Pa11y/axe on a page, then do a 5-10 minute manual keyboard + screen-reader check to catch the high-risk items automated scans miss.

Tools & AI that actually help

Automated: Lighthouse, Pa11y, axe-core, Storybook a11y addon, eslint-plugin-jsx-a11y.
Storybook as your sandbox: create stories for each UI component and add accessibility checks so every component ships with a testable, documented behavior.
Agent skills & automation: use agent workflows to scan PR diffs, annotate PRs with remediation suggestions, and generate accessible attribute suggestions for simple cases. (Hat tip: Addy Osmani's agent-skills repo.)
Linting and CI: fail builds on regressions for critical surfaces, but be pragmatic: start with warnings and move to enforced rules after a grace period.
Validate your markup. Funfact: valid HTML is more accessible than invalid markup. If you're nesting clickable elements within clickable elements - or use invalid attributes - ya got trouble. Right here in River City!

A repeatable workflow (practical checklist)

Pick a bounded surface to own (modal, nav, form field group).
Run automated tools -> note obvious failures.
Do a quick manual check: keyboard nav + screen reader.
Implement fixes in component(s) and Storybook stories.
Add unit/visual/accessibility tests where possible.
Re-run automated tests, run Pa11y/Lighthouse on staging.
Verify in production (or canary) with a small rollout.
Document the change and add a PR checklist item to prevent regression.

Handling cross-cutting/systemic problems

Identify tokens/vars used across the app (color tokens, spacing, focus color). Strategy:

Tag them as cross-cutting in your backlog.
Batch remediation into a scoped sprint or design-system PR.
Add automated checks that prevent tokens from being reintroduced with bad values.

Team enablement & culture

Short workshops: 1-2 hour sessions where engineers pair up and run keyboard + screen-reader checks on components.
PR checklist: simple yes/no items that reviewers must verify (keyboard, labels, focus states).
Designers: include contrast checks in mock reviews and expose tokens clearly.
Product: add accessibility acceptance criteria to stories.
Celebrate wins: publish a short changelog of accessibility improvements to the team each week.

Screen-reader testing (practical guide)

Why SR testing matters: bots miss ordering, context, and live region timing.
Basic walkthroughs for the team: NVDA (Windows) and VoiceOver (macOS) quick scripts: navigate with keyboard only, test live regions, verify form error announcements and labels.
Build reproducible test notes for frequently used flows.

Measuring impact

Metrics: number of accessibility bugs, mean time to fix, keyboard success rate for key flows, reduction in support tickets tied to a11y issues.
Instrumentation: add tags to error logs or analytics events when assistive tech is detected; use surveys for qualitative feedback.
Communicate wins: short monthly reports to stakeholders showing deficit -> remediation -> improvement.

Roadmap & templates (appendix)

PR checklist template and Storybook test examples.
90-day sample plan: per-feature sprints + one token remediation sprint (see below).

90-day plan (summary)

Cadence: 2-week sprints (6 sprints, ~90 days). One sprint is dedicated to token remediation.
Prework (week 0): baseline Pa11y/Lighthouse audit, Storybook + a11y addons, eslint a11y linting in CI, team workshop on screen readers.
Sprint 1 (weeks 1-2): primary nav & header - keyboard flow, visible focus, labels, Storybook stories and a11y tests.
Sprint 2 (weeks 3-4): search & content cards - accessible search input, announcements, semantic card markup, Storybook stories.
Sprint 3 (weeks 5-6): article reader - heading hierarchy, skip links, media captions and alt text, reading order.
Sprint 4 (weeks 7-8): token remediation sprint - inventory tokens, migrate bad color/focus tokens, add token-lint to CI, ship design-system PR with visual diffs.
Sprint 5 (weeks 9-10): forms & error handling - labels, aria-invalid, error announcements, focus management.
Sprint 6 (weeks 11-12): polish, telemetry, and handoff - ship remaining fixes, add telemetry for a11y regressions, document playbook and handoff.
Acceptance & reporting: per-sprint acceptance criteria include Storybook stories, Pa11y zero critical failures for changed surfaces, manual SR checks for key flows. Weekly report: failures opened/closed, Pa11y counts vs baseline. End-of-90-days: one-page impact summary.

Conclusion

Accessibility becomes achievable when you stop treating it as a single mountain to climb and instead collect small, repeatable summits. The combination of automated tooling, Storybook-first components, pragmatic batching of system problems, and team training compounds fast. Ship the small wins - your users will notice, your team will build momentum, and the codebase you respect will get steadily better.