Accessible Interaction Playbook

Semantic HTML is essential, but a lot of accessibility problems only appear once users start interacting with the page. When users open a modal, focus needs to stay inside it. When a form submits, screen readers need to announce what happened. When content animates, it needs to respect motion preferences. Many applications handle static markup well but struggle with these dynamic interactions, and this guide covers each of them.

Manage Focus Deliberately

Focus is how keyboard users navigate your interface. When focus management breaks down, users find themselves navigating without any sense of where they are or how to reach interactive elements.

• Create clear focus paths: Every screen needs one logical tab order. Use Focus Management to trap focus inside modals. When a modal is open, keyboard users shouldn’t be able to tab onto the page behind it.
• Add skip links: Place Skip Links at the top of your page so keyboard users can jump directly to content instead of tabbing through many navigation links.
• Design for focus first: Determine focus order during design, not at the end of development. Annotate wireframes with tab order to ensure accessibility is considered from the start.

Make Everything Keyboard Accessible

If users can click something with a mouse, they should be able to activate it with a keyboard. Keyboard support is core 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. Avoid intercepting screen reader shortcuts, which frustrates users.
• Keep shortcuts optional: Keyboard shortcuts are conveniences, not requirements. Only add them if there’s also a mouse or touch alternative. Allow users to customize or disable them.
• Test without a mouse: Disconnect your mouse and try to use your application. If you struggle, users who navigate this way every day struggle too. Anything that only works with a mouse is an accessibility bug.

Announce Dynamic Changes

Screen reader users cannot see visual feedback like success toasts or loading indicators. Without announcements, they have no way of knowing their action succeeded.

• Use live regions: Implement Live Regions to announce toasts, error messages, and loading states. These inform screen reader users without moving their focus away from their current task.
• Keep announcements brief: Announcing every state change overwhelms users, so announcements work best for errors, confirmations, and important status changes.
• Support all languages: Test announcements in other languages. A short English message might become a longer sentence in another language and get truncated.

Respect Motion Preferences

Animations that some users enjoy can make others feel sick or disoriented. The prefers-reduced-motion setting exists for this reason.

• Honor reduced motion: Use Accessible Animation to check if users have reduced motion enabled. When they do, use simple fades or instant transitions instead of elaborate animations.
• Keep animations purposeful: Animations should communicate something useful: loading progress, state transitions, or feedback. Purely decorative animations are the first thing to remove when users prefer reduced motion. Avoid auto-playing sound or aggressive haptic feedback.

Design for Screen Readers

Screen readers read the interface out loud, and how easy that is to follow depends on how well the markup is structured.

• 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 rely on accurate state information.
• Provide context: When users tab into a complex component like a data grid, announce what keyboard shortcuts are available. Brief instructions help users navigate custom widgets efficiently.

Make Accessibility Routine

Leaving accessibility to an audit at the end of development usually means retrofitting it badly, and building it in from the start gives better results.

• Define requirements upfront: Add accessibility criteria to feature specifications. Document where focus should move, what gets announced, and how animations adapt. What isn’t specified usually doesn’t get built.
• Test regularly with assistive tech: Use VoiceOver, NVDA, JAWS, or TalkBack at least once a week. They all behave differently, and regular use means you find problems during development instead of after release.
• Automate what you can: Use axe-core to catch common issues automatically. Write integration tests that verify focus management. Automation catches the common issues, and manual testing catches the ones that need a person to notice.

Remember: Accessible interactions are core functionality. The World Health Organization estimates that 1.3 billion people, about 16% of the world’s population, live with a significant disability. The same focus handling, announcements, and motion settings make the interface easier for everyone else too.