Accessibility as a Default, Not a Ticket

On almost every project I've joined midway, accessibility lived in the same place: a ticket near the bottom of the backlog, labelled something like "A11y improvements," estimated vaguely and deprioritized repeatedly. Sometimes there was an audit report attached, full of issues nobody had time to fix.

That approach almost guarantees failure. When accessibility is a separate task, it competes with features for priority — and features usually win. The result is a product that excludes people by default and promises to include them later.

I've come to think about accessibility differently: not as a task, but as a property of the system. If the foundations are accessible, most of the product becomes accessible without anyone having to remember to do it.

Who we're designing for#

It's easy to think of accessibility as serving a small group. It isn't. Disabilities can be permanent, temporary, or situational. Someone with a broken arm, someone holding a baby, someone using a phone in bright sunlight, someone with an ear infection, someone who's exhausted after a night shift — all of them benefit from the same design decisions that support people with permanent disabilities.

Add aging populations, people with varying levels of digital literacy, and people using older devices or slow connections, and "accessibility" starts to look a lot like "usability for everyone in real conditions."

That reframing helps in stakeholder conversations. It's not a compliance cost for a niche audience. It's quality.

Start with the tokens#

The most effective accessibility work I do happens at the foundation level, in the design system.

Color contrast#

If every color pairing in the system meets contrast requirements, every screen built from it starts in a good place. I define text and surface color tokens in pairs and check them against contrast standards before anyone designs a screen. A designer picking "text secondary on surface muted" doesn't need to check contrast; the system already did.

I also avoid using color alone to convey meaning. Errors get icons and text, not just red borders. Status badges include labels, not just colored dots. Charts use patterns or direct labels in addition to color.

Typography#

Type scales should support readability: comfortable body sizes, adequate line height, and sensible line lengths. Text should be able to scale up without breaking layouts. I test key screens with larger system font settings to make sure nothing overlaps or gets cut off.

Spacing and targets#

Touch targets need to be large enough to hit reliably. Building minimum target sizes into components — buttons, icon buttons, list items, form controls — means nobody accidentally ships a tiny tap area.

Accessible components#

Components are where most accessibility issues either get solved once or repeated everywhere.

For each component in a system, I document:

Focus states that are clearly visible, not removed for aesthetics.
Keyboard behavior — how the component is reached, operated, and exited using only a keyboard.
Labels — what a screen reader should announce, including for icon-only buttons.
States — how disabled, selected, expanded, and error states are communicated beyond visual changes.
Motion — whether animations respect reduced-motion preferences.

When this documentation lives with the component, developers implement it correctly the first time. When it doesn't, every developer has to rediscover it, and most won't.

Patterns that often go wrong#

Some interface patterns are especially prone to accessibility issues. These deserve extra attention:

Modals — focus must move into the modal, stay there while it's open, and return to the trigger when it closes.
Custom dropdowns and selects — native controls are accessible by default; custom ones need careful work to match.
Forms — every input needs a visible label, errors need to be clearly associated with their fields, and required fields should be indicated in text.
Carousels — auto-advancing content is hard for many people to use; provide controls and avoid auto-play where possible.
Toasts and notifications — temporary messages can disappear before someone has read them; important information shouldn't rely on them alone.
Data tables — need proper structure so screen reader users can navigate rows and columns meaningfully.

Writing is accessibility#

Clear writing is one of the most underrated accessibility tools. Plain language helps people with cognitive disabilities, people reading in a second language, people under stress, and honestly everyone else too.

Some habits I try to follow:

Use short sentences and common words.
Put the most important information first.
Make link and button text meaningful on its own — "Download invoice" rather than "Click here."
Avoid jargon, or explain it when it's unavoidable.
Write error messages that explain how to fix the problem.

In healthcare products especially, clarity can be the difference between someone managing their care confidently and someone giving up.

Testing with real assistive technology#

Automated tools are useful but limited. They can catch missing labels and low contrast, but they can't tell you whether a flow actually makes sense with a screen reader.

I try to include some manual testing in every significant feature:

Navigate the main flow using only a keyboard.
Use a screen reader to complete a key task.
Zoom the interface and increase text size.
Turn on reduced motion and high-contrast settings.
Try the flow on an older, slower device.

It doesn't take long, and it reliably reveals issues that would otherwise ship. Where possible, testing with people who use assistive technology daily is even better — they find things no checklist would.

Making it stick in teams#

The cultural side matters as much as the technical side. A few things have helped accessibility become a habit rather than an afterthought:

Include it in the definition of done. A feature isn't finished until it meets the team's accessibility baseline.
Annotate designs. Focus order, labels, and heading structure noted directly in handoff files.
Share real stories. Watching someone struggle with an inaccessible flow changes minds faster than any guideline.
Celebrate fixes. Make accessibility improvements visible, not invisible maintenance.
Start small. A team that fixes the top five issues consistently will outperform a team that has a perfect plan and no time to execute it.

The default matters#

The most powerful thing about building accessibility into the system is that it changes the default. Instead of every designer and developer having to remember to do the right thing, the right thing is what happens when they use the tools they already have.

That's the shift I try to make on every project: from accessibility as a ticket at the bottom of the backlog to accessibility as a property of the foundations. When the defaults are inclusive, the product is inclusive — not because someone remembered, but because it would take extra effort to make it otherwise.