Creating accessible web pages requires combining semantic HTML with ARIA (Accessible Rich Internet Applications) attributes to ensure all users, regardless of ability, can navigate and understand your content. Semantic HTML provides the structural foundation by using meaningful tags like ``, ``, ``, and `` instead of generic divs, which helps screen readers and assistive technologies understand the page’s layout and content hierarchy. ARIA attributes then enhance this foundation by adding additional context and interactivity information that semantic HTML alone cannot convey, such as live regions that announce dynamic content changes or roles that clarify complex widgets.
The combination of these two approaches isn’t about choosing one over the other—it’s about using them together strategically. For example, a form with required fields benefits from semantic HTML’s ``, `` elements paired with ARIA attributes like `aria-required=”true”` and `aria-describedby` to provide redundant, clear information to all users. Without semantic HTML, ARIA becomes a patch on top of inaccessible markup. Without ARIA, semantic HTML alone cannot handle interactive components like modals, tabs, or custom dropdowns that require additional accessibility announcements.
Table of Contents
Semantic HTML is the starting point for any accessible website because it communicates meaning to both machines and humans. When you use `` instead of ``, browsers and assistive technologies immediately recognize it as an interactive control, keyboard-accessible by default, with the proper role and name exposed to screen readers. Similarly, `
` landmarks help screen reader users skip to navigation, `` clearly identifies primary content, and `` or `` elements organize related content into logical regions. The practical benefit goes beyond just screen readers. A semantic button element receives native keyboard support (Space and Enter keys), focus management, and correct ARIA roles without any extra code.
A div styled as a button requires JavaScript to add those features, creating complexity and potential gaps in functionality. Real-world example: an e-commerce site using proper `` elements for “Add to Cart” will work correctly with keyboard navigation, while one using styled divs may trap keyboard users or fail to announce the action to screen reader users. One limitation to keep in mind: semantic HTML alone cannot communicate all the nuances of complex, interactive components. A custom date picker or autocomplete field built with semantic HTML still needs ARIA roles like `combobox` and properties like `aria-expanded` and `aria-controls` to function accessibly. The semantic foundation is necessary but insufficient for modern, interactive user interfaces.
Understanding ARIA Roles, Properties, and States in Depth
ARIA divides into three categories: roles (what something is), properties (static characteristics), and states (current conditions). Roles like `menuitem`, `tab`, `slider`, and `grid` tell assistive technologies what interactive pattern the element follows, allowing screen reader users to understand how to interact with it. For example, a `role=”tab”` element signals that arrow keys will switch between tabs, not that screen reader users should tab through each option individually. Properties like `aria-label`, `aria-describedby`, and `aria-owns` provide additional information or relationship details that HTML alone cannot express. States like `aria-selected`, `aria-disabled`, and `aria-expanded` communicate the current condition, and JavaScript must update these values when state changes. A critical limitation is that ARIA doesn’t change a page’s functionality—it only communicates functionality to assistive technologies. If you add `aria-expanded=”false”` to a div but don’t actually hide the panel with CSS or JavaScript, a screen reader will announce that the panel is collapsed while it remains visibly open, creating confusion.
ARIA is a communication layer, not a replacement for actual DOM management and styling. Warning: overusing ARIA can actually harm accessibility. If you add `role=”button”` to a clickable span but fail to add keyboard event listeners, you’ve created the illusion of accessibility without the substance. The most common mistake is using ARIA to fix broken HTML instead of fixing the HTML itself. Rather than adding `role=”button”` to a styled div, use a real ``. Rather than adding `role=”image”` to a decorative div, use an `
Web Accessibility Issues by Type Missing Alt Text 28% Unlabeled Form Fields 22% Low Color Contrast 18% Missing ARIA on Interactive Elements 17% Keyboard Navigation Failures 15% Source: WebAIM Accessibility Survey 2024
Making Complex Components Accessible with ARIA
Complex interactive components like accordions, carousels, and autocomplete dropdowns require careful ARIA implementation to communicate their behavior. An accordion needs `role=”button”` or semantic `` elements, `aria-expanded` to announce whether each section is open, and `aria-controls` to link the button to the content panel it controls. When a user expands a panel, JavaScript must update `aria-expanded=”true”` and ensure the associated panel is visible and in the DOM. A real-world example is a multi-step form wizard. Each step needs clear labeling with `aria-current=”step”` to announce which step is active, and dynamically updated content that screen readers can announce.
A carousel requires `role=”region”`, `aria-live=”polite”` or `aria-live=”assertive”` depending on whether announcements should interrupt, `aria-label` to identify the carousel region, and careful management of which slide is actually in focus. Without this structure, keyboard and screen reader users cannot understand what’s happening when slides change or whether the carousel is interactive. The implementation complexity increases with custom widgets. A combobox (autocomplete field) needs `role=”combobox”`, `aria-controls` pointing to the listbox of options, `aria-expanded` to communicate whether the list is open, and `aria-activedescendant` to announce which option is currently highlighted as the user navigates. Each of these must be updated dynamically as the user types and navigates, creating a more complex JavaScript implementation than a native select element.
Practical Implementation: Step-by-Step Approach to Adding Semantic HTML and ARIA
Start by auditing your page’s structure: replace all `
` elements used for layout with semantic equivalents like `
