HTML (HyperText Markup Language) is the standard for structuring web pages and their content. When used appropriately, it ensures that every user has an equivalent experience — regardless of whether they’re browsing on a desktop computer, a mobile device, or with assistive technology (AT).
Web accessibility begins with HTML. If your website has no structure, it’s not useful for people who use screen readers (software that converts text to audio or braille) and other AT.
When you think about accessibility when writing HTML, you can avoid common mistakes that affect the user experience. Here’s how to maintain an accessible mindset when creating your content.
If you’re new to web development, you might choose HTML elements based on how they look in Wordpress or another content management system (CMS). For example, many content creators choose certain subheadings for their visual appearance.
But the purpose of HTML is to define the structure of the page. This is called semantics, and it’s a crucial concept for ensuring that your website works well for every user — regardless of their user agent or the technologies they’re using to access your content.
To go back to our example, choosing the wrong level of subheading can create confusion for users. People will expect the subheadings to organize the page in a logical way, and when subheadings appear out-of-order, some users might get confused.
Use HTML to structure your page, then use CSS (Cascading Style Sheets) to perfect the visual appearance of the content.
Related: Plain Old Semantic HTML: A Perfect Basis for Accessibility
The <div> and <span> elements group pieces of HTML together, but they don’t have semantic meaning. That can be advantageous in certain situations, particularly if you’re building complex or dynamic content.
However, <div> and <span> are frequently misused. If you can use semantic HTML, use it — don’t default to <div> or <span>, even if you’ve learned how to use them effectively. That’s particularly important for buttons and other interactive elements.
Related: Accessibility Tips: Using the DIV and SPAN Elements
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications, often referred to simply as ARIA) is a set of roles and attributes that can be applied to HTML elements to define semantics.
While ARIA supports HTML, it’s not the same thing. Screen readers and other AT support ARIA, but their exact level of support varies. Even if you test your website with a screen reader, you can’t guarantee that it will work the same way with every screen reader and browser combination.
HTML is much more widely supported, and in the vast majority of situations, simple HTML is the better choice. Before using ARIA to define, consider these questions:
If you can’t answer those questions, don’t start writing ARIA markup just yet — work with your accessibility partner to find an appropriate solution. Poor ARIA implementation can make your website unstable or unusable for AT users.
Related: Introduction to ARIA for Web Accessibility
Text hyperlinks, buttons, and other elements that prompt user interaction are especially important for accessibility. Look at each element and ask questions:
Published by the World Wide Web Consortium (W3C), the Web Content Accessibility Guidelines (WCAG) contains a number of rules for writing HTML markup.
You should test your entire page frequently against WCAG Level A/AA success criteria, but interactive elements deserve special attention. By performing a quick check, you can at least ensure that your page is operable (though you’ll need to take a comprehensive look at your content to make sure that it provides a great experience for your users).
To learn more techniques for improving web accessibility, download our free eBook: The Ultimate Guide to Web Accessibility.