Accessibility foundations

Prefer native semantics

Choose the HTML element whose built-in meaning and behavior match the interaction before adding ARIA.

9 minute lesson

~~~

Links navigate, buttons perform actions, headings structure content, and labels name controls. This is a small part of a deliberately flawed event-registration page that is audited, repaired, and retested with real evidence, but the boundary it creates affects everything that follows.

Native elements carry semantics, focus behavior, keyboard activation, forms integration, and platform support. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to rebuild a native control from generic elements and repair each missing behavior manually. It makes later failures harder to locate. Instead, start with native HTML, add ARIA only for a missing semantic, and never contradict the host element. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Frame accessibility around successful user tasks and inspect what browsers expose to assistive technology. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Replace three generic interactive elements on the flawed page and list the code you could delete. Hand the result to someone else and see whether the behavior is clear without an oral explanation.

Lesson completed

Take this course offline

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

Get the download library →