How do you ensure accessibility in UI components?

Long Answer

Accessibility is not an afterthought—it is part of component design from the start. As a UI Engineer, my role is to ensure each component is inclusive, operable, and perceivable by all users, regardless of ability or device.

1) Semantic-first design

I always prefer semantic HTML over div-spans. Buttons are <button>, lists are <ul><li>, and headings follow hierarchical structure. This allows screen readers and browsers to parse meaning without extra ARIA. Only when semantics fall short do I use ARIA roles to patch gaps (e.g., role="dialog" for modals).

2) Keyboard navigation

Keyboard accessibility ensures users can interact without a mouse. Best practices include:

• Tab order matches visual flow; no hidden traps.
  
• Focus states are always visible (custom but high-contrast outlines).
  
• Activation keys: Enter and Space work consistently for interactive elements.
  
• Escape/Arrow keys: used for modals, dropdowns, sliders.
  
• Focus trapping in modals and menus; returning focus to the opener when closed.
  

3) Screen reader support

Screen readers require meaningful announcements. I apply:

• Labels: aria-label, aria-labelledby, aria-describedby.
  
• Roles: dialog, navigation, tablist, alert.
  
• Live regions: aria-live="polite/assertive" to announce async updates (e.g., “3 items in cart”).
  
• Skip links: “Skip to main content” to bypass nav.
  
• Landmarks: <header>, <nav>, <main>, <footer> for structured navigation.
  

4) ARIA usage and pitfalls

ARIA fills semantic gaps but should not replace native HTML. Examples:

• Use role="dialog" with aria-modal="true" for modals.
  
• aria-expanded + aria-controls for dropdown toggles.
  
• aria-selected and aria-current for active states.
  I avoid “ARIA overuse” (e.g., role="button" on <div>), which harms accessibility.
  

5) Dynamic and responsive states

Modern apps update dynamically. Components must announce state changes to assistive tech. For example, toast notifications get role="status". When adding/removing DOM nodes, I confirm screen readers register the change. Responsiveness means ensuring no functionality is lost on mobile, zoom (200%), or text resize.

6) Inclusive design principles

Beyond technical A11y, inclusive design considers colorblindness, motion sensitivity, and cognitive load. Examples:

• Color is never the only indicator (icons + labels + text).
  
• prefers-reduced-motion disables parallax and autoplay.
  
• Forms include clear instructions, error states, and validation tied to inputs.
  
• Language is simple, avoiding jargon.
  

7) Testing strategy

Accessibility must be tested, not assumed. I combine:

• Automated: axe-core, Lighthouse, Pa11y for quick scans.
  
• Manual: keyboard-only runs, VoiceOver/NVDA screen reader tests.
  
• Cross-device: mobile screen readers (TalkBack, iOS VoiceOver).
  
• CI integration: automated audits in pipelines to prevent regressions.
  

8) Example scenario

A custom dropdown: built with <button> for the trigger, <ul role="listbox"> for items, aria-expanded for state, keyboard support (arrows, Escape), and focus management. Screen readers announce “Dropdown, 3 options, expanded/collapsed.” Visual users see focus outlines, and motion-sensitive users can disable animations.

By embedding accessibility at the component level, we scale inclusivity across entire products, ensuring both compliance and better UX for everyone.

‍

Table

‍

Common Mistakes

• Using <div> or <span> for interactive elements with onclick.
  
• Removing focus outlines for aesthetics (“focus invisible”).
  
• Forgetting to trap focus inside modals, leaving background accessible.
  
• Over-relying on ARIA when semantic HTML suffices.
  
• Ignoring prefers-reduced-motion, forcing autoplay or parallax.
  
• Providing color-only indicators (red vs. green states).
  
• Not testing with real screen readers, assuming automated tools catch everything.
  
• Misusing ARIA (e.g., aria-hidden on visible content).
  
• Failing to return focus to trigger after closing dialogs.
  
• Overlooking mobile screen reader behavior (TalkBack quirks).
  
  

Sample Answers

Junior:
“I build components with semantic HTML, add labels, and make sure everything is tab-navigable. For example, buttons use <button>, not divs, and I keep visible focus outlines. I run Lighthouse for basic audits.”

Mid:
“I integrate accessibility from design. Dropdowns have aria-expanded and arrow key support, modals trap focus, and forms announce errors with aria-describedby. I test components with NVDA and VoiceOver, and add automated checks in CI.”

Senior:
“My approach is systemic: accessible tokens, reusable patterns, and Storybook documentation. Components always use semantic HTML first, ARIA only as needed, and motion respects prefers-reduced-motion. We run manual assistive tech tests, integrate axe-core in pipelines, and maintain design guidelines. Accessibility is part of acceptance criteria, not a post-check.”

‍

Evaluation Criteria

• Semantic-first mindset: Candidate uses proper HTML before ARIA.
  
• Keyboard operability: All components reachable, tabbable, and usable without a mouse.
  
• Screen reader clarity: Correct roles, labels, and live announcements.
  
• Motion and inclusivity: Respects prefers-reduced-motion, avoids color-only states.
  
• Testing maturity: Mix of automated and manual assistive technology tests.
  
• Cross-device awareness: Mentions desktop and mobile readers (NVDA, VoiceOver, TalkBack).
  
• Process discipline: Accessibility baked into design system and component library.
  Red flags: Hides focus, misuses ARIA, assumes audits replace manual testing, ignores inclusivity beyond screen readers.
  
  

Preparation Tips

• Review WCAG 2.2 guidelines for components (focus, color, motion).
  
• Practice building accessible modals, dropdowns, and forms with semantic HTML + ARIA.
  
• Learn ARIA states like aria-expanded, aria-selected, aria-live.
  
• Run keyboard-only tests on your projects.
  
• Install NVDA, VoiceOver, and TalkBack to practice manual testing.
  
• Integrate axe-core or pa11y into local/CI pipelines.
  
• Explore reduced-motion queries (prefers-reduced-motion) in CSS.
  
• Prepare to explain trade-offs: why semantic HTML is always better than ARIA hacks.
  
• Draft a personal accessibility checklist for each component.
  
  

Real-world Context

E-commerce cart: A modal previously lacked focus management; adding role="dialog" and focus trap reduced abandonment.
Banking app: Transaction forms announced errors via inline text but not to screen readers. Adding aria-describedby improved task success for blind users.
Healthcare portal: Dynamic lab results updates were silent to screen readers. Adding aria-live announced changes in real time.
SaaS dashboard: Dropdown menus used <div> with click handlers. Refactored to <button> + <ul role="listbox">, enabling arrow key navigation and screen reader clarity.

These examples show inclusive UI components improve usability for everyone—not just those with disabilities.

‍

Key Takeaways

• Use semantic HTML first, ARIA as a gap-filler.
  
• Ensure robust keyboard navigation and focus management.
  
• Announce dynamic updates with ARIA live regions.
  
• Respect reduced-motion preferences and avoid color-only signals.
  
• Test with real assistive technologies, not just automation.
  
  

Practice Exercise

Scenario:
You’re tasked with building a reusable modal and dropdown component for a design system. They must support accessibility across keyboard, screen readers, and motion-sensitive users.

Tasks:

1. Modal: Implement with <dialog> or <div role="dialog">, trap focus inside, announce via aria-labelledby. Add Escape key close and restore focus to trigger.
   
2. Dropdown: Use a <button> trigger with aria-expanded and aria-controls. Render list items inside <ul role="listbox">, support arrow keys, and announce selection with aria-selected.
   
3. Apply prefers-reduced-motion to animations (fade-in instead of slide).
   
4. Ensure color is not the only indicator—add icons or labels.
   
5. Write unit tests for keyboard navigation, snapshot tests for ARIA attributes, and run Lighthouse/axe audits.
   
6. Test with NVDA, VoiceOver, and keyboard-only flows. Document results.
   
   

Deliverable:
A pair of accessible UI components (modal + dropdown) that demonstrate semantic HTML, ARIA states, keyboard operability, reduced-motion compliance, and screen reader clarity—proving inclusive design in practice.