The web is an indispensable source of information and knowledge, which has transformed how we work, access entertainment, and handle important daily activities like banking. One key characteristic of the web is its ubiquity. We can access information from many types of devices, including personal computers and smartphones. As designers, we must ensure our web designs are accessible across all these devices.
The web content you access daily using your browser (e.g., Google Chrome, Firefox) is predominantly structured with HyperText Markup Language (HTML). HTML is a markup language, which means that your web browser parses the document written in HTML, creates a document object model (DOM) tree, and renders it as a visual webpage in your browser. That is, you write a text file in HTML that look something like:
<!DOCTYPE html>
<html>
<body>
<h1>My First Heading</h1>
<p>My first paragraph.</p>
</body>
</html>
Elements enclosed in brackets (<>) are called HTML tags. Your browser translates them into a visual webpage like:
A browser translates the HTML into DOM tree, which gets rendered as a webpage like what is shown in the figure.
How you write and structure HTML—the source code for a webpage—impacts its accessibility in multiple ways. These include information architecture and how assistive technologies help users navigate web interfaces, HTML tag semantics and ARIA, forms and interactive components, and responsive design considerations like reflow. There are also other factors like providing alt text and video captions that impact web accessibility. However, I will focus less on these universal accessibility issues that aren't specific to the web (as I've touched on those universal topics in earlier lecture notes), and more on web-specific accessibility topics in this lecture note.
When designing a web page, one thing to note is its information architecture (IA). IA matters not only for readability and ease of finding information that we often discuss in UI and UX design, but also for how you structure information in HTML for better accessibility. Good IA makes assistive-technology navigation predictable.
A key principle is that the DOM order should match the intended reading order. Screen readers and keyboard users experience the page in the same sequence as the DOM, even when CSS visually rearranges content. Web pages with layouts heavily modified by CSS that don't match the natural DOM flow create documents that are hard to navigate: the page looks correct but reads incorrectly. When you press Tab to navigate through the page, focus doesn't move in a sensible sequence.
Beyond using sensible reading order, proper **headings and landmarks** make keyboard and screen reader navigation easier. While headings may appear as just visual styling to sighted users, they provide an outline that screen reader users rely on to scan and navigate content. Clear, descriptive headings with a logical hierarchy (e.g., h1 followed by h2, avoiding jumps) enable efficient movement through content. Similarly, landmarks like header, nav, main, aside, and footer let screen reader users jump directly to major sections without stepping through everything.
Managing focus is essential for keyboard-based navigation. Two key techniques improve accessibility: skip links and the **inert attribute**. Skip links like "Skip to main content" let keyboard users bypass repeated headers and menus, reducing navigation effort and allowing them to jump directly to the primary content. When the interface changes dynamically and some elements become invisible or should not be interacted with, you can use the inert attribute to manage focus intentionally. When applied, an inert element and all its descendants become non-interactive and they cannot receive focus, are removed from the tab order, and are ignored by assistive technologies. However, use careful consideration when applying the inert attribute; as a web developer, it is your responsibility to think which content should be active and which are inert in the application’s lifecycle.
Accessible web interfaces start with good HTML semantics. When the structure is correct, browsers and assistive technologies can infer meaning without extra work. Semantic HTML means choosing the most specific native element that matches your intent. For example, use button for clickable controls that trigger actions, a for navigation links, and appropriate form elements like input, select, and textarea for inputs. Using generic containers like div and span for interactive elements forces developers to manually recreate keyboard support and accessibility metadata. Semantic structure also means using headings, lists, and sections appropriately. Headings provide an outline, lists communicate grouped items, and sections represent thematic groupings with labels. A common mistake is confusing links and buttons. For example, using a clickable div for navigation or styling a link as a button for an in-page action breaks user expectations and often degrades keyboard and screen reader support.
Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that can add semantics when native HTML is not enough, especially for dynamic interfaces or custom widgets. The core idea is simple: a role describes what a component is (for example, role="progressbar"), while ARIA states and properties describe its current condition (for example, aria-valuenow, aria-valuemin, and aria-valuemax).
However, ARIA must be used carefully. The first rule of ARIA: don't use it when native HTML can express the same meaning. ARIA can override built-in semantics and create confusing or incorrect interpretations. ARIA helps when filling genuine semantic gaps—implementing a custom widget with no native equivalent, adding an accessible name to an icon-only button, or describing dynamic relationships between controls and content. It harms when roles are misapplied (for example, adding role="button" to an actual button), when attributes become stale and no longer reflect the UI, or when ARIA is used as a band-aid for poor HTML structure. A practical rule: start with semantic HTML, add ARIA only when needed, and validate with keyboard and screen reader testing.