Owen McGirr on Software Accessibility

The podcast discusses accessibility in software development from both theoretical and practical perspectives, emphasizing the importance of designing products that accommodate diverse user needs and input methods such as keyboard navigation, switch controls, voice, eye gaze, and screen readers. It highlights common assumptions in software design - such as reliance on fine motor control, visual clarity, or rapid response times - that create barriers for users with disabilities. The discussion stresses that retrofitting accessibility is often ineffective and costly, advocating instead for integrating accessibility from the earliest stages of development through semantic HTML, logical focus order, proper labeling, and support for platform accessibility APIs.

Several tools and applications are examined as case studies, including "Say It," a text-to-speech AAC app, and "Switchify," an Android and Windows tool enabling switch and facial gesture control. These projects illustrate technical challenges such as inconsistent browser-based speech synthesis, managing latency in communication, and building robust scanning interfaces. The role of AI in accessibility is also explored - not as a replacement for real user testing, but as a tool to simulate switch-based navigation and surface UX ambiguities. The conversation extends to platform differences, with insights on iOS, Android, and Windows, underscoring the need for consistent, reliable accessibility APIs and the importance of involving disabled users throughout the design and development process.

• What if you redesigned your core user flow for switch or voice-only access?

  • Move: Pick one primary workflow in your app (e.g. onboarding, checkout, or posting content) and rebuild it using only keyboard tab navigation and semantic HTML, ensuring every action is reachable and labeled without relying on mouse hovers or touch gestures.
  • Why Now?: Most accessibility issues stem from assuming mouse/touch input; retrofitting later is costlier and less effective. Starting now with a real user flow ensures structural compliance early.
  • Expected Upside: You'll uncover hidden UX flaws, improve SEO and test automation, and make your product usable by people with motor disabilities - expanding your market while reducing future rework.

• What if you used AI to simulate how a switch user would struggle with your interface?

  • Move: Set up an AI agent (e.g. GPT-4V) to analyze screenshots of your app's key screens, giving it a goal (e.g. "submit a form") and restricting its actions to "next," "previous," "select," and "back" - then log where it gets stuck or makes wrong choices.
  • Why Now?: AI can rapidly expose ambiguous labels, illogical focus order, or missing semantics before real users encounter them, especially as AI tools now support vision-based reasoning.
  • Expected Upside: You'll catch 30 - 50% of critical accessibility issues pre-launch, reduce support burden, and create a repeatable test suite that evolves with your UI.

• What if you launched a minimal AAC-compatible version of your app for users who rely on text-to-speech?

  • Move: Fork your current app into a PWA variant optimized for AAC users - enable dynamic text scaling, ensure all buttons have visible labels, eliminate time-limited interactions, and add phrase prediction or shortcuts for frequent actions.
  • Why Now?: With rising demand for inclusive tools and AI-assisted development, building AAC-aware features is faster than ever - and gives you first-mover advantage in underserved markets.
  • Expected Upside: You'll differentiate your product, improve usability for all users (especially in high-fatigue scenarios), and open doors to education, healthcare, or enterprise contracts requiring accessibility compliance.

• Audit your software's accessibility early by testing core workflows (e.g., checkout, form submission) using only keyboard navigation and a screen reader.
• Replace custom UI components with native HTML controls wherever possible to ensure built-in accessibility and proper semantic labeling.
• Design interactive elements with multiple input methods in mind - ensure buttons, links, and actions are usable via keyboard, switch, voice, or gaze input.
• Implement logical focus order and visible focus indicators, and ensure error messages are programmatically associated with inputs and announced to screen readers.
• Test your application with real assistive technologies (e.g., switch control, screen readers) in realistic scenarios, not just automated tools, and involve disabled users in feedback loops.