Question 1

What makes an accessible name for a control?

Accepted Answer

Visible label, aria-label, aria-labelledby, or native labeling associations. Prefer visible label for. aria-label overrides and can hurt i18n if not translated. Decorative icons need careful naming so buttons aren't silent.

Question 2

Why are clickable

s an accessibility problem?

Accepted Answer

They lack button semantics, keyboard activation, and often focus styles. Use button or a href. If unavoidable, add role, tabindex, key handlers, and focus styles — still inferior to native.

Question 3

Explain alt text strategy for images.

Accepted Answer

Describe purpose: informative alt, empty alt for decorative, avoid 'image of'. Linked images need alt that describes destination/purpose. Complex charts need long descriptions nearby. CSS background images are invisible to AT.

Question 4

How does focus management work for modals?

Accepted Answer

Move focus into the dialog on open, trap tab within, restore focus on close. Use dialog element or a vetted pattern. aria-modal and labels required. Background should be inert. Escape closes.

Question 5

What is the difference between aria-hidden and the hidden attribute?

Accepted Answer

hidden removes from presentation and usually the a11y tree; aria-hidden hides from AT but may remain focusable if misused. Never aria-hide focusable elements without removing them from tab order. Prefer hidden/inert for closed UI.

Question 6

How do you make a custom checkbox accessible?

Accepted Answer

Prefer native input type=checkbox; if custom, sync aria-checked, roles, keyboard Space. Visible label, focus ring, and form participation matter. Custom controls often break with forms and AT.

Question 7

What are skip links and why do they matter?

Accepted Answer

First focusable link to jump to main content, reducing repetitive tabbing. Must be visible on focus. Target should be focusable (tabindex=-1 on main).

Question 8

How do you handle accessible error messages in forms?

Accepted Answer

Associate errors via aria-describedby; use aria-invalid; move focus to first error on submit. Don't rely on color alone. Announce via live regions carefully for async validation.

Question 9

Contrast and focus visibility — what do you check?

Accepted Answer

Text contrast ratios and a clearly visible :focus-visible style that isn't outline:none without replacement. WCAG targets depend on size. Dark themes still need contrast. Keyboard users must see focus.

Question 10

What is a live region and when is it dangerous?

Accepted Answer

aria-live announces dynamic updates; overuse causes noisy interruptions. Use polite for non-critical updates, assertive sparingly. Don't put entire pages in live regions.

Question 11

How would you accessibility-test a SPA route change?

Accepted Answer

Update document title, manage focus to a heading, ensure landmarks refresh, avoid focus loss. Screen reader users need confirmation of navigation. Routers often forget focus management.

Question 12

Describe keyboard interaction for a tabs widget.

Accepted Answer

Arrow keys move among tabs; Tab moves into tabpanel; aria-selected and roles required. Prefer established patterns. Ensure panels are labeled by tabs. Don't only support click.

Question 13

How do you build an a11y culture on a frontend team?

Accepted Answer

Design system primitives with a11y baked in, linting, CI axe checks, manual AT passes, acceptance criteria. Component libraries prevent rework. Train designers on focus order and labels. Budget time for audits on critical flows.

Accessibility HTML Interview Questions

Other HTML interview topics