Accessibility and Inclusive Design

"How would you make this accessible?" is one of the most common practical prompts in a UI/UX design interview, and it's a prompt with a wrong-answer shape that's easy to spot: candidates who reach for a vague, feel-based answer ("make sure it's easy to use for everyone") instead of citing specific, testable standards. Accessibility is not a vibe — it's a body of numbered, falsifiable rules (a 4.5:1 contrast ratio either passes or it doesn't) layered under a broader philosophy of designing for human diversity. Interviewers use this prompt because the gap between candidates who've internalized the actual standard and candidates who've absorbed the general idea of "accessibility is important" shows up immediately, often within the first sentence of the answer.

This subject covers the standard (WCAG, its four principles, and its conformance levels), the specific numeric rules interviewers fact-check most often (contrast ratios, keyboard operability, focus visibility), how assistive technology actually consumes an interface (the accessibility tree, ARIA), how teams verify their own work (automated and manual testing), the broader inclusive-design lens that explains why these rules exist beyond legal compliance, and a fully worked example of the exact interview prompt in its title.

It builds on interaction-design-principles (keyboard interaction patterns) and visual-design-fundamentals (contrast and typography) elsewhere in this track, and connects forward to responsive-and-mobile-design, where situational impairments (bright sunlight, one-handed use) recur as a design constraint. Nothing here requires code to understand — but every rule below is a rule you could point at in a real component review, which is exactly why interviewers reach for this topic so often.

One framing to hold onto throughout: every section below answers a version of the same question — given this specific rule, what would a real user actually experience if it were violated, and how would you verify it was fixed? That's the difference between reciting a standard and demonstrating you've applied one.

WCAG and the POUR Principles

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the standard nearly every accessibility conversation in industry and law traces back to. The current versions in active use are WCAG 2.1 (2018) and WCAG 2.2 (2023), which extends 2.1 with additional success criteria rather than replacing it — 2.1 content remains valid, 2.2 adds to it (for example, 2.2 added stricter target-size and focus-visibility criteria on top of 2.1's baseline). WCAG organizes its success criteria under four principles, abbreviated POUR, and every individual success criterion in the standard is numbered and filed under exactly one of the four:

• Perceivable — information and interface components must be presentable to users in ways they can perceive, regardless of which sense they rely on. Example (Success Criterion 1.1.1, Non-text Content): an <img> of a bar chart needs an alt attribute describing what it shows (or, if purely decorative, alt="" so a screen reader skips it silently) — without it, the information exists visually but is imperceptible to a blind user. The same principle is why video needs captions: the information exists audibly but is imperceptible to a deaf user.
• Operable — interface components and navigation must be operable by the user. Example (SC 2.2.1, Timing Adjustable): a carousel that auto-advances every 3 seconds with no pause control is inoperable for a user who reads slowly or has a motor impairment that makes clicking within a tight window difficult — WCAG requires that time limits be extendable, pausable, or removable, not just "generous."
• Understandable — information and the operation of the interface must be understandable. Example (SC 3.3.1/3.3.3, Error Identification and Suggestion): a form that rejects a submission with only a generic "Error" banner and no indication of which field failed or why is unclear even to users with no disability, and actively blocking for someone with a cognitive disability — the fix is inline, specific error text next to the offending field, plus a suggestion for how to fix it.
• Robust — content must be robust enough to be interpreted reliably by a wide range of user agents, including assistive technologies, both now and as they evolve. Example (SC 4.1.2, Name, Role, Value): using valid, semantic HTML (a real <button>, not a <div> with a click handler) ensures a screen reader, a braille display, and next year's assistive-tech release all interpret the element the same way — non-standard or invalid markup is a coin flip on each.

Why this matters in an interview: naming POUR and giving one concrete example per principle, ideally with the rough success-criterion number attached, is a fast way to demonstrate you know the standard has structure, not just a pile of unrelated rules — and it gives you a framework to slot any specific accessibility fix into ("that's an Operable fix" / "that's a Perceivable fix") when asked to justify a design decision on the spot.

What WCAG 2.2 added on top of 2.1. Knowing at least one or two of these signals you've kept up with the standard rather than memorizing a five-year-old version of it:

• SC 2.5.8, Target Size (Minimum): interactive targets (buttons, links, icons) must be at least 24×24 CSS pixels, unless spacing or an exception applies — directly relevant to touch-target sizing on mobile.
• SC 2.4.11, Focus Not Obscured: a focused element can't be entirely hidden behind a sticky header, a cookie banner, or another overlapping element — a real, common bug on pages with sticky navigation.
• SC 3.3.8, Accessible Authentication: a login flow can't rely on a cognitive test (like solving a puzzle CAPTCHA or remembering a transformed password) as the only way to authenticate, without an alternative.

Conformance Levels: Why AA, Not AAA, Is the Target

WCAG defines three conformance levels, each success criterion tagged with exactly one:

This is a common interview fact-check: if you say "we design to AAA" without qualification, it signals you're reciting a word rather than understanding the standard — WCAG's own conformance requirements note that AAA cannot always be satisfied for some content, which is why it's not the general-purpose target. The correct, precise answer is AA: it's the level that's both rigorous enough to remove the major barriers and realistic enough to apply across an entire product, and it's the level regulators and legal standards actually cite by name.

In practice, teams still selectively adopt specific AAA criteria where they're cheap and high-value (for example, a 7:1 contrast target for a small set of critical text, or extended audio descriptions on a flagship marketing video) without claiming full AAA conformance across the site. When asked "what accessibility level do you design to," the strongest answer is "AA as the baseline, with selective AAA criteria adopted where the cost is low and the content is high-stakes" — that's a materially better answer than either "AAA everywhere" or "A is enough."

Where AA gets cited by name in practice — worth having one or two of these ready if an interviewer pushes on "why AA specifically":

• ADA (Americans with Disabilities Act), Title III litigation and DOJ guidance in the US routinely treat WCAG 2.1 AA as the de facto technical standard for "effective communication," even though the ADA text itself predates WCAG and doesn't name it directly.
• Section 508 governs US federal agency procurement and explicitly incorporates WCAG 2.0 AA (with agencies increasingly held to 2.1 AA in practice).
• EN 301 549 is the EU's harmonized accessibility standard, referencing WCAG 2.1 AA, and underlies the European Accessibility Act's requirements for many private-sector digital products and services.
• AODA (Accessibility for Ontarians with Disabilities Act) in Canada similarly requires WCAG 2.0 AA for public-facing web content.

One more nuance worth having ready: a conformance claim is technically made per page, not automatically for an entire site — a real audit walks through representative page types (homepage, a form page, a content page, a checkout flow) rather than asserting conformance for the whole product from a spot-check of one screen. A candidate who says "the whole site is AA compliant" after checking a single landing page is making exactly the kind of overclaim a rigorous interviewer will probe.

Contrast Ratio Math

What a contrast ratio is, conceptually: it's a comparison of the relative luminance (how much light a color reflects, on a 0-to-1 scale independent of hue) between a foreground color and its background, expressed as a ratio from 1:1 (identical, no contrast at all) to 21:1 (pure black on pure white, the maximum possible contrast). You don't need to compute the luminance formula by hand in an interview or on the job — any contrast checker tool takes two hex colors and returns the ratio instantly — but you do need to know the pass/fail thresholds, because that's what turns "does this look readable" from a subjective judgment call into a testable, falsifiable spec a designer can defend or a QA process can automate.

WCAG 2.1 AA's specific numeric requirements:

A concrete worked example, the kind interviewers expect you to reason through: #999999 text on a #FFFFFF background comes out to roughly 2.85:1 — a common design-system default that looks acceptable at a glance and still fails the 4.5:1 minimum outright. Darkening it to #767676 on the same white background lands at roughly 4.54:1, which clears the threshold with a small safety margin. The point of walking through numbers like this isn't memorizing hex values — it's demonstrating that you treat contrast as an engineering constraint with a pass/fail answer, not a matter of taste to be argued about in a design review.

The reason to internalize the exact thresholds rather than a fuzzy "make sure there's enough contrast" is the same reason the whole standard is built this way: a contrast checker gives a binary pass/fail against a cited number, which means a designer can catch a violation before a review meeting instead of arguing about whether pale-gray-on-white "looks fine" to a particular reviewer's eyes on a particular monitor under particular lighting. In an interview, citing "4.5:1 for body text, 3:1 for large text and UI components" is the single fastest way to establish you've actually worked against the spec rather than around a general impression of it.

What's exempt, and why it's worth knowing the exceptions too — citing these correctly (rather than over-applying the rule everywhere) also signals real fluency with the spec, not just the headline numbers:

• Disabled or inactive UI components (a grayed-out "Submit" button before a form is valid) are exempt from the 3:1 UI-component minimum, since they're not currently operable at all — contrast rules exist to make operable things perceivable.
• Logos and brand marks are exempt from the text contrast requirements, since brand identity is treated as a separate concern from functional legibility.
• Text that is part of a photograph or an incidental screenshot, where the text isn't the primary conveyed content, is exempt — a photo of a street sign in a travel article isn't held to the same bar as the article's body copy.
• Pure decoration (a background watermark, a purely stylistic divider) is exempt because it conveys no information a user needs to perceive.

Keyboard Navigation and Focus

Every interactive element — links, buttons, form fields, custom widgets — must be reachable and fully operable using the keyboard alone, with no mouse:

• Tab / Shift+Tab move focus forward and backward through interactive elements, following the page's tab order (SC 2.4.3, Focus Order).
• Enter (and Space, for buttons and checkboxes) activates the focused element.
• Arrow keys handle movement within a composite widget (a menu, a set of radio buttons, a tab list) once it has focus, per the ARIA Authoring Practices patterns for that widget type.
• A skip link ("Skip to main content," SC 2.4.1, Bypass Blocks) as the very first focusable element lets a keyboard user jump past a repeated navigation bar instead of tabbing through every nav item on every single page load — a small addition with an outsized impact on a keyboard-only user's efficiency.

This isn't an edge case for a small population — keyboard-only use covers users with motor impairments who can't operate a mouse, blind users navigating via screen reader (which relies heavily on keyboard commands), and power users who simply find the keyboard faster for repetitive tasks. A product that's mouse-only for any interactive element is fully unusable, not just degraded, for that population — there's no partial credit for "you can see the button, you just can't reach it."

Visible focus indicator. At every moment, the currently focused element must have a visible indicator (SC 2.4.7, Focus Visible) — a default browser outline, or a custom style with equivalent or greater visibility. The classic, citable anti-pattern is a global CSS reset that includes outline: none (or outline: 0) on interactive elements, usually applied because the default blue outline "clashed with the design," with no replacement style added. Concretely, this breaks the product for two overlapping groups: a keyboard-only user tabbing through the page has no way to see which element is currently focused, so they can't tell what pressing Enter will activate next; a low-vision user relying on a strong visual cue to track focus loses that cue entirely, even if they can technically operate a mouse. The fix is never "put the default outline back and accept the visual clash" as a shrug — it's to design a custom :focus-visible style (a distinct border, background fill, or ring) that itself meets the 3:1 UI-component contrast requirement against its surrounding area, so focus stays clearly visible without reintroducing the visual clash that motivated removing it in the first place.

Logical tab order. Tab order should follow the visual/reading order of the page — generally, matching DOM source order to visual order is what makes this work for free; a layout that's visually reordered with CSS (flex-direction: row-reverse, order, or absolute positioning) without also reordering the underlying markup produces a tab sequence that jumps around the screen unpredictably. That's disorienting for a keyboard or screen-reader user even though it looks completely correct visually — this is a common bug precisely because it's invisible in a normal visual QA pass and only shows up when someone actually tabs through the page.

Keyboard patterns differ by widget type, and knowing a few of the standard ones (from the WAI-ARIA Authoring Practices Guide) shows you're not treating "keyboard accessible" as a single undifferentiated checkbox:

A focus trap that's missing on a modal is its own common, citable bug: without one, Tab silently walks focus out of the dialog and into page content sitting behind it (which may be visually hidden under an overlay), leaving a keyboard user unable to tell where focus went or how to get back.

Screen Readers and ARIA Semantics

A screen reader does not "see" a rendered page the way a sighted user does. It consumes the accessibility tree — a structured representation built from the page's semantic HTML and ARIA attributes, describing each element's role (what kind of thing it is — button, link, heading, list), name (its accessible label), and state (expanded, checked, disabled, selected). Visual layout — where something sits on screen, its color, its size, its z-index — is not part of this tree at all; it's simply invisible to that layer of the stack.

This is why a <div> styled with CSS to look exactly like a button (rounded corners, a shadow, a hover state, a click handler) is invisible to a screen reader as an interactive element, even though it's pixel-identical to a real button visually. The accessibility tree reports it as a generic, non-interactive container — a screen-reader user tabbing through the page won't land on it, and if they somehow reach it, it won't be announced as "button" or respond to Enter/Space by default. A native <button> element gets all of this for free from the browser: it's automatically in the tab order, automatically has role="button" in the accessibility tree, automatically responds to Enter and Space, and automatically gets a default focus indicator. This is often summarized as the first rule of ARIA: if a native HTML element or attribute already has the behavior or semantics you need, use it rather than reaching for ARIA on a generic element — ARIA can describe a custom widget, but it never grants the built-in keyboard behavior a native element gets automatically; you'd still have to wire that up by hand.

When a native element genuinely isn't available (a custom widget with no HTML equivalent, like a combobox with autocomplete, or a tab panel), ARIA (Accessible Rich Internet Applications) attributes fill the gap by directly annotating the accessibility tree:

• Landmarks (<nav>, <main>, <header>/role banner, <footer>, role="complementary") mark out the major regions of a page. Their purpose is specifically for screen-reader users: instead of tabbing linearly through every single link and element to get from the top of the page to the main content, a screen-reader user can jump directly by landmark (many screen readers expose a dedicated "rotor" or landmark-navigation shortcut for this), which is the assistive-tech equivalent of a sighted user's glance-and-skip visual scanning.
• Labels (aria-label, aria-labelledby) supply an accessible name when there's no visible text to derive one from. The classic case, and a frequent interview prompt in its own right: an icon-only button (a magnifying glass for search, an X for close, a trash can for delete) has no text content for a screen reader to announce — without aria-label="Search" (or similar), it's announced only as "button," with no indication of what it actually does. aria-labelledby does the same job by pointing to the id of another element already holding the label text, useful when that text is visible on screen for sighted users too and you don't want to duplicate it in a second, hidden string.
• Live regions (aria-live="polite" or aria-live="assertive") announce dynamic content changes that happen without a page reload — a form validation error appearing after submit, a "3 items added to cart" confirmation, a chat message arriving — content a screen reader wouldn't otherwise notice since nothing moved focus.

How an accessible name actually gets computed. When several of the above could apply to the same element, browsers resolve a single accessible name using a priority order, roughly: aria-labelledby (if present) wins first, then aria-label, then the element's own visible text content, then a title attribute as a last resort. Knowing this order matters in practice — adding aria-label="Submit" to a button that already visually reads "Submit order" silently overrides the visible text with whatever string you gave aria-label, which is exactly how a mismatch between what's displayed and what's announced sneaks into a codebase.

Testing what you built. Automated tools (axe, Lighthouse's accessibility audit, WAVE) are a fast first pass and typically catch on the order of 30-40% of WCAG issues — missing alt text, insufficient contrast, missing form labels, invalid ARIA usage — but they cannot evaluate whether a label is meaningful, whether a tab order is logical, or whether an interaction genuinely makes sense with a screen reader running, because those require judgment automated rules can't make. The rest requires manual verification:

Both manual passes are cheap enough to run on every significant component before it ships, and neither is optional if an automated scan is the only check being run — a scan reporting zero errors is evidence of "nothing a machine could catch," not evidence the component is actually usable.

Inclusive Design vs. Accessibility

Accessibility is about conformance — meeting a defined standard (WCAG, at AA) so that people with disabilities can use a product. Inclusive design, formalized by Microsoft's Inclusive Design framework, is the broader design practice it sits inside: designing for the full range of human diversity from the start, rather than treating disability as an edge case to patch in afterward once the "main" design is done.

The framework's central move is classifying impairment along a spectrum of three categories, using vision and hand/arm use as the illustrative examples:

The same spectrum applies past vision and mobility, and it's worth being ready to extend it: cognitive and attention load has a permanent case (a person with dyslexia or ADHD), a temporary case (someone recovering from a concussion, or on medication that affects concentration), and a situational case (a sleep-deprived new parent, or anyone trying to complete a form while a toddler is climbing on them) — clear language, generous time limits, and forgiving error recovery serve all three, which is exactly why the Understandable principle from WCAG isn't a "nice to have" layered on top of the "real" accessibility work, it's addressing this same spectrum from a different angle.

The framework's key insight, and the reason this section is worth citing beyond "accessibility is nice to have": designing a solution for the permanent case usually produces a solution that also helps the temporary and situational cases, so the investment isn't a niche accommodation for a small population, it's a multiplier. Closed captions, designed for permanently deaf users, also help someone with a temporary ear infection, and also help the enormous situational population watching video with sound off — on a train, in an open office, in a video autoplaying in a social feed. One-handed operable UI, designed for someone with a permanent limb difference, also helps someone with a temporary arm injury in a cast, and also helps the situational case of a parent holding a baby or a commuter gripping a subway pole with their free hand.

Interviewers listen for this reframe specifically because it repositions accessibility work from "a compliance cost for a small, fixed population" to "a design investment whose payoff scales with the much larger situational population everyone passes through at some point" — a materially stronger way to advocate for it internally than citing legal risk alone, and a distinctly different answer from simply restating what WCAG requires.

The curb-cut effect is the physical-world example the digital analogy is borrowed from, and it's worth naming directly: curb cuts (the sloped ramps at street corners) were built for wheelchair users, a permanent-impairment case — but they now also help a parent pushing a stroller, a delivery worker with a hand truck, a traveler rolling a suitcase, and a cyclist, none of whom are the population the ramp was designed for. The digital equivalent — captions, keyboard operability, clear error text — follows the identical shape: a solution scoped to a permanent-impairment requirement ends up serving a far larger group who encounter the same barrier temporarily or situationally. Citing the curb-cut effect by name is a fast, concrete way to make the inclusive-design argument land with a non-designer stakeholder, because it's a physical example almost everyone has personally benefited from without noticing.

The "How Would You Make This Accessible" Interview Prompt: A Worked Example

A frequent live-interview exercise: you're shown a generic custom dropdown/select component — a styled <div> that opens a list of options on click, built from scratch instead of a native <select> because the design called for a visual treatment the native element can't achieve. "How would you make this accessible?" Walking through the concrete gaps and fixes, not a list of abstractions:

Before diagnosing the widget itself, it helps to name the general method out loud, since interviewers are partly evaluating whether you have a repeatable process rather than a memorized answer for this one component: check what a keyboard-only user can and can't reach, check what a screen reader announces at each step, and check every state change (open/closed, selected/unselected) against whether it's actually communicated to assistive technology — not just visually.

Gap 0 — The field itself has no accessible name. As built, the whole control (trigger plus hidden list) may have no association with the visible field label sitting next to it ("Country," "Sort by") — a sighted user infers the connection visually, but nothing in the markup ties the two together. Fix: associate the label explicitly, either with a real <label for="..."> pointing at the trigger's id (if it's a real <button>) or aria-labelledby pointing at the label element's id — without this, a screen-reader user who reaches the control by navigating field-by-field hears "combobox, collapsed" with no indication of which field it even is.

Gap 1 — Keyboard operability. As built with only a click handler, the dropdown can be opened only by mouse. Fix: the trigger must be a real <button> (or a <div> with tabindex="0" and manually wired keydown handlers, though a real button is simpler and safer), openable with Enter or Space; once open, Arrow Up/Down must move through the option list, and Escape must close it and return focus to the trigger.

Gap 2 — Focus management. As built, focus likely stays on the trigger (or gets lost entirely) when the list opens, and nothing moves focus back when it closes. Fix: when the list opens, move focus to the currently selected option (or the first option); when the user selects an option or presses Escape, close the list and return focus explicitly to the trigger button — a screen reader or keyboard user who loses track of focus has effectively lost the interface, even if it's still fully rendered on screen.

Gap 3 — ARIA role and expanded state. As built, the trigger is a styled <div>, invisible to the accessibility tree as an interactive control, and there's no indication the list is a dropdown or whether it's currently open. Fix: the trigger needs role="combobox" (or, if built as a real <button>, the button role is free) with aria-expanded="true"/"false" toggling as the list opens and closes, and aria-haspopup="listbox" so a screen reader announces it as a control that opens a list before the user even activates it.

Gap 4 — Screen-reader announcement of selection. As built, selecting an option silently updates the visual text on the trigger with no announcement — a screen-reader user gets no confirmation the selection changed unless they happen to re-focus the trigger and have it re-read. Fix: the selected option needs aria-selected="true" within the list (role="listbox" / role="option" on the items), and the trigger's accessible name should update to reflect the new selection so it's announced on the next interaction — some implementations pair this with a live region for an explicit "X selected" announcement at the moment of selection, rather than relying only on the next focus event.

The pattern across all five gaps is the same one from the ARIA section above: a native <select> gets a label association, keyboard support, focus handling, role, state, and announcement for free from the browser; rebuilding it as a styled <div> means manually re-implementing every one of those behaviors, and each one skipped is a distinct, separately-diagnosable point of failure. The strongest interview answer names the gaps in this itemized way — what's missing, why it matters, what specifically fixes it, tied back to the exact ARIA attribute or keyboard behavior involved — rather than a single blanket "add ARIA attributes," which signals the vocabulary without the underlying mechanism.

Quick Reference: Common Anti-Patterns

A compact list worth keeping in mind walking into a component review or an interview — each of these ties back to a rule covered above:

This subject's throughline is the same across every section: accessibility rules are precise enough to test, and the interview prompt "how would you make this accessible" rewards a candidate who can walk from a specific, named gap to a specific, named fix — not one who can only gesture at the general idea that accessibility matters. The same throughline carries into the rest of this track: interaction-design-principles covers the interaction patterns these keyboard and focus rules build on, and responsive-and-mobile-design picks the situational-impairment thread back up in the context of touch targets and small screens.