Accessible Interaction Playbook

Semantic HTML is essential, but real accessibility shows in 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 respect motion preferences? Many applications handle static markup well but struggle with dynamic interactions. This guide addresses those challenges.

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. This is core functionality, not an optional enhancement.

• 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 customise or disable them.
• Test without a mouse: Disconnect your mouse and try to use your application. If you struggle, consider what that experience is like for users who navigate this way every day. Mouse-only interactions are accessibility gaps.

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. Focus on what matters: 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 that gets truncated. Verify that translations work well.

Respect Motion Preferences

Animations that delight some users can cause discomfort or disorientation for others. The prefers-reduced-motion setting exists precisely for this reason.

• Honour 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 transform visual interfaces into spoken text. Well-structured markup produces clear narration; poorly structured markup creates confusion.

• 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

Treating accessibility as an end-of-development audit usually means poor retrofitting. Building it in from the start produces better outcomes.

• 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. Regular use makes accessibility issues obvious rather than surprising.
• Automate what you can: Use axe-core to catch common issues automatically. Write integration tests that verify focus management. Automation handles the basics while manual testing catches nuance.

Remember: Accessible interactions are core functionality. About 15% of the global population has some form of disability. Building with accessibility in mind means building for everyone.