Tools like screen readers and keyboard alternatives help many people access the internet. But some websites aren’t optimized for these interactions. ARIA can help.
In 2023, 96% of website homepages failed to meet Web Content Accessibility Guidelines (WCAG), and only 30.8% had fewer than 10 web accessibility errors. This data means that on most websites, people with disabilities can’t access some (or any) information.
There are ways to address these concerns. Accessible Rich Internet Applications, or ARIA, help your website support assistive technologies. Including ARIA in your code tells screen readers and other tools how to interact with your website’s content and present it correctly.
Implementing ARIA sets your website apart and allows a broader audience to interact with your content. Let’s explore how to use ARIA and why it’s essential to the web development process.
What’s ARIA?
ARIA is a set of HTML roles and attributes that make websites more accessible to people with disabilities. The World Wide Web Consortium (W3C) created it under the Web Accessibility Initiative (WAI) in the early 2000s to address the lack of true web accessibility in website coding.
ARIA is a type of semantic HTML, which labels and defines the different parts of a website’s content within its code. Each piece of ARIA markup helps browsers and developers understand an element’s function. ARIA roles, states, and properties — elements in code that prompt ARIA functions — let developers adapt web pages for assistive technologies.
Many assistive tools, such as screen readers and voice control, better engage with websites when the HTML includes ARIA rules — telling a screen reader, for example, where a button is or what it does so visitors with visual disabilities can still use it.
Why use ARIA?
Using ARIA in your code gives a wider audience access to your content. It can also ensure your projects comply with web accessibility rules like the WCAG, another WAI best practice.
The WAI lists diverse abilities and barriers that could affect how different people experience the web. For example, someone with photosensitivity could have a negative reaction to flashing animations, while someone with an auditory disability might be unable to get information from a video that lacks captions.
To help you meet these accessibility design guidelines, ARIA builds on the foundation of semantic HTML by allowing a broader range of accessibility in navigation, form prompts, widget descriptions, and error messages, to name a few.
ARIA can’t make your website accessible to everyone, but it reduces the number of barriers within your code. It considers the needs of a wider audience without compromising site function, allowing more people to access your website’s content, read your blog, explore your portfolio, or complete whatever conversion you aim for.
How to use ARIA
To use ARIA, incorporate its roles and attributes into existing or new code. Here’s how to do so without complicating or breaking the website.
ARIA roles
ARIA roles are HTML attributes that apply to existing elements in HTML code. They name and identify these elements — forms, tables, images — so assistive technology can understand and display the elements correctly.
You can add these roles into HTML scripting using div tags and the role attribute to denote which page element the ARIA code highlights.
Each role has a different function, so make sure you’re using the right one. Mislabeling elements could break your code and negatively impact the user experience (UX).
These roles have four classifications:
- Abstract roles are what browsers use to lay the foundation for other roles. Examples include widget, landmark, window, and command
- Widget roles define user interface (UI) elements generally classified as widgets. Some common examples include alert, button, scrollbar, tab, and textbox
- Document structure roles describe the structures that organize web page content, such as article, toolbar, row, directory, and list
- Landmark roles are navigational landmarks within a page. Each role, application, form, and main applies to different page regions
ARIA states and properties
ARIA states and properties complement roles by offering more information about page functionality. States are a type of attribute that can change over time, while properties are less likely to change. Examples, which can be states and/or properties, include aria-describedby, aria-haspopup, aria-hidden, and aria-label.
These four attribute classifications define states and properties:
- Widget attributes apply to UI elements and support widget roles like forms and popups
- Live region attributes characterize content that constantly updates, such as weather or stock tickers. Assistive technologies use these updates to inform visitors that page data is changing
- Drag-and-drop attributes apply to draggable elements or ones that require a file drop
- Relationship attributes define element relationships when HTML doesn’t do so, such as the relationship between a form header to the form field itself
ARIA guidelines
The web development community has a saying: “No ARIA is better than bad ARIA.” Correctly incorporating ARIA supports a wider user base, but doing it wrong can harm everyone’s UX. It’s worth adding — but requires effort and research. Make sure you fully understand your end goal and how to get there before you hit publish.
The WAI's ARIA guidelines outline rules and best practices to ensure proper implementation. These are the five rules of ARIA worth remembering:
1. Use HTML elements whenever possible
ARIA originally covered missing accessibility elements within HTML4. Since then, HTML5 has advanced to support semantic tagging, which means your code might already include the specification it needs to be more accessible for people with disabilities.
If you’re assessing your code to check for accessibility, always use an HTML5 semantic element instead of ARIA if you can. This practice reduces overworking of a website and the potential for mistakes.
2. Only change native semantics if necessary
Building on the first rule of using ARIA, the second rule states you should only change native HTML elements or attributes if absolutely essential. Again, HTML semantics might already have the right accessibility features, and changing them could worsen the code’s performance.
3. All interactive ARIA controls must be accessible via keyboard
Using a mouse to explore a website isn’t possible for everyone. Adding keyboard navigation helps people interact with your content differently.
The keyboard must be able to trigger any action elements on a page — drag, drop, click, etc. Identifying elements with ARIA roles communicates what keyboard strokes trigger these actions, like pressing the enter key to interact with a button instead of clicking a mouse.
4. Don’t use role="presentation" or aria-hidden="true" on a focusable element
When you use one of these identifiers on a focusable element, they focus on nothing, making the action pointless. Using either of these tags on a focusable element, like a button, can inadvertently hide the button from the user, making it hard for them to navigate your website.
5. All interactive elements must have an accessible name
Every UI element needs an accessible name that identifies its specificity and use. This name can come from a visible property (like the text on a button) or invisible property (like image alt text). This practice helps accessibility technology use elements correctly.
Learn about our commitment to web accessibility and how you can build more accessible online experiences.
Learn about our commitment to web accessibility and how you can build more accessible online experiences.
ARIA pattern examples
The WAI has a comprehensive resource of pattern examples for how roles, states, and properties work together to create more accessible user elements. Exploring these examples will give you a better understanding of how ARIA works on a functioning website before you incorporate it.
Breadcrumbs: A breadcrumb trail lists links in a hierarchical order that leads back to the parent page. This trail tells users where they’re navigating and offers a clearer path if they want to return to a previous page.
Buttons: A button typically requires users to click a link or menu, but ARIA lets assistive technology “click” the button with the spacebar instead of a mouse.
Links: ARIA identifies links so visitors know when an element has one and where it leads. This process can apply to both internal links (to other pages on the same website) and external links (to other websites).
Carousels: ARIA coding creates clickable elements for image carousels so adaptive technologies can manipulate them and guide users.
Alert and message dialogs: When an alert pops up to deliver a message, it generally asks the user to respond by clicking “OK,” “Cancel,” or a similar confirmation. ARIA identifies the difference between popups (not urgent) and alerts (urgent) so users can act accordingly.
How to incorporate ARIA into your site
Thousands of people use assistive technology to access the web. Incorporating ARIA from the start helps you reach and support them.
Webflow’s accessibility checklist covers vital ARIA processes and other accessibility measures like adding alt text, using high-contrast colors, and writing descriptive, logical headings. Going through the checklist doesn’t guarantee full accessibility — a “perfect” website doesn’t exist — but it does let you hit important marks like adding roles to forms and tables and labeling your website’s logo.
A common use of ARIA in Webflow sites is to give more context to an input by using aria-describedby. Here’s how:
- Identify the input element on your website that requires additional context. This element could be a text input, a text area, or any other form field. For this example, we’ll use an input field labeled “guests.”
- Create a descriptive element that provides clear instructions to the user. For “guests,” your goal is to have users list the names of all party guests, separated by commas. Clearly communicate this information in the descriptive element.
- Assign unique ID attributes to both the “guests” input element and the descriptive element. You might assign the input field and descriptive element an ID of guests-input and guest instructions, respectively.
- Link the elements by using the aria-describedby attribute on the input element and descriptive element. This linkage ensures that screen readers and other assistive technologies can accurately communicate the additional instructions to users.
Improve your site’s accessibility with Webflow
To learn more about website accessibility, check out Webflow University’s Accessibility web course, which teaches best practices and why you should follow them. This course is a great place to start before incorporating ARIA or other accessibility measures. Check out our blog to discover more tips and get inspired by accessibility advocates.
Build completely custom, production-ready websites — or ultra-high-fidelity prototypes — without writing a line of code. Only with Webflow.
Build completely custom, production-ready websites — or ultra-high-fidelity prototypes — without writing a line of code. Only with Webflow.
