Accessibility Foundations
Accessibility is not a distinct feature of the web. Instead, it directly results from how HTML is written and how interfaces are structured. When development treats accessibility as a foundational principle, many benefits accrue naturally through correct semantic structure.
Accessibility starts with structure, not ARIA
ARIA (Accessible Rich Internet Applications) provides attributes that add semantic information where native HTML alone proves insufficient. This includes components like custom dropdowns, complex widgets, or interactive elements that do not map cleanly to standard form controls.
A common misconception suggests that accessibility starts with ARIA attributes. In reality, it begins with semantic HTML. Browsers and assistive technologies inherently understand native HTML elements. For instance, elements like headings, landmarks, labels, buttons, and form controls all provide built-in behavior and meaning.
ARIA should extend existing semantics only when necessary, not replace native HTML elements already suitable for a given task. A useful rule of thumb remains: “If a native HTML element exists for the job, use it before reaching for ARIA.”
Headings as navigation, not decoration
Headings are one of the primary navigation tools for screen reader users. Assistive technologies allow users to jump between headings, skip sections, and understand page structure without reading every word. This only works when headings reflect true hierarchy.
Consider this page outline:
<h1>Accessibility Foundations</h1>
<h2>Headings</h2>
<h2>Landmarks</h2>
<h2>Forms</h2>
A screen reader user can navigate this page efficiently. If headings are skipped, misused, or chosen based on visual size, that navigation breaks down. This is why headings should express structure, not appearance as visual styling belongs to CSS.
Landmarks and page regions
Landmarks help users understand the large-scale structure of a page. They define where things are, not just what they look like.
Elements such as <header>, <nav>, <main>, <aside>, and <footer> create recognizable regions that assistive technologies can jump between. Screen reader users often navigate pages by moving directly from landmark to landmark, rather than reading everything in order.
A typical page structure might look like this:
<header>
<nav>
<!-- site navigation -->
</nav>
</header>
<main>
<!-- primary page content -->
</main>
<footer>
<!-- supplementary information -->
</footer>
This structure allows users to skip repeated content, such as navigation menus, and move directly to what they need.
Landmarks also reduce the need for custom “skip links” in many cases, because assistive technologies already understand these regions and expose them as navigation shortcuts.
One important constraint: Landmarks should be used sparingly and intentionally. A page should have one primary <main> region, and landmarks should reflect meaningful structure, not visual layout. Overusing them can be just as confusing as not using them at all.
Forms: Labels are not optional
Forms are one of the most common places where accessibility breaks down. Every form control must have an accessible name. In most cases, this is achieved with a <label> element.
<label for="email">Email address</label>
<input id="email" type="email" />
This association is critical. It allows screen readers to announce what the input is for, and it improves usability for all users by increasing the clickable area. A second valid pattern is to wrap the input inside the label:
<label for="email">Email address
<input type="email" />
</label>
Placeholder text is not a replacement for labels. Placeholders disappear as users type and are not consistently announced by assistive technologies. Well-labeled forms are not just more accessible; they are more usable and less error-prone.
Clear intent: Buttons vs. links
Interactive elements must communicate intent clearly. For example, a <button> represents an action. It triggers behavior within the current context, such as submitting a form, opening a dialog, or saving data. Whereas, a <a> (link) represents navigation. It takes the user to a new location, whether that is another page, a different section, or an external resource.
Mixing these roles creates confusion. Screen readers announce buttons and links differently, and users form expectations based on those announcements. When an element behaves differently than its semantic role suggests, the interface becomes harder to understand.
For example:
<button>Submit form</button>
<a href="/dashboard">Go to dashboard</a>
Here, the intent is clear without any visual styling. One element performs an action; the other moves the user to a new location.
Text clarity matters just as much as element choice. Generic phrases like “Click here” or “Learn more” lose meaning when links are read out of context, which is how many screen reader users navigate pages.
Keyboard accessibility is not optional
Not all users navigate with a mouse or touch screen. Some users rely entirely on a keyboard, either by preference or necessity. A keyboard-accessible interface must allow users to:
- Tab through interactive elements
- See where focus currently is
- Activate controls using standard keys
Native HTML controls automatically support this. Developers often introduce problems by replacing native elements with custom components that do not preserve essential keyboard behavior.
If an element is clickable, it must also be focusable and operable via keyboard. Keyboard users rely on visible focus indicators to orient themselves on the page. Removing focus outlines without providing a clear alternative constitutes a common accessibility failure. When focus styles are customized, they must remain clearly visible.
This isn’t merely about aesthetics. It is fundamentally about orientation and control. Users who cannot see focus indicators cannot reliably use the interface.
Accessibility as a habit, not a checklist
Accessibility is not something you “add at the end.” It emerges naturally when you:
- Write semantic HTML.
- Use headings and landmarks correctly.
- Label form controls.
- Rely on native elements for interaction.
- Test with a keyboard occasionally.
These habits dramatically reduce the need for complex fixes later.
A practical test
A straightforward approach to assessing fundamental accessibility involves testing the page as many users actually experience it:
- First, navigate the page exclusively with a keyboard. Every interactive element must be reachable, and focus should always be clearly indicated. If you become trapped within a component, lose focus, or cannot activate a control, the interface fails to be keyboard-accessible.
- Next, examine the page’s structural outline by navigating through its headings. The resulting outline should appear logical, with heading levels accurately reflecting semantic hierarchy rather than mere visual styling.
- Finally, test any forms using a screen reader or by inspecting the browser’s accessibility tree. Inputs must possess meaningful labels, buttons should clearly describe their actions, and error messages must be readily understandable.
If the page proves usable without a mouse and comprehensible without its visual layout, its core accessibility foundation is likely robust.
Popular Guides