What accessibility essentials do you build into every page?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Semantic landmarks and headings, alt text on meaningful images, labeled form controls, visible focus states, sufficient contrast (4.5:1 text), keyboard operability, logical DOM order, and ARIA only when semantics fall short.
Detailed explanation
Accessibility is a practice, not a checklist bolted on late. Structure first: one h1, hierarchical headings, landmark regions so screen reader navigation works. Images need alt reflecting purpose (decorative ones get empty alt="" to be skipped). Every interactive element must be reachable and operable by keyboard — which semantic HTML gives mostly free; custom widgets demand full keyboard patterns and focus management (modals trap focus, return it on close). Focus indicators must stay visible — outline: none without replacement fails WCAG. Contrast ratios: 4.5:1 normal text, 3:1 large text/UI components. Labels belong to inputs via <label for>/aria-labelledby; error messages connect via aria-describedby. ARIA rule number one: prefer native elements; ARIA adds roles/states only where HTML can't express them (tab panels, live regions). Test cheaply: unplug the mouse, run Lighthouse/axe, try a screen reader once monthly.
Example
<!-- Label association -->
<label for="email">Email</label>
<input id="email" type="email" aria-describedby="email-hint" />
<p id="email-hint">We never share your email.</p>
<!-- Decorative image skipped by readers -->
<img src="divider.svg" alt="" />
<!-- Visible focus -->
<style>
:focus-visible { outline: 2px solid indigo; outline-offset: 2px; }
</style>Interview tip
Pick 4–5 practices and explain WHY each matters (who benefits), then say 'ARIA last, semantics first.' Mentioning axe/Lighthouse testing shows operational habit.
Common mistakes
- Treating ARIA attributes as decoration without behavior.
- Removing focus outlines without alternatives.