I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
For the role attribute specifically, there are definitely some things you should not use, and semantic HTML is always preferable, but stuff like hyperlinks as buttons is unfortunately here to stay with or without this, and it’s arguably better to handle those correctly but still have them than to not handle them correctly as a way to discourage developers to use them.
As far as which roles to actuallyuse though, tagging the landmark roles (main, navigation, and similar stuff) is easy, needs no extra attributes, and immediately makes your site more accessible for most (but not all) users using modern screen readers.
On the note of the dialog element, needing a polyfill just for support on major browsers (Safari completely lacks support, Firefox requires running the nightly or manually enabling the element in about:config, and Edge has only supported it since January of 2020) is a major complication for practical usage, especially when said polyfills often require special handling when used with popular application frameworks. Yes, using the native element is preferred where possible, but using role="dialog" is still better than nothing, and there are a distressing number of sites out there that do nothing beyond making the element look like a dialog in visual presentation and hijack any input that would go to other elements on the page.
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.
But with modern screen readers role="main" is exactly the same as <main>. It is an overhang from xHTML / HTML 4 days....but we have had HTML 5 for 13 years, there are few screen readers that don't support it, even legacy ones that only run on IE9!
I mean we could take it to the extreme and say "but what about people on IE6,7,8" in which case - sure add the role attribute to those elements, but i guarantee there are 100 other things that make your site completely unusable to them when using HTML 5 that make it futile.
I cannot think of any standard landmark role where adding role adds any benefit over its native HTML5 version.
Now with that being said I do agree with you on dialog but as I said, you then have the problem of needing to know aria-modal="true", aria-labelledby, add keyboard functionality, focus management, aria-haspopup on the button that opens the modal etc. etc.
We are a long way from the stuff that beginners can learn in a day. That was the point I was trying to make, <dialog> requires role="dialog" still due to poor support to inform screen reader users what element they are in, but it makes no difference if you don't know the other things you need to implement!
I would rather you learned <dialog> so that 50% of users get some semblance of a usable experience instead of role="dialog" which would add 0 functionality but would let a screen reader know "hey this is a dialog, but that is all, we haven't made it usable or anything".
If you have a particular example in mind of whether you think knowing role="" is useful over knowing the semantic equivalent I will probably agree entirely but I can't think of one that doesn't require a much larger breadth of knowledge.
So that leaves role="alert" and role="search" as the only two I can think of that are useful without deeper knowledge? Maybe I am missing one though.
As for everything else I think we are in full agreement, and as for how distressing it is seeing some modal implementations I think you under played the problem if anything!
My favourites are still the ones where you can't focus the close button (as it isn't a <button> but instead <div role="button" where the developer didn't add tabindex="0"!) and of course there is no Esc key to close. I mean you know a problem is wide spread when WCAG has the "no keyboard traps" criteria in it!
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
The things with dialogs though is that you don’t have to understand why you need to have aria-labeledby or any of the other functionally required attributes, just that they need to be there. That kind of knowledge (you need to have this so that things behave properly) is not difficult for most people to learn quickly provided you present it correctly, even if the ‘why’ aspect is much more complicated and harder to understand.
As far as zero-effort role attribute values, the top of the list is probably role="presentation". It shouldn’t need to be used, but a lot of sites do stupid things that involve using elements for purely presentational purposes without tagging them as such. Other than that, description comes to mind, as it’s dead simple to understand when to use it (if an element is pointed to by an aria-describedby attribute, it should have the description role).
A handful of cases are not reasonably usable without specific additional attributes, but the required additional attributes are pretty trivial to understand. progressbar is probably the best example of this, you just need an aria-valuemax set appropriately and an aria-valuenow that gets updated as you adjust the progress bar itself, and not doing this makes an application difficult at best to use for non-visual (and even text-only) users.
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.
I agree with you, but I think we have strayed back into the whole point of my rant now though.
If we made it simple "This is the skeleton of a dialog, you need these roles on it, these attributes, this attribute should be this, this or that" etc. Then accessibility would fall into place for 95% of things.
Where I was arguing the point was purely on what order I would want people to learn things that is all (and the overuse of WAI-ARIA due, mostly, to improper HTML markup!)
100% yes I have no idea how I didn't think of role="presentation"...possibly because I use it so rarely.
Other than that, description comes to mind, as it’s dead simple to understand when to use it (if an element is pointed to by an aria-describedby attribute, it should have the description role).
Where did you read / learn that? I don't think role="description" is a real role?
Are you meaning aria-roledescription which is for custom elements?
aria-describedby is intended to be used to add additional long form information to a control, input label etc. But all it expects is the ID(s) of any element(s) with readable "flow" content inside it. It does not expect the element it is being pointed at to be marked up in any special way (unless this is a future aria thing I haven't seen!)
Same again with progress bar - easy to understand....but knowing about it and using it....that is where my rant started!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For the
roleattribute specifically, there are definitely some things you should not use, and semantic HTML is always preferable, but stuff like hyperlinks as buttons is unfortunately here to stay with or without this, and it’s arguably better to handle those correctly but still have them than to not handle them correctly as a way to discourage developers to use them.As far as which roles to actuallyuse though, tagging the landmark roles (
main,navigation, and similar stuff) is easy, needs no extra attributes, and immediately makes your site more accessible for most (but not all) users using modern screen readers.On the note of the
dialogelement, needing a polyfill just for support on major browsers (Safari completely lacks support, Firefox requires running the nightly or manually enabling the element inabout:config, and Edge has only supported it since January of 2020) is a major complication for practical usage, especially when said polyfills often require special handling when used with popular application frameworks. Yes, using the native element is preferred where possible, but usingrole="dialog"is still better than nothing, and there are a distressing number of sites out there that do nothing beyond making the element look like a dialog in visual presentation and hijack any input that would go to other elements on the page.But with modern screen readers
role="main"is exactly the same as<main>. It is an overhang from xHTML / HTML 4 days....but we have had HTML 5 for 13 years, there are few screen readers that don't support it, even legacy ones that only run on IE9!I mean we could take it to the extreme and say "but what about people on IE6,7,8" in which case - sure add the
roleattribute to those elements, but i guarantee there are 100 other things that make your site completely unusable to them when using HTML 5 that make it futile.I cannot think of any standard landmark role where adding
roleadds any benefit over its native HTML5 version.Now with that being said I do agree with you on
dialogbut as I said, you then have the problem of needing to knowaria-modal="true",aria-labelledby, add keyboard functionality, focus management,aria-haspopupon the button that opens the modal etc. etc.We are a long way from the stuff that beginners can learn in a day. That was the point I was trying to make,
<dialog>requiresrole="dialog"still due to poor support to inform screen reader users what element they are in, but it makes no difference if you don't know the other things you need to implement!I would rather you learned
<dialog>so that 50% of users get some semblance of a usable experience instead ofrole="dialog"which would add 0 functionality but would let a screen reader know "hey this is a dialog, but that is all, we haven't made it usable or anything".If you have a particular example in mind of whether you think knowing
role=""is useful over knowing the semantic equivalent I will probably agree entirely but I can't think of one that doesn't require a much larger breadth of knowledge.So that leaves
role="alert"androle="search"as the only two I can think of that are useful without deeper knowledge? Maybe I am missing one though.As for everything else I think we are in full agreement, and as for how distressing it is seeing some modal implementations I think you under played the problem if anything!
My favourites are still the ones where you can't focus the close button (as it isn't a
<button>but instead<div role="button"where the developer didn't addtabindex="0"!) and of course there is no Esc key to close. I mean you know a problem is wide spread when WCAG has the "no keyboard traps" criteria in it!The things with dialogs though is that you don’t have to understand why you need to have
aria-labeledbyor any of the other functionally required attributes, just that they need to be there. That kind of knowledge (you need to have this so that things behave properly) is not difficult for most people to learn quickly provided you present it correctly, even if the ‘why’ aspect is much more complicated and harder to understand.As far as zero-effort role attribute values, the top of the list is probably
role="presentation". It shouldn’t need to be used, but a lot of sites do stupid things that involve using elements for purely presentational purposes without tagging them as such. Other than that,descriptioncomes to mind, as it’s dead simple to understand when to use it (if an element is pointed to by anaria-describedbyattribute, it should have thedescriptionrole).A handful of cases are not reasonably usable without specific additional attributes, but the required additional attributes are pretty trivial to understand.
progressbaris probably the best example of this, you just need anaria-valuemaxset appropriately and anaria-valuenowthat gets updated as you adjust the progress bar itself, and not doing this makes an application difficult at best to use for non-visual (and even text-only) users.I agree with you, but I think we have strayed back into the whole point of my rant now though.
If we made it simple "This is the skeleton of a dialog, you need these roles on it, these attributes, this attribute should be this, this or that" etc. Then accessibility would fall into place for 95% of things.
Where I was arguing the point was purely on what order I would want people to learn things that is all (and the overuse of WAI-ARIA due, mostly, to improper HTML markup!)
100% yes I have no idea how I didn't think of
role="presentation"...possibly because I use it so rarely.Where did you read / learn that? I don't think
role="description"is a real role?Are you meaning
aria-roledescriptionwhich is for custom elements?aria-describedbyis intended to be used to add additional long form information to a control, input label etc. But all it expects is the ID(s) of any element(s) with readable "flow" content inside it. It does not expect the element it is being pointed at to be marked up in any special way (unless this is a future aria thing I haven't seen!)Same again with progress bar - easy to understand....but knowing about it and using it....that is where my rant started!