When Accessibility Is an Add-On, Exclusion Is the Architecture

Series: Almost Accessible

This piece is part of the ongoing Almost Accessible series, where I name the quiet ways systems filter people out — not because anyone stood at the door and said “no,” but because the structure was built with someone else in mind. You can read more about the series on this page.

I was looking for a new home for my photography website when this idea crystallized for me — not because of a line of code, but because I met Molly.

Molly is blind. She uses a screen reader the way I use my power wheelchair. It isn’t an accessory; it’s infrastructure. It’s how she moves through the online world. When we talk about digital access for her, we’re not talking about convenience. We’re talking about whether she gets in at all.

I tend to evaluate platforms the way I approach most systems — carrying both parts of myself into the room. The photographer cares about narrative and presentation. The engineer examines architecture before she reads marketing copy. Accessibility isn’t a side value in my life. It has been my profession and my lived reality for more than three decades. I’ve assessed systems as a RESNA-certified Assistive Technology Professional and ADA architectural barriers specialist, and I’ve lived inside the consequences of design decisions that were made without me in mind. So when I explore a platform, I don’t start with fonts. I start with structure.

I looked for an accessibility statement, WCAG conformance documentation, a VPAT — anything that would indicate accessibility was built into the foundation rather than layered on after the fact. The answer, once I pressed, was polite and clear: the platform was not WCAG compliant by default. Accessibility would require a third-party add-on, and the add-on most often referenced would not integrate cleanly with the platform’s architecture.

That sequencing matters. Architecture determines what is possible. It decides whether a system supports keyboard navigation, screen readers, predictable focus order, semantic structure, and accessible interaction patterns. Those elements aren’t enhancements; they’re prerequisites. If they aren’t part of the foundation, accessibility becomes dependent on patches and promises. You can install a widget. You can add a toolbar that offers contrast controls and text resizing. What you can’t do is rewrite underlying structure with an overlay. If the code wasn’t written with semantic clarity from the start, a plugin can’t manufacture it. If interaction patterns assume sight, no toggle in the corner of the screen changes that assumption.

For Molly, that difference isn’t abstract. A site that relies on overlays may work today and fail tomorrow after an update. It may function one way in testing and another way in real life. Most users will never notice; they click, scroll, move on. She tabs, listens, interprets, recalibrates. When architecture hasn’t assumed her presence, she feels it immediately, and she has to decide whether the friction is worth the effort.

Most people who encounter that kind of friction don’t file complaints. They leave quietly. That quiet exit doesn’t register as protest; it registers as absence. Disabled users are filtered out before onboarding, before checkout, before participation ever begins. Teams interpret silence as success. A lack of complaints becomes evidence that everything is fine, while people like Molly encounter unpredictability and fatigue and choose carefully where to spend their limited margin.

More than ninety percent of high-traffic websites still fail basic accessibility standards, which isn’t surprising when accessibility is treated as something to handle later — something that can be layered in once aesthetics, performance, and scalability are settled. When it isn’t part of the original design logic, exclusion doesn’t look dramatic. It simply follows the path laid down at the beginning.

I’m not arguing against tools. Tools can support accessibility when they’re layered onto systems that were designed with inclusion in mind from the start. But tools can’t substitute for architecture. They can’t compensate for priorities that never assumed disabled users were part of the intended audience. Blueprints tend to tell the truth about who was expected to walk through the door.

When I choose where to build my work, I’m not just choosing a layout or a hosting plan. I’m choosing whether someone like Molly can arrive and move through it independently and reliably, without negotiation and without uncertainty. That decision may look technical from the outside, but from where I sit it has everything to do with who was considered at the beginning — and who was expected to adapt afterward.

Almost accessible doesn’t look broken. It just works exactly as intended, and that’s the problem.