Introduction
Accessibility questions are appearing in more frontend interviews than ever—driven by legal exposure (ADA Title III lawsuits against websites have increased dramatically), increased auditor scrutiny, and a growing recognition that accessible code is simply better code.
Yet most engineers are underprepared. This guide covers the accessibility questions that frontend engineers encounter at companies like Shopify, Stripe, LinkedIn, and government contractors.
Foundational Questions
Q: What does WCAG stand for and what are its four principles?
WCAG stands for Web Content Accessibility Guidelines, published by the W3C. The four principles form the acronym POUR:
- Perceivable: Information must be presentable in ways all users can perceive (e.g., alt text for images, captions for video).
- Operable: Interface components must be operable by all users (e.g., full keyboard navigation, no seizure-triggering content).
- Understandable: Content and UI must be understandable (e.g., clear labels, predictable navigation, error descriptions).
- Robust: Content must be interpretable by a wide variety of user agents, including assistive technologies.
WCAG 2.1 AA is the most commonly required compliance level in the USA (referenced in ADA guidance and Section 508).
Q: What is the difference between WCAG A, AA, and AAA conformance levels?
- Level A: Minimum requirements. Failing these creates severe barriers.
- Level AA: The standard target for most websites. Covers the most impactful issues.
- Level AAA: The gold standard—often aspirational, as some criteria conflict with usability for non-disabled users.
Most legal standards and enterprise procurement requirements target Level AA.
HTML & Semantic Markup
Q: Why is semantic HTML important for accessibility?
Semantic elements communicate meaning to assistive technologies. A screen reader knows that a <nav> element contains navigation, a <button> is interactive, and a <h1> is the page's main heading—without any additional attributes needed.
<!-- ❌ Non-semantic: screen reader has no context -->
<div class="btn" onclick="submit()">Submit</div>
<!-- ✅ Semantic: screen reader knows this is a button, focusable by default -->
<button type="submit">Submit</button>
Non-semantic markup forces you to recreate browser behaviors manually (keyboard focus, role announcements) via ARIA—which is always a secondary option.
Q: When should you use ARIA and when should you not?
The first rule of ARIA: don't use ARIA if a native HTML element provides the semantics you need. ARIA supplements HTML; it does not replace it.
Valid ARIA use cases:
- Custom interactive widgets with no HTML equivalent (e.g., a combobox, a tree view, a tab panel).
- Marking up dynamic content updates (
aria-liveregions). - Adding labels where a visible label is not possible (
aria-label,aria-labelledby).
Common ARIA mistakes to mention:
role="button"on a<div>without also addingtabindex="0"and keyboard event handlers.- Using
aria-hidden="true"on focusable elements (hides from screen readers but not keyboard). - Redundant ARIA (
<button role="button">is noise).
Keyboard Navigation
Q: How do you ensure a custom dropdown menu is fully keyboard accessible?
A custom dropdown must support:
- Tab: Move focus to the trigger button.
- Enter/Space: Open the menu.
- Arrow keys: Navigate between menu items.
- Escape: Close the menu and return focus to the trigger.
- Tab (inside menu): Close and move focus to next interactive element.
This pattern is documented in the ARIA Authoring Practices Guide (APG) as the "Menu Button" pattern.
// React example: managing focus and keyboard events
function DropdownMenu() {
const [isOpen, setIsOpen] = useState(false);
const triggerRef = useRef(null);
const handleKeyDown = (e) => {
if (e.key === 'Escape') {
setIsOpen(false);
triggerRef.current?.focus(); // return focus to trigger
}
};
return (
<div onKeyDown={handleKeyDown}>
<button
ref={triggerRef}
aria-haspopup="true"
aria-expanded={isOpen}
onClick={() => setIsOpen(!isOpen)}
>
Options
</button>
{isOpen && (
<ul role="menu">
<li role="menuitem" tabIndex={-1}>Edit</li>
<li role="menuitem" tabIndex={-1}>Delete</li>
</ul>
)}
</div>
);
}
Q: What is a focus trap and when should you use one?
A focus trap constrains keyboard focus within a specific component—typically a modal dialog. Without it, users can Tab out of the modal into background content that is visually hidden by an overlay but still in the DOM.
Use a focus trap when: a modal, drawer, or dialog is open. Implement it using the focus-trap library or manually by intercepting Tab and Shift+Tab, looping focus between the first and last focusable elements.
Color, Contrast & Visual Design
Q: What contrast ratio is required for WCAG AA compliance?
- Normal text (<18pt or 14pt bold): 4.5:1
- Large text (≥18pt or ≥14pt bold): 3:1
- UI components and graphical objects: 3:1 against adjacent colors
Tools: Chrome DevTools color picker shows contrast ratio. axe-core and Lighthouse flag contrast failures automatically.
Q: Can you rely on color alone to convey information?
No—this violates WCAG 1.4.1 (Use of Color). Users with color blindness (affects ~8% of males) may not perceive color-coded information. Always supplement color with another indicator: shape, pattern, icon, label, or text.
Example: A red error border must also include an error icon and/or descriptive error text, not just the border color.
Testing for Accessibility
Q: What tools do you use to test accessibility?
Automated (catches ~30–40% of issues):
axe-core/axe-playwright(CI integration)- Lighthouse accessibility audit
- eslint-plugin-jsx-a11y (linting for React)
Manual (required for the remaining 60–70%):
- Screen reader testing: NVDA + Chrome (Windows), VoiceOver + Safari (macOS/iOS), TalkBack (Android)
- Keyboard-only navigation walkthrough
- Zoom to 200% and check layout integrity
- Color contrast checker (Colour Contrast Analyser desktop app)
Q: How do you write accessible forms?
<!-- Every input needs an associated label -->
<label for="email">Email address</label>
<input
type="email"
id="email"
name="email"
aria-required="true"
aria-describedby="email-error"
/>
<span id="email-error" role="alert">Please enter a valid email address.</span>
Key rules: explicit <label for="id"> pairing, error messages linked via aria-describedby, required fields marked with aria-required="true" AND visible indication, error states announced via role="alert" or aria-live="polite".
Summary
Accessibility is not an afterthought—it is a core engineering skill that demonstrates craftsmanship and legal awareness. Interviewers increasingly use a11y questions to assess code quality and attention to detail beyond algorithmic correctness.
Practice frontend interview questions on Interview Masters →