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.
Your list of five easy things to do is nice, and is an awesome starting point, but it falls far short of the ‘90% accesible’ watermark that you claim for any reasonably complex application, especially once you take into account the lack of practical useful support for some semantic elements (with the dialog element being the most problematic offender here).
Given this, I would extend your list of easy steps with two others:
Any time you are using an element for some purpose other than the one defined by the HTML standard, use the appropriate role attribute. For anybody who is non-visual and/or uses keyboard-only interaction with the web, this actually will solve a significant percentage of accessibility issues on it’s own. It’s also one of the simplest parts of WAI-ARIA to understand, is well supported across browsers, and even sometimes makes things behave better for ‘normal’ users as well.
Don’t interfere with zoom functionality, and don’t use a font size that’s a absolute number of pixels or scaled off of the viewport size (yes, I have actually seen sites that do that...). I don’t care if you think your layout only looks good at one scale, the user should not need to resort to OS-level functionality to be able to read your site (and your layout will be ugly from the perspective of such users anyway, because they will find a way to make things bigger or they will just not use your site). This one is not only easy to do (you quite simply don’t do something), it’s also a major issue even for people who do not technically have accessibility problems by most standard definitions.
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 think 90% accessible is poorly explained on my part, 90% by volume, not by impact / severity would still be reasonably accurate (as I assume once you learn those items you actually use them!).
point 1 role attribute
I can't agree on your first point. Not because I don't agree with the sentiment of using the appropriate role...far from it!
The reason I can't agree is because the second you add role= you open up the whole world of needing to add aria attributes, expected keyboard functionality etc. (maybe role="alert" and role="search" are the only ones I can think of that you can just use out of the box with very little knowledge)
Plus the second you give people the "power" of role= you get the disaster that is hyperlinks as buttons, divs with roles instead of native elements etc.
It is also the very first thing that is a "code smell" to me...I see a load of role=s in the HTML and I think "if only they started with x element they could have saved 20% of their extra code".
One more thing is that majority of roles are mirrored in semantic markup. Very rarely do you actually need to stray from semantic markup, we just like to (prime example being custom <select> elements due to how little flexibility we have in styling / content - one of the few times when I can completely agree that "starting with native" just isn't feasible if you have anything even marginally complex to display!).
Finally the second you learn of the role attribute you also learn of the role="application" and as we know....that might as well burn your application to the ground for people who use a screen reader and or a keyboard! It should come with a public health warning for the majority of developers! 🤣
Along the same lines, the dialog element example. Yes it falls far short of "set and forget" but it is still better than just <div class="dailog" as you see in soooo many applications and should still be used as a base for a modal in most circumstances.
point 2 - browser zoom and font sizes
Second point - oh that is without doubt in the top 10, in fact I would have a hard time arguing it not being point 6 or 7!
I am not without this sin either unfortunately, I have a couple of older sites that are still live and out there that use vw for font sizes....and it does make me cringe that I did that!
So I would probably put this point 6 or 7! But luckily nowadays a lot of the "stopping zooming" has gone away and a lot of browsers override this anyway so not as bad as say 5 /6 years ago.
My number 6 (before you mentioned zoom and fonts 😋)
Personally my number 6 would be to learn how to use aria-label, aria-labelledby and visually hidden text.
Those three items can massively improve user experience when implemented correctly and fix a lot of the empty button and link issues we see.
My number 7
Learn native HTML 5 form validation.
Yet again faaaaar from perfect, but much better than nothing. Plus it does act as a nice base for proper validation through progressive enhancement.
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.
Nitpick:
Your list of five easy things to do is nice, and is an awesome starting point, but it falls far short of the ‘90% accesible’ watermark that you claim for any reasonably complex application, especially once you take into account the lack of practical useful support for some semantic elements (with the dialog element being the most problematic offender here).
Given this, I would extend your list of easy steps with two others:
roleattribute. For anybody who is non-visual and/or uses keyboard-only interaction with the web, this actually will solve a significant percentage of accessibility issues on it’s own. It’s also one of the simplest parts of WAI-ARIA to understand, is well supported across browsers, and even sometimes makes things behave better for ‘normal’ users as well.Nitpick away, I welcome it!
I think 90% accessible is poorly explained on my part, 90% by volume, not by impact / severity would still be reasonably accurate (as I assume once you learn those items you actually use them!).
point 1
roleattributeI can't agree on your first point. Not because I don't agree with the sentiment of using the appropriate
role...far from it!The reason I can't agree is because the second you add
role=you open up the whole world of needing to addariaattributes, expected keyboard functionality etc. (mayberole="alert"androle="search"are the only ones I can think of that you can just use out of the box with very little knowledge)Plus the second you give people the "power" of
role=you get the disaster that is hyperlinks as buttons, divs with roles instead of native elements etc.It is also the very first thing that is a "code smell" to me...I see a load of
role=s in the HTML and I think "if only they started with x element they could have saved 20% of their extra code".One more thing is that majority of
roles are mirrored in semantic markup. Very rarely do you actually need to stray from semantic markup, we just like to (prime example being custom<select>elements due to how little flexibility we have in styling / content - one of the few times when I can completely agree that "starting with native" just isn't feasible if you have anything even marginally complex to display!).Finally the second you learn of the role attribute you also learn of the
role="application"and as we know....that might as well burn your application to the ground for people who use a screen reader and or a keyboard! It should come with a public health warning for the majority of developers! 🤣Along the same lines, the
dialogelement example. Yes it falls far short of "set and forget" but it is still better than just<div class="dailog"as you see in soooo many applications and should still be used as a base for a modal in most circumstances.point 2 - browser zoom and font sizes
Second point - oh that is without doubt in the top 10, in fact I would have a hard time arguing it not being point 6 or 7!
I am not without this sin either unfortunately, I have a couple of older sites that are still live and out there that use
vwfor font sizes....and it does make me cringe that I did that!So I would probably put this point 6 or 7! But luckily nowadays a lot of the "stopping zooming" has gone away and a lot of browsers override this anyway so not as bad as say 5 /6 years ago.
My number 6 (before you mentioned zoom and fonts 😋)
Personally my number 6 would be to learn how to use
aria-label,aria-labelledbyand visually hidden text.Those three items can massively improve user experience when implemented correctly and fix a lot of the empty button and link issues we see.
My number 7
Learn native HTML 5 form validation.
Yet again faaaaar from perfect, but much better than nothing. Plus it does act as a nice base for proper validation through progressive enhancement.
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!