Frontend
Accessibility
Building interfaces usable by everyone, including people relying on screen readers, keyboards or high contrast — through semantic HTML, ARIA where needed, focus management, alt text and sufficient colour contrast (WCAG 2.1 AA). It is often a legal requirement and better UX for all. Most of the wins come free from correct, semantic markup.
Purpose
Accessibility (a11y) makes interfaces usable by everyone — including people who rely on screen readers, keyboard navigation, captions or high contrast. The standard to design against is WCAG 2.1 AA: perceivable, operable, understandable, robust.
When to Use It
It applies to every interface, and in many jurisdictions and public-sector contracts it is a legal requirement. The same work improves everyone's experience: keyboard support helps power users, contrast helps sunlight readability, captions help viewers in noisy rooms.
Trade-offs
Retrofitting accessibility onto a finished app is expensive; building it in as you go is nearly free, because most of it falls out of correct semantic HTML. Misused ARIA is worse than none — role attributes that promise behaviour the element does not deliver actively mislead screen readers.
Implementation
Use native elements first — a <button> is focusable, announced and keyboard-operable for free. Ensure every interactive element is reachable and visible on focus, every image has meaningful alt text, forms have labels, and contrast meets AA ratios. Test with a keyboard only, then with a screen reader, and run automated checks (Lighthouse, axe) in CI.