Distinguishing between ARIA and native HTML attributes
As a developer, you want to create more inclusive and accessible digital experiences for your users. Great! It’s possible, however, that you might be feeling a bit confused or overwhelmed by the element attributes that can affect the usability for users of assistive technology.
ARIA (or WAI-ARIA, Web Accessibility Initiative-Accessible Rich Internet Applications) defines some aria-* attributes with a name that is very similar to HTML attributes. This can lead to some confusion. Questions like, “Are they the same but one is for accessibility?” and “Should I use one or the other or both?” are very common. Here are some examples:
- Is the
aria-disabledattribute the same as the HTMLdisabledattribute? - Is the
aria-autocompleteattribute the same as the HTMLautocompleteattribute? - Is the
aria-hiddenattribute the same as the HTMLhiddenattribute?
Although the names are similar, the purposes are different and they are not interchangeable. It can be tricky to apply these right. According to a WebAIM 2023 study, home pages with ARIA present averaged 68.6% more detected errors than those without ARIA. Let’s briefly examine the similarities and differences of these attributes and how to implement them correctly.
Disabled and aria-disabled
The HTML disabled attribute makes a form control (and all its form control descendants) disabled, meaning it will be unchangeable, unfocusable, and will not be submitted with the form. In addition, a lot of browsers will automatically change the visual presentation of the control too, making it appear visually dimmed and inactive. Semantically the form control is disabled. You can add the disabled attribute on buttons, fieldsets, inputs, optgroups, options, selects, and textareas.
The aria-disabled attribute, when set to “true“, is different because it ONLY tells assistive technologies that the element (and all of its focusable descendants) is disabled. Adding the attribute to an element and setting it to “true” will have no automatic effect on whether it can be changed, focused, or submitted in a form. Visual presentation of the element will not automatically change either. All of these features and functionality will need to be managed by a developer. However, it can be applied widely, including on custom controls, making it a powerful tool.
Both attributes are useful and can affect the accessibility of a control. When using standard form controls, the HTML disabled attribute is easy to use and will be applicable for most use cases to disable the control. But when you need flexibility or are building a custom control (such as a custom disabled button) the aria-disabled attribute is the way to go! You should not need to use these both on a single control, but may need to use both in a page.
It’s worth reviewing more details. You can find some great documentation on both:
Autocomplete and aria-autocomplete
The HTML autocomplete attribute allows a developer to specify what type of information the browser may suggest for an input and what kind of information is expected. There are various defined values for autocomplete that are valid. For example, autocomplete="given-name" on an input will signal to the browser that the field is expecting a first name and the browser may suggest first name values that the user has supplied in the past.
The aria-autocomplete attribute, on the other hand, tells an assistive technology that adding text to a combobox, searchbox, or textbox control may trigger display of predicted values while the user types (also known as autosuggest). If the value for the attribute is set to “inline“, it indicates that it will present a single value. And if set to “list“, it indicates that it will present a series of values in a separate element. A third option, a value of “both“, indicates that it will present a list and a predicted value. Lastly, aria-autocomplete may be set to none, which is default, and indicates that the control will not provide predictions. Because this attribute simply signals to an assistive technology that the functionality is present and does not cause any functionality, any behaviors or functionality will need to be completely managed by a developer.
Both attributes are important for accessibility. The HTML autocomplete attribute can greatly impact the speed, accuracy, and ease with which a user completes a form on a web page. It is also directly supportive of WCAG Success Criterion 1.3.5 Identify Input Purpose (Level AA). Using aria-autocomplete may help screen reader users to understand the complex interactions in custom controls such as an interactive search or a combobox.
This can still be confusing and there are a lot of important details. Take a look at further documentation:
Hidden and aria-hidden
The HTML hidden attribute causes an element to not render. The element will not display visually and will not be announced by a screen reader.
The aria-hidden attribute, when set to true, will cause an element to not be exposed to assistive technologies. It does not change the visual presentation of the element. So it is possible that it will remain visible, but will not be announced by a screen reader. This may cause significant accessibility issues and should be used with great caution. Never add aria-hidden="true" on a focusable element as this would cause it to lose its accessible name!
Both attributes are powerful tools that strongly impact accessibility. If an element should not be presented to anyone but needs to remain in the DOM, then the HTML hidden attribute is the right tool. An example of this might be for a control that toggles visibility of some content, you can use JavaScript to simply toggle the hidden attribute away to cause the content to become visible and back again to hide from everyone. In a case where you have some visually decorative content that would be confusing or distracting to a screen reader user, you may want to consider using aria-hidden very carefully to ensure your message is clear. It isn’t necessary to use aria-hidden to supplement the HTML hidden attribute. The HTML hidden attribute hides the content for everyone!
You can learn more about these from detailed documentation:
Let’s review
Although some aria-* attribute names are similar to HTML attributes, they serve different purposes and are not equivalent. Knowing when and how to use these makes a huge difference for the accessibility of the experience you’re developing. In general, aria-* attributes are useful to convey important information to assistive technologies about custom controls or complex interactions. HTML attributes can directly impact features and functionality. You will need to use them both!
Now that we’ve got that cleared up, go on and make amazing accessible experiences!
