Understanding an ARIA property is important knowledge to have as you begin to improve your website so that it is accessible to all users, especially when you’re aiming to include the 1 billion people in the world who are living with a disability. By having an accessible website, you ensure that those with vision impairments, motor disabilities, cognitive disorders, and more can understand and navigate all your company has to offer. Without an accessible website, these users cannot use their assistive technologies to navigate and are unable to browse the site.
More companies are beginning to consider the needs of this large group of people when optimizing their website (and rightfully so!) Understanding how an ARIA property fits into this movement is an important step to take into consideration.
How an ARIA Property Works
Dynamic content on any webpage can be challenging for users who cannot view their mobile or desktop screen due to a disability. Stock tickers, live Twitter feed updates, progress indicators, and similar content modify the Document Object Model (DOM) in ways that assistive technology (AT) may not be aware of, which is where ARIA properties come into play and make a difference. While this may seem a bit over-your-head if you’re not a developer, this knowledge will come in handy in the future! More on that later.
ARIA supplements HTML so that interactions and widgets frequently used in applications can be passed to assistive technologies when there are no other mechanisms. For instance, ARIA enables accessible navigation landmarks in several places, with a few of the most popular being:
- Form hints
- Error messages
- Live content updates
Like any other web technology out there, there are multiple levels of support for ARIA. Support is based on the operating system and browser being utilized and the kind of assistive technology that is interfacing with it. The version of the operating system, browser, and assistive technology are contributing factors. Older software versions may not support certain ARIA roles, have partial support, or misreport its functionality.
Leader in automated web accessibility, accessible, describes ARIA’s functionality on their website. “All fields must include a “LABEL” tag that is connected to the field by the “id” and the “for” attributes, or an “aria-label” attribute. Required fields must include both visual cues (Asterix*, text or other), and the “aria-required” attribute equals true. Fields must include the “aria-invalid” attribute to inform screen-readers whether the field is currently valid or invalid. This attribute must change dynamically according to the validations. E.g., an empty required “name” field must include aria-invalid=” true” to indicate that it’s invalid, but change to aria-invalid=” false” once the user fills it up.”
Why ARIA Matters
When a form is submitted in more layman’s terms and errors are present, the keyboard must be taken to the first invalid field. The user must receive an explanation (both visual and the screen-reader) of the issue with this particular field. When a form is submitted successfully, a blind user with a screen-reader should be informed of that, which is a big reason why ARIA matters.
It is also important to consider that some people who rely on assistive technology features may be reluctant to upgrade their software. Some fear that they will lose the ability to interact with their browser and computer as a whole. Due to this, it is crucial to use semantic HTML elements whenever you possibly can. As we have written in the past, “Accessibility makes normal websites more available for cell customers whilst using a browser like Chrome or Safari. Users can get admission to your internet site whenever anywhere using any tool. It is important to create a mobile-pleasant layout to make certain clarity and functionality whilst viewed on a cellphone or tablet.”
In the end, using properties like ARIA to assist Internet users with disabilities is crucial in creating an equal Internet user experience.