Lesson 4
Accessibility & responsive UI
Build a practical mental model for accessibility & responsive ui and use it in working JavaScript.
By the end, you will be able to…
- Explain accessibility & responsive ui in your own words
- Use accessibility & responsive ui in a small program
- Recognize and debug a common failure mode
Build the mental model
Accessible UI works for keyboard-only users and screen readers, not just a mouse and perfect eyesight: every interactive element needs a visible focus state and a clear accessible name. Responsive UI adapts layout to the viewport instead of assuming one screen size.
Syntax and working example
Read the code from inputs to output. Predict what it prints, then run it and change one value.
Why this matters
Accessibility is both a real legal requirement in many contexts and simply correct: a meaningful fraction of users rely on these affordances daily.
Real-world example
A modal dialog trapping focus and being closable with Escape is standard accessible-UI behavior in production apps.
Common mistakes
- Using a <div> with a click handler instead of a real <button>, losing keyboard support for free
- Icon-only buttons with no aria-label, announcing nothing meaningful to screen readers
- Removing focus outlines with CSS without providing any visible alternative
Try it yourself
Challenge
Write buildAriaLabel(action, itemName) producing a clear accessible label string.
Knowledge check
Why prefer a real <button> element over a <div> with a click handler?
Summary
Use semantic elements, label icon-only controls, keep focus visible, and design layouts that adapt to any viewport.