Designing for Agency: Why Accessibility is an Engineering Core, Not a Feature

Accessibility is often treated as a peripheral compliance task, but this is a fundamental engineering error. By failing to design for diverse input methods like switch access, eye gaze, or voice, developers bake rigid assumptions into their software architecture. This conversation with Owen McGirr shows that accessibility is not a layer to be added later; it is a measure of whether a product functions at all. When developers ignore these constraints, they create systems that are fragile, difficult to debug, and exclusionary. The competitive advantage lies in building for accessibility from the start, as it forces a level of structural clarity and robust error handling that benefits every user. For engineers, shifting this mindset is the difference between building a tool that works and one that assumes a narrow user profile.

The Hidden Cost of Standard Assumptions

Most software development assumes a default user: someone with fine motor control, rapid reaction times, and the ability to interact with a mouse or direct touch. McGirr, an AAC user and developer of SayIt! and Switchify, argues that these assumptions remain invisible until they break a user workflow. When an interface relies on hover states, tiny tap targets, or time-sensitive dialogues, it creates a system that is inaccessible to anyone outside that narrow profile.

The downstream effect of these assumptions is a lack of resilience. A dialogue that times out because it assumes a specific speed of cognition or motor response does not just annoy a user. It acts as a hard barrier to participation.

To me accessibility is not a separate feature or layer you add at the end. It is a measure of whether the product can actually be used by the people who need it.

-- Owen McGirr

Where the Obvious Fix Fails

Conventional wisdom suggests that accessibility can be bolted on later. McGirr’s experience suggests the opposite: tacked-on accessibility is immediately apparent to the end user. It manifests as jumping focus, awkward navigation flows, and features that work only in the simplest cases.

Systems thinking reveals that accessibility is tied to platform API usage. If a developer uses native controls, the system inherits built-in accessibility. If they build custom controls without providing the same role, state, and focus behavior, they are building a black box that assistive technology cannot penetrate. The quick win here is not a complex feature. It is the discipline of using native components and ensuring the entire task is navigable via keyboard.

Using AI to Stress-Test UX Assumptions

McGirr’s approach to testing Switchify provides a way to use AI as a constraint-based testing tool. By building a harness that restricts an AI agent to a limited set of switch-based actions like Next, Previous, or Select, he forces the AI to navigate the UI as a switch user would.

When the AI struggles to interpret the interface, it is not a failure of the AI. It is a diagnostic signal that the UX is ambiguous. This reveals a non-obvious dynamic: if a machine equipped with visual context and clear instructions cannot navigate the system, a human user with limited input options certainly cannot either.

The model has the instructions and the visual evidence yet the interface is still communicating something ambiguous. It makes the AI useful as a deliberately unfamiliar user.

-- Owen McGirr

The 18-Month Payoff: Designing for Participation

The true measure of accessibility is not raw speed, but participation. For an AAC user, the system is their voice. If the interface is too slow or the error recovery is too complex, the conversation moves on before the user can respond. This creates a feedback loop where the user is effectively silenced by the software design.

Building for this requires patience. It requires moving away from the fast solution mentality that prioritizes features over foundational usability. While this requires more effort upfront, the payoff is a product that is inherently more robust, predictable, and usable across all devices and input methods.

Key Action Items

• Audit Your Workflow (Immediate): Spend one day using your own software without a mouse. Use only Tab, Shift+Tab, Enter, and Escape. If you cannot complete the core task, the structure of your application needs immediate attention.
• Adopt Native Components (Immediate): Prioritize native UI elements. They come with built-in accessibility roles, states, and keyboard support that custom-built components often lack.
• Implement Pause Logic (Next 3-6 Months): If your application uses time-sensitive dialogues or automated processes, ensure there is a way to pause or extend the interaction indefinitely. Never assume the user can react within a fixed window.
• Label Everything (Immediate): Ensure every interactive element has a semantic label. Placeholder text is not a substitute for a real label.
• Test Task-Level Accessibility (Ongoing): Stop testing components in isolation. Test the entire task flow, from start to finish, using a screen reader or switch-style navigation to ensure the logic remains consistent.
• Build Constraint-Based Test Harnesses (12-18 Months): If you are using AI in your development pipeline, create test environments that enforce input constraints like keyboard-only or switch-only to expose where your UI is actually confusing.