DEV Community

Cover image for How to Implement ARIA Tags for Better Accessibility: A Comprehensive Guide for Web Developers

How to Implement ARIA Tags for Better Accessibility: A Comprehensive Guide for Web Developers

Sarvesh Patil on February 27, 2023

Introduction As web developers, it’s essential to make sure your website is accessible to everyone. One of the ways to achieve this is b...
Collapse
 
rouilj profile image
John P. Rouillard

I realize you are giving contrived examples but the first rule of ARIA is don't use ARIA. You correctly state this at the conclusion of your article.

However,

<button aria-label="Search" type="submit">Search</button>
Enter fullscreen mode Exit fullscreen mode

The text Search inside the button already provides the label. aria-label isn't needed. You can see this by putting your example in a web page and pulling up accessibility tools from your browser's dev tools. Add and remove the aria-label and reload the page. You will see that the button's visible text becomes the name for the button.

Your example does show that the aria-label and visible label should be the same. This assists partly sighted people using a voice recognition system. They can say "Press Search". IIRC setting an aria-label to a value different from the visible label would break this. It would make the button inaccessible.

Also role=button is not needed with a <button> element.
That is the default role for button and is at best redundant.

If you were using a div as a button (with all the javascript etc. needed to make that "work"), role=button would be needed.

Similarly using aria-checked isn't needed with an input type-checkbox. As developer.mozilla.org/en-US/docs/w... says:

Note: Where possible use an HTML <input> element with
type="checkbox" and type="radio" as these have built in
semantics and do not require ARIA attributes.

Again, I appreciate that simple examples are tough to come up with. Teaching people about ARIA is important and I am glad you are trying. But providing examples that people just learning ARIA will use incorrectly isn't good either.

Collapse
 
sarveshh profile image
Sarvesh Patil

Thank you for taking the time to read my article and provide feedback. I appreciate your input and agree with your points.

You are correct that the first rule of ARIA is to not use it if there is an appropriate HTML element available. I included the example with aria-label for educational purposes, to demonstrate the proper usage of the attribute when there is no visible label present. However, as you rightly pointed out, in the case of the element, it already provides a visible label, making the aria-label attribute redundant.

Regarding the use of role=button, I agree that it is unnecessary when used with the element. I included it as a way to demonstrate the proper usage of the role attribute for educational purposes. However, I should have made it clear that it is redundant in this case.

Similarly, regarding the use of aria-checked with a checkbox, I should have made it clear that it is unnecessary when using the element with type="checkbox". The same goes for aria-selected with the element.

Thank you for pointing out these errors. I will update the article to make it clearer and more accurate. Your feedback is valuable and will help me improve my future articles.

Collapse
 
netdjw profile image
Balázs Winkler

Please fix this article, because it suggest bad practice.

A button should NOT define role="button", because it's a button. You dont need to define again it's a button. And an "a" tag should NOT define role="link" because it's a link by naturally.

With these unneccessary definitions you not simply just write more codes, but whit that you downgrade the performance a bit for accessibility tools, because they will parse the button element, register it's a button, then parse the role attribute, and overdefine it's a button. So this is absolutely wasting resources.

Collapse
 
sarveshh profile image
Sarvesh Patil

Thank you for taking the time to read my article and provide feedback. I appreciate your input and agree with your points.

You are correct that the role attribute is not necessary for the button and link elements since they already have their default roles defined. In the article, I included these examples to demonstrate the proper usage of the role attribute for educational purposes. However, I should have made it clear that it is redundant in these cases.

I apologize for any confusion this may have caused and for the potential impact on accessibility tool performance. I will update the article to make it clearer and more accurate, taking your feedback into consideration.

Again, thank you for bringing this to my attention and helping me improve the quality of my content.

Collapse
 
citronbrick profile image
CitronBrick

Please enable syntax highlighting in your Dev.to code blocks, using

(triple backtick) (name of language. eg: html)
(your code)
(triple backtick)

Collapse
 
sarveshh profile image
Sarvesh Patil

I will definitely take your suggestion into consideration for future posts and will make an effort to implement it. Thank you once again for your valuable input!

Collapse
 
dinodonga_76 profile image
dinoDonga • Edited

id start with this article. its an easy fix and makes all of our reading experiences way better

Image description

Thread Thread
 
sarveshh profile image
Sarvesh Patil

Noted

Collapse
 
vulcanwm profile image
Medea

great post!

Collapse
 
sarveshh profile image
Sarvesh Patil • Edited

Hey, thanks @vulcanwm

Collapse
 
vulcanwm profile image
Medea

np!