Search for a command to run...
Building an Inclusive Web: From Semantic Markup to ARIA Mastery
I am an aspiring web developer on a mission to kick down the door into tech. Join me as I take the essential steps toward this goal and hopefully inspire others to do the same!
No comments yet. Be the first to comment.
Step-by-step guide: Master web dev from HTML/CSS basics to Web Components. Learn semantic markup, accessibility, responsive design, DOM manipulation, custom elements, Shadow DOM, and reusable UI patterns for real-world apps.
Best Practices & Real-World Examples
My Life-Long PC Building Adventure
Where Innovation Meets Standardization
Advanced Patterns for Web Components in Modern Frameworks
Leveraging Custom Elements for Scalable and Maintainable Web Applications
Ensuring Inclusivity in Custom Elements
Accessibility is a cornerstone of modern web development. By writing accessible HTML and using ARIA (Accessible Rich Internet Applications) appropriately, we ensure that our website can be used by everyone—even those relying on assistive technologies like screen readers or keyboard navigation. In this article, we’ll cover:
Writing Accessible HTML: Proper use of labels, alt text, and headings.
Introduction to ARIA: When to use it, its “5 Rules,” and common pitfalls.
Best Practices for Links, Forms, and Landmarks: How to create intuitive and accessible interactive elements.
Creating accessible HTML means using elements and attributes in a way that provides clear meaning and structure for both browsers and assistive technologies.
Label Elements:
Always associate form controls with a <label>. This ensures that screen readers announce what each control is for. For example:
<label for="username">Username:</label>
<input type="text" id="username" name="username">
Wrapping Technique:
If we want to wrap the input, we can also do so by:
<label>
Email:
<input type="email" name="email">
</label>
See the difference proper label association makes for accessibility. In this example, try clicking on the labels in both examples and notice how only properly associated labels focus their corresponding input fields.
Descriptive Alt Text:
For meaningful images, include a clear alt attribute:
<img src="team-photo.jpg" alt="Our team celebrating the product launch">
Decorative Images:
If an image is purely decorative, use an empty alt attribute to ensure it is skipped by screen readers:
<img src="decorative-pattern.jpg" alt="">
This interactive demo simulates how a screen reader interprets images with and without proper alt text. Click on each image to hear what would be announced to screen reader users.
Hierarchical Headings:
Use headings (<h1> to <h6>) in order to create a clear document outline. For instance, a single <h1> should represent the page title, followed by <h2> for major sections, <h3> for subsections, and so on.
<h1>About Our Company</h1>
<h2>Our Mission</h2>
<h3>Our History</h3>
Consistency is Key:
Avoid skipping heading levels to ensure that users can navigate the page easily via their assistive technology.
Experience how screen reader users navigate through a page using headings. This simulation shows how proper heading hierarchy creates an accessible document outline.
ARIA is a powerful tool that helps enhance the accessibility of web applications, especially when native HTML elements alone are not sufficient.
This custom dropdown demonstrates how to make complex interactive components accessible using ARIA attributes and keyboard interaction patterns.
Supplement, Don’t Replace:
ARIA should be used to enhance the semantics of non-standard UI components or dynamic content that isn’t easily expressed using native HTML. For example, if we wanted to build a custom dropdown menu with <div> elements, we should add ARIA attributes to indicate its role and state.
<div role="combobox" aria-expanded="false" aria-haspopup="listbox">
<input type="text" aria-autocomplete="list">
</div>
Fallback First:
Always use native HTML elements with built-in accessibility features first. Use ARIA only when there’s no alternative.
This interactive example demonstrates how ARIA roles affect screen reader announcements. Toggle between the native HTML elements and non-semantic elements with ARIA roles to understand the difference.
Do Not Use ARIA When Native HTML Works:
If an HTML element already has the semantics we need, don’t override it. For instance, use a <button> instead of a <div> with role="button".
Do not change native semantics:
Avoid overriding default behaviors. For example, we should not change a <button> into a heading by adding role="heading".
Ensure Keyboard Usability:
All interactive elements enhanced with ARIA must be fully operable via the keyboard.
Avoid Hiding Focusable Elements:
Never use aria-hidden="true" or role="presentation" on elements that must remain focusable.
Provide an Accessible Name:
Every interactive element should have an accessible name using text content, aria-label, or aria-labelledby.
Overusing ARIA:
Adding ARIA roles and properties to elements that already have native semantics can confuse assistive technologies.
Incorrect Role Assignments:
Ensure that the ARIA role we assign matches the behavior we want to implement. For example, using role="button" on a non-interactive element without keyboard event handlers can lead to a broken experience.
Dynamic State Management:
When updating interactive elements (e.g., toggling aria-expanded), make sure the changes are kept in sync with the visual state.
Test your understanding of the 5 ARIA rules. Review these examples and determine whether each follows or violates the ARIA rules. Click to see the explanation.
Descriptive Link Text:
Avoid generic text like “click here.” Instead, describe the destination or action:
<a href="/about-us">Learn more about our company</a>
Indicating External Links:
If a link opens in a new tab, inform users with additional text or an ARIA attribute. We can do this by providing an ARIA attribute of aria-popper="new-tab". This attribute informs assistive technologies like screen readers that clicking the link will open it in a new tab or window.
Next, we should provide an ARIA label like this: aria-label="Link to external site (opens in new tab)".This provides text information, telling users both where the link leads and how it behaves.
<a
href="/about-us"
aria-label="Link to external site (opens in new tab)"
aria-popper="new-tab">
External Link (opens in new tab)
</a>
Compare generic link text with descriptive alternatives. This example shows how screen reader users experience different approaches to link text.
Labels and Fieldsets:
Use <label> elements for inputs and group related form controls with <fieldset> and <legend>.
<fieldset>
<legend>Personal Information</legend>
<label for="fname">First Name:</label>
<input id="fname" type="text">
</fieldset>
Error Handling:
When a form error occurs, provide clear feedback. Use ARIA attributes like aria-invalid and aria-describedby to connect error messages to their corresponding fields.
To implement clear feedback for form errors using ARIA attributes, follow these steps:
Add Required Attribute: Include required in each form element that needs validation.
Validation Handling: Use JavaScript or server-side processing to trigger validation and check if fields are filled correctly. (We will cover this in a later article)
Mark Invalid Fields: For each invalid field, set the aria-invalid attribute to "true" on the corresponding <input> element.
Place Error Messages: Position error messages immediately after their respective fields for easy association.
ARIA Descriptions: Use aria-describedby on error messages to associate them with their corresponding form fields. Set the aria-describedby attribute's value to the id of the field it describes.
Here is an example:
<div class="form-group">
<input type="text" id="name" name="name" required aria-invalid="true">
<div class="error-message" aria-describedby="name">Name is required.</div>
</div>
<div class="form-group">
<input type="email" id="email" name="email" required aria-invalid="false">
<div class="error-message" aria-describedby="email">Please enter a valid email address.</div>
</div>
Experience how proper error handling improves accessibility. This example demonstrates accessible form validation techniques using ARIA attributes.
Use HTML5 Landmark Elements:
Elements like <header>, <nav>, <main>, <aside>, and <footer> create natural navigation landmarks for screen readers.
ARIA Landmark Roles:
If we must use non-semantic elements (like <div>), we should assign them landmark roles such as role="navigation" or role="main". However, native elements are preferred.
<div role="navigation">
<!-- navigation links -->
</div>
Consistent Structure:
Ensure that landmarks are used consistently across our site to provide a predictable structure for users.
Keyboard shortcuts aren't just for power users – they're a critical accessibility feature that can make your web applications more inclusive and efficient. By implementing thoughtful key commands, we can:
Reduce reliance on precise mouse movements for users with motor impairments
Speed up navigation for repetitive tasks
Create parity with native application experiences
The JavaScript snippet below demonstrates a clean implementation of landmark navigation using three simple shortcuts:
D → Next element
U → Previous element
T → Cycle filter categories
This pattern follows WCAG guidelines by:
✅ Using non-conflict key combinations
✅ Providing visual feedback
✅ Supporting both keyboard and mouse inputs
Accessible web design isn’t just about compliance—it’s about creating an inclusive experience that benefits everyone. By writing accessible HTML with clear labels, descriptive alt text, and a logical heading structure, we lay the groundwork for a website that is easy to use. Complement this with thoughtful ARIA usage following its “5 Rules,” and we can avoid common pitfalls while enhancing the accessibility of links, forms, and landmarks. Start applying these best practices today, and build a web that truly works for all users.