My Approach to Digital Accessibility

The Setup

This is the framework behind my approach to digital accessibility. Digital accessibility enables people with disabilities to perceive, understand, navigate, interact with and contribute to the web. It isn’t a checklist added at the end of a project. It’s a way of designing from the start.

Why Design for Accessibility

Morally, it’s the right thing to do. It’s also a real chance to serve people the industry has historically designed past. About 1 in 6 people worldwide live with a significant disability, and more than 1 in 4 U.S. adults have some type of disability. Both reasons point the same direction. The risk of ignoring it keeps growing too: digital accessibility lawsuits now number in the thousands every year, and more laws point to the same standard.

How It’s Measured

Accessibility has to be measurable to be real. My framework uses the W3C’s Web Content Accessibility Guidelines (WCAG) to turn intent into pass-or-fail checks. Level A is the floor, Level AA is the standard that laws and courts point to, and Level AAA is the ceiling for critical flows. That way a team can tell the difference between intending to be accessible and actually being accessible.

Common Issues

The same issues recur across products: low-contrast text, missing alt text, missing form labels, empty links and buttons, and missing page language. The framework names them so teams can design against them instead of discovering them after launch.

Principles

Four principles anchor the work. Content must be Perceivable, Operable, Understandable and Robust, and every design decision is checked against them. A companion set of considerations covers what sits beyond the basics: the six areas we design for (visual, auditory, speech, motor, cognitive and mental health), and the fact that disability can be permanent, temporary or situational.

Goals

The framework sets explicit goals for users and for the teams building for them. The finish line is WCAG 2.2 Level AA at minimum. For users, every person can complete every core task with any device and any assistive technology. For teams, that means shared standards, clear owners and fewer surprises late in a project.

My Approach

This is where the framework becomes a working method, built into the design process rather than audited in afterward. Every discipline owns a piece of it: user research, content strategy, information architecture, interaction design, visual design and engineering. Every phase has an accessibility deliverable, from recruiting participants with disabilities in discovery to re-testing with every release. Verification runs in four layers: automated scans, manual checks, assistive technology testing, and sessions with people who use assistive tech every day.

Project Principles

Finally, project principles translate the framework to the level of a single engagement. They are: execute the fundamentals; build in clarity, logic and priority; use color with purpose; get content order and hierarchy right; and design for assistive technology. Every project starts with accessibility as a premise, not a patch.

What I Led

I defined the framework and put it to work at Aura across four surfaces: iOS, Android, the web product and the marketing site. I set the standard, assigned ownership to every discipline and made accessibility a deliverable in each phase of the work, not a review at the end.

What We Delivered

A repeatable practice with a clear finish line of WCAG 2.2 AA at minimum. Behind it sat a 100+ point standards checklist, annotated design specs and engineering documentation, so the build matched the design on every platform. From there it became the practice I bring to every project.