Design and development practices that ensure digital products are perceivable, operable, understandable, and robust for people with diverse abilities, assistive technologies, and usage contexts. Candidates should demonstrate knowledge of the Web Content Accessibility Guidelines and conformance levels such as A, AA, and AAA and be able to explain how to apply those guidelines in product work. Core technical topics include using semantic Hypertext Markup Language structure and accessible component patterns, prudent use of Accessible Rich Internet Applications roles properties and states only when native semantics are insufficient, and progressive enhancement to preserve accessibility. Interaction topics include keyboard navigation and comprehensive focus management, logical tab order, visible focus indicators, touch target sizing, and mobile accessibility. Visual topics include color contrast, readable typographic scales, and accommodation for color blindness and low vision. Content topics include alternative text and descriptive labels for images and media, accessible form controls with labels and clear error messaging, and plain accessible language. Motion and animation considerations include providing controls to reduce or disable motion for vestibular sensitivities. Testing and validation cover automated auditing tools, manual accessibility audits, keyboard only testing, assistive technology testing such as screen reader and magnifier testing, and usability testing with people with disabilities. Candidates should be prepared to discuss specific accessibility decisions and trade offs they made, testing strategies and metrics, monitoring and preventing regressions, and how accessibility is integrated into design systems team workflows and the product lifecycle through documented patterns acceptance criteria and advocacy.
EasyTechnical
54 practiced
Explain how to assess color contrast for text and UI elements, state the WCAG contrast thresholds for normal and large text at AA and AAA levels, and describe how you would present accessible color variants to stakeholders without breaking brand recognition.
Sample Answer
**Approach to assessing contrast**I start by measuring relative luminance contrast between foreground and background using a contrast checker (built into Figma plugins, Stark, or the WCAG formula). I verify real UI states — disabled, hover, focus, modal overlays — and test with zoomed text and color-blind simulators.**WCAG contrast thresholds**- AA normal text: 4.5:1 - AA large text (≥18pt or ≥14pt bold): 3:1 - AAA normal text: 7:1 - AAA large text: 4.5:1**How I present accessible color variants to stakeholders**- Create side-by-side color token table showing: brand color, contrast ratio, suggested accessible variant, and usage guidance (primary vs. accent vs. background).- Provide annotated mockups (primary screens and edge states) showing variants in context so stakeholders see brand preserved.- Offer “do’s and don’ts” with visual examples that keep hue/saturation consistent while adjusting lightness to meet ratios.- Include migration plan: token updates in design system, dev-ready CSS variables, and acceptance criteria for QA.This balances accessibility with brand recognition by keeping hue and personality while adjusting luminance and supporting system-level tokens for consistent implementation.
EasyTechnical
60 practiced
Describe recommended touch target sizes, spacing, and tappable-area strategies for mobile interfaces. Explain how you would balance density and accessibility on small screens, and what guidelines you would include in a mobile component spec.
Sample Answer
**Recommended sizes & spacing**- Minimum touch target: 44px (iOS) / 48dp (Android) as the baseline. I specify these as the tappable area regardless of visible control size.- Ideal comfortable target: 56–64px for primary actions or frequently used controls.- Minimum spacing between touch targets: at least 8–12px clear space; for critical adjacent targets use 16px+ or separators.**Tappable-area strategies**- Extend the hit area beyond the visible element with invisible padding (maintain visual rhythm).- Prioritize primary actions with larger hit zones and higher contrast.- Use larger hit areas for icons in dense toolbars; keep visual size small but hit area large.- Prevent accidental taps with debounce (≥300ms) and smart gesture conflict resolution.**Balancing density vs accessibility**- Use progressive disclosure: surface high-priority actions, hide secondary actions in overflow menus.- Use adaptive layouts: compact grid/list at small widths, expanded spacing on tablets.- Offer configurable density in settings for power users; default to accessible spacing.- Validate with reachability testing (one-handed thumb zones) and accessibility audits (VoiceOver/TalkBack).**Component-spec checklist (what I include)**- min hit area (px/dp), visual size, spacing, and margin rules- touch padding implementation details (CSS/Android/iOS snippet)- visual affordance: contrast ratios, focus & pressed states- accessibility labels, roles, and keyboard equivalents- edge cases: stacked icons, lists, modal close targets- testing criteria: automated tap-target QA and manual thumb-zone testsThis approach keeps interfaces efficient for power users while ensuring they’re reliably tappable and accessible.
EasyTechnical
71 practiced
Rewrite the following sentence into plain accessible language suitable for an in-product notification and explain each change: "Our application presents an aggregation of user-entered metadata which may be purged periodically based on compliance-determined retention windows." As a product designer, state the trade-offs between clarity and brand voice.
Sample Answer
Rewritten notification (plain, accessible):We keep any notes or tags you add to items for up to 90 days. After that, we remove them to meet legal requirements. If you want to keep something longer, export or save it now.Why I changed each part- "We keep any notes or tags you add to items": Replaces "aggregation of user-entered metadata" with concrete, everyday terms ("notes", "tags") so users immediately understand what data is affected.- "for up to 90 days.": Replaces vague "retention windows" with a specific timeframe so users can form a mental model and act if needed.- "After that, we remove them": Uses an active verb ("remove") instead of passive "purged" to be clearer and less alarming.- "to meet legal requirements.": Short, plain reason instead of "compliance-determined" which is jargon.- "If you want to keep something longer, export or save it now.": Adds a clear, actionable next step to reduce user anxiety.Trade-offs between clarity and brand voice- Clarity priority: I favor plain language and explicit actions for accessibility and trust—critical in notifications.- Brand voice trade-off: A playful or formal brand voice can be layered into greetings or microcopy elsewhere, but should not obscure urgency or instructions here.- Practical compromise: Keep core sentence plain and add a subtle brand tone in a short preface or CTA label (e.g., "Heads up — we remove..." or branded button copy).
HardTechnical
78 practiced
How do accessibility concerns change when you design for international markets and multiple languages (including right-to-left scripts)? Discuss layout direction, iconography, localization of alt text and labels, screen reader nuances per locale, and how to adapt the design system to handle these needs.
Sample Answer
**Situation & goal** As a product designer building for global audiences, accessibility must be baked into localization and the design system so users in every locale — including RTL scripts — have equivalent experiences.**Layout direction (LTR vs RTL)** - Support logical mirroring: reading flow, primary/secondary controls, progress indicators, and form field order. - Use start/end CSS logical properties (margin-inline-start, padding-inline-end) and avoid hardcoded left/right. - Test keyboard focus order and tabbing in mirrored layouts.**Iconography & visuals** - Mirror directional icons (arrows, chevrons) for RTL; keep non-directional symbols identical. - Ensure icons remain semantically clear when mirrored; adjust illustrations that contain text or culturally specific imagery.**Localization of alt text and labels** - Localize all alt, aria-label, title, placeholder and error texts — avoid concatenated strings. - Prefer resource files with context comments for translators; include character limits and text direction metadata.**Screen reader & locale nuances** - Use lang attribute on document and subtrees so AT applies correct pronunciation and voice. - For RTL, use dir="rtl" and ensure screen readers announce numbers/dates correctly (use Unicode BiDi controls if mixing LTR content). - Test with NVDA, VoiceOver, TalkBack in target locales and languages.**Design system adaptations** - Create tokens for direction-aware spacing, typography, and icon variants. - Provide mirrored component variants and guidelines for translators and engineers. - Include accessibility checklist, localization keys, and examples in the component docs.**Process & validation** - Involve native speakers and users with disabilities in research and QA. - Add automated checks (i18n linting, directionality tests) and manual accessibility audits per locale.Result: a design system and product that treat localization and accessibility as first-class constraints, reducing regressions and delivering consistent, usable experiences worldwide.
MediumTechnical
64 practiced
How would you prototype features so they are testable with assistive technology (screen readers, keyboard navigation) and realistic enough for inclusive usability sessions? Describe tools, fidelity decisions, and how you balance speed with testability when working with PMs and engineers.
Sample Answer
**Approach (goal)** Prototype features so participants can use screen readers and keyboard-only flows realistically, while moving fast enough to iterate with PMs and engineers.**Tools & artifacts** - Low/medium-fidelity: Figma with semantic layer (labels, tabindex notes), interactive flows using Variants/Prototype links for keyboard focus order. - High-fidelity & testable: HTML/CSS/JS snippets or Storybook components with semantic HTML and ARIA attributes; run in browser with VoiceOver (macOS) and NVDA (Windows). - Assistive simulators: Axe DevTools, Accessibility Insights for automated checks; Tota11y for quick in-browser hints.**Fidelity decisions & when** - Early rounds: click-through Figma + clear scripts for screen-reader scenarios to validate concepts. - Validation rounds: coded prototypes when verifying reading order, live announcements, focus management, or keyboard traps.**Balancing speed vs testability** - Start with acceptance criteria mapping: list critical behaviors (focus order, skip links, live regions). Share with PMs/engineers to scope prototype effort. - Prioritize "testable knobs": implement only needed semantics in code (proper headings, buttons, live regions). Use Storybook knobs to iterate quickly. - Timebox engineering work: 1–2 focused components for sessions rather than full app.**Collaboration & facilitation** - Pair with an engineer to build minimal accessible HTML; use recordings and transcripts for stakeholders. - In sessions, give clear tasks and assistive-tech setup; capture observations tied to acceptance criteria.Outcome: fast validation of real assistive behaviors without overbuilding.
Unlock Full Question Bank
Get access to hundreds of Accessibility and Inclusive Design interview questions and detailed answers.
