Web Accessibility and Semantic HTML
The Web Accessibility and Semantic HTML domain tests WCAG-driven practice: whether every user can perceive, operate and understand the interface, including people using keyboards and assistive technology.
Principles and thresholds
WCAG is organised by POUR - perceivable, operable, understandable, robust - with levels A, AA and AAA; most legal requirements reference AA. Normal text needs 4.5:1 contrast, large text (≥24px, or ≥18.66px bold) 3:1, and UI component boundaries plus meaningful graphics 3:1. Content must reflow at 320px, survive 200% text zoom, and stay keyboard operable with a visible focus indicator.
Names and roles
Prefer native elements: <button> already supplies keyboard activation, focus behaviour and a role. The accessible name comes from <label for>, aria-label or aria-labelledby, falling back to element content. alt describes the purpose of informative images; alt="" plus aria-hidden="true" removes decorative ones. aria-hidden must never wrap focusable content.
Forms and feedback
Link every control to a <label>, group related inputs with <fieldset>/<legend>, point at error text with aria-describedby, and set aria-invalid="true". Live regions (aria-live="polite", or role="alert" for assertive) announce updates without moving focus.
Worked example
An icon-only close control: <button type="button" aria-label="Close dialog"><svg aria-hidden="true" focusable="false">…</svg></button>. The native button handles keyboard and focus, aria-label supplies the name, and hiding the SVG prevents a meaningless graphic being announced.
Traps
Removing focus outlines, using placeholders as labels, writing aria-label text that drops the visible label wording (a 2.5.3 mismatch), and assuming a <div onclick> is keyboard accessible.