Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
preword: this isn't an attack on your article, just a very important warning as people may copy paste examples without knowledge or use role everywhere when it is not needed and could cause problems! I commend anyone drawing attention to accessibility ❤
Some examples, without relevant WAI-ARIA attributes would actually make accessibility worse.
And in some case in your examples they serve no purpose at all.
There are obviously a lot of examples here so I can't cover them all in a comment but I will cover a few just to draw people's attention to the fact that you can't just "set and forget" role attributes without understanding them and a lot of the time a simple HTML5 element will do the job better and with a lot more compatibility (more robust) with assitive technology.
role=button
<ahref="#"role="button">Button CTA</a>
While not an incorrect usage, the problem is that this is an anti-pattern. Instead just use a <button> element, all the semantics are built in, doing this is no where near as robust as <button> and a bad practice, avoid at all costs! (there is a caveat here, if you have built a backup page that shows if JavaScript fails then this could be acceptable, but it is a very niche use case and requires a lot of nuance that is too long for a comment, so unless you really know what you are doing, avoid it!)
<buttonrole="button">Add</button>
Also in this example there is nothing to be gained, the semantics are already on the button and unless you are supporting xHTML or HTML4 then it is unnecessary clutter.
For clarity that would be supporting IE8 and below, IE9 supports HTML5 just fine and I would be surprised if you are building websites that support IE8. This applies to a lot of the examples / summary below where I suggest just using a semantic element.
role="presentation"
<divstyle="float:left;">Some content on the left.</div><divstyle="float:right;">Some content on the right</div><divrole="presentation"style="clear:both;"></div><!-- Only used to clear floats -->
There is nothing to be gained adding it to an empty <div>, yet again it already has no role (which is essentially what role="presentation" does).
This should be used instead for things like images that are purely for aesthetics, tables if used for layout (which if you are doing you should have stopped 10 years ago!) etc.
It is designed to remove semantic information from an element that already contains semantic information.
warning: this is a very dangerous role. The second you add it every single item inside that element loses all semantic meaning and in-built functionality as far as assistive technology is concerned.
Unless you have a very very very strong grasp of accessibility and expected functionality I would not use this role.
it is that dangerous that when I talk about role attributes I never even mention it!
Yet again, completely unnecessary for anything below IE8 - just use <header> - it has exactly the same meaning.
And because this comment is long, some quick summaries:
role=checkbox - not needed on an input functioning as a checkbox.
role="complementary" - just use <aside>
role="contentinfo" - just use <footer>
role="heading" - not needed (just use <h1> through to <h6>), unless for some reason you need heading level 7 in a very complex document. Also cannot be used without aria--level otherwise it breaks the accessibility tree.
role="link" - just use a <a href="", fake links are a terrible idea.
role="list" - don't use this on an <ul> or an <ol>, you are removing semantic information.
role="main" - just use <main>
role="menu" - needs a lot of extra ARIA attributes such as aria-expanded, aria-controls (or aria-owns) etc. to have any meaning. Without it it would cause confusion.
role="navigation" - just use <nav>
role="region" - use <section>, but you must also name it with either aria-label or aria-labelledby.
There are other warnings such as some of them having really poor support aria-role="switch" probably shouldn't be used for example and you should instead use something like a checkbox if appropriate.
Anyway, have a ❤ and a 🦄 as it is still great having a list of all the roles in oe place and draws attention to accessibility! 👍
I am Rajesh, a Software Engineer by profession and a Technical Blogger by passion. I am passionate about knowledge sharing, open-source contributions, connecting to people, and mentoring.
Thank you for your time to explain this, I agree there are few scenarios where-in we can seek for alternatives as using semantic HTML tags. We also encounter the situations where-in we need to rely on more than one ARIA. My HTML articles are targeted to most of code newbies or beginners and it's good to know for them that role is so vast. Gradually with experience they will get to know when and how to avoid them based on situations and yes they can refer your comment note - :)
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Not an issue at all, as I said, the article is great as a reference for the roles.
The only reason I wrote the comment is as you said "code newbies" tend to copy paste (or at least that is how I started out learning) so just wanted to give people a heads up!
Great reference piece for people to go off and learn each of the roles (perhaps you could link to MDN or another resource for each so people can understand them further)!
I hope to see more accessibility stuff from you in the future. ❤
I am Rajesh, a Software Engineer by profession and a Technical Blogger by passion. I am passionate about knowledge sharing, open-source contributions, connecting to people, and mentoring.
preword: this isn't an attack on your article, just a very important warning as people may copy paste examples without knowledge or use
role
everywhere when it is not needed and could cause problems! I commend anyone drawing attention to accessibility ❤Some examples, without relevant WAI-ARIA attributes would actually make accessibility worse.
And in some case in your examples they serve no purpose at all.
There are obviously a lot of examples here so I can't cover them all in a comment but I will cover a few just to draw people's attention to the fact that you can't just "set and forget"
role
attributes without understanding them and a lot of the time a simple HTML5 element will do the job better and with a lot more compatibility (more robust) with assitive technology.role=button
While not an incorrect usage, the problem is that this is an anti-pattern. Instead just use a
<button>
element, all the semantics are built in, doing this is no where near as robust as<button>
and a bad practice, avoid at all costs! (there is a caveat here, if you have built a backup page that shows if JavaScript fails then this could be acceptable, but it is a very niche use case and requires a lot of nuance that is too long for a comment, so unless you really know what you are doing, avoid it!)Also in this example there is nothing to be gained, the semantics are already on the button and unless you are supporting xHTML or HTML4 then it is unnecessary clutter.
For clarity that would be supporting IE8 and below, IE9 supports HTML5 just fine and I would be surprised if you are building websites that support IE8. This applies to a lot of the examples / summary below where I suggest just using a semantic element.
role="presentation"
There is nothing to be gained adding it to an empty
<div>
, yet again it already has no role (which is essentially whatrole="presentation"
does).This should be used instead for things like images that are purely for aesthetics, tables if used for layout (which if you are doing you should have stopped 10 years ago!) etc.
It is designed to remove semantic information from an element that already contains semantic information.
role="application"
warning: this is a very dangerous
role
. The second you add it every single item inside that element loses all semantic meaning and in-built functionality as far as assistive technology is concerned.Unless you have a very very very strong grasp of accessibility and expected functionality I would not use this role.
it is that dangerous that when I talk about
role
attributes I never even mention it!role="banner"
Yet again, completely unnecessary for anything below IE8 - just use
<header>
- it has exactly the same meaning.And because this comment is long, some quick summaries:
role=checkbox
- not needed on an input functioning as a checkbox.role="complementary"
- just use<aside>
role="contentinfo"
- just use<footer>
role="heading"
- not needed (just use<h1>
through to<h6>
), unless for some reason you need heading level 7 in a very complex document. Also cannot be used withoutaria--level
otherwise it breaks the accessibility tree.role="link"
- just use a<a href=""
, fake links are a terrible idea.role="list"
- don't use this on an<ul>
or an<ol>
, you are removing semantic information.role="main"
- just use<main>
role="menu"
- needs a lot of extra ARIA attributes such asaria-expanded
,aria-controls
(oraria-owns
) etc. to have any meaning. Without it it would cause confusion.role="navigation"
- just use<nav>
role="region"
- use<section>
, but you must also name it with eitheraria-label
oraria-labelledby
.There are other warnings such as some of them having really poor support
aria-role="switch"
probably shouldn't be used for example and you should instead use something like a checkbox if appropriate.Anyway, have a ❤ and a 🦄 as it is still great having a list of all the roles in oe place and draws attention to accessibility! 👍
Thank you for your time to explain this, I agree there are few scenarios where-in we can seek for alternatives as using semantic HTML tags. We also encounter the situations where-in we need to rely on more than one ARIA. My HTML articles are targeted to most of code newbies or beginners and it's good to know for them that role is so vast. Gradually with experience they will get to know when and how to avoid them based on situations and yes they can refer your comment note - :)
Thanks for your time, really appreciating :)
Not an issue at all, as I said, the article is great as a reference for the roles.
The only reason I wrote the comment is as you said "code newbies" tend to copy paste (or at least that is how I started out learning) so just wanted to give people a heads up!
Great reference piece for people to go off and learn each of the roles (perhaps you could link to MDN or another resource for each so people can understand them further)!
I hope to see more accessibility stuff from you in the future. ❤
Thank you, will try to accommodate the reference URLs in future.