Accessible Interaction Playbook

Using semantic HTML is table stakes. Real accessibility happens in the interactions: when users open a modal, does focus trap correctly? When a form submits, do screen readers announce what happened? When content animates, does it make anyone nauseous? Most apps get the static markup right but fumble every dynamic interaction. Don’t be most apps.

Manage Focus Deliberately

Focus is the keyboard user’s cursor. Lose track of it and you’ve lost your user. They’re tabbing through a void, hoping to stumble onto something interactive:

• Create clear focus paths: Every screen needs one logical tab order. Use Focus Management to trap focus inside modals. If the modal is open, keyboard users shouldn’t be able to tab onto the page behind it. That’s chaos.
• Add skip links: Put Skip Links at the top of your page so keyboard users can jump straight to content instead of tabbing through numerous navigation links. It’s the accessibility equivalent of an express lane.
• Design for focus first: Figure out focus order during design, not at 4pm the day before launch. Annotate your wireframes with tab order. Future you will thank present you.

Make Everything Keyboard Accessible

If users can click it with a mouse, they should be able to activate it with a keyboard. This isn’t optional, it’s basic functionality:

• Implement full keyboard support: Use Keyboard Navigation to make every interactive element respond to Enter, Space, and arrow keys where appropriate. Show visible focus states. Don’t intercept screen reader shortcuts; you will lose that battle.
• Keep shortcuts optional: Keyboard shortcuts are nice-to-have, not must-have. Only add them if there’s also a mouse/touch alternative. And for the love of accessibility, let users customize or disable them.
• Test without a mouse: Unplug your mouse and try to use your app. If you get frustrated in 30 seconds, imagine using it every day. Mouse-only interactions aren’t “advanced features,” they’re bugs.

Announce Dynamic Changes

Screen reader users can’t see your success toast pop up. If you don’t announce it, they’ll never know their action succeeded:

• Use live regions: Implement Live Regions to announce toasts, error messages, and loading states. These alert screen reader users without yanking their focus away from what they’re doing.
• Keep announcements brief: Announcing every state change is like having someone narrate your entire browsing session out loud. It’s maddening. Only announce things that matter: errors, confirmations, important status changes.
• Support all languages: Test your announcements in other languages. A short English message might become a verbose French sentence that cuts off mid-word. That’s not a great user experience.

Respect Motion Preferences

Your parallax scrolling effect might delight some users and make others literally nauseous. Respect the prefers-reduced-motion setting:

• Honor reduced motion: Use Accessible Animation to check if users have reduced motion enabled. If they do, skip the fancy animations and use simple fades or instant transitions. Making someone sick to show off your CSS skills is not a good trade.
• Keep animations purposeful: Animations should communicate something useful (loading, transitioning, feedback). If an animation is purely decorative, it’s the first thing to cut when users prefer reduced motion. And for the love of UX, don’t auto-play sound or aggressive haptics.

Design for Screen Readers

Screen readers turn your visual interface into spoken text. If your markup is a mess, the narration will be too:

• Use proper ARIA: Follow the Screen Reader pattern to give elements correct roles, labels, and states. When a button changes from “collapsed” to “expanded,” update the ARIA state immediately. Screen readers can’t guess.
• Provide context: When users tab into a complex component like a data grid, announce what keyboard shortcuts are available. Don’t make them guess how to navigate your custom widget. Brief instructions save everyone time.

Make Accessibility Routine

Treating accessibility as an audit at the end of development is how you end up retrofitting it poorly. Build it in from the start:

• Define requirements upfront: Add accessibility criteria to your feature specs. Document where focus should move, what gets announced, how animations adapt. If it’s not specified, it won’t get built.
• Test regularly with assistive tech: Turn on VoiceOver, NVDA, JAWS, or TalkBack at least once a week. They all behave differently. Using them regularly makes accessibility bugs obvious instead of surprising.
• Automate what you can: Use axe-core to catch low-hanging fruit automatically. Write integration tests that verify focus management. Automation catches the basics, manual testing catches the nuance.

Remember: Accessible interactions aren’t extra credit, they’re core functionality. About 15% of the world has some form of disability. Ignoring them means ignoring a massive chunk of potential users because you couldn’t be bothered to test with a keyboard.