Accessible progressive UI

Keep semantics in sync

Update aria-expanded, hidden state, labels, errors, and focus together with visual state.

9 minute lesson

~~~

Before choosing a tool or writing more code, make the requirement concrete. The edit disclosure is a button controlling a named region and communicates its expanded state on every transition.

Reactive visibility is only one part of an accessible interaction; name, role, value, state, and focus must agree. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to change classes while leaving accessibility attributes and focus on stale elements. The happy path may still work, which makes the mistake easy to miss. start from the native interaction pattern and bind every relevant semantic state from the same source value. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Finish the issue board as a progressively enhanced interface that remains understandable with keyboard, assistive technology, slow networks, and JavaScript failure. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Inspect the accessibility tree and use the complete board without a mouse. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →