DEV Community


Discussion on: 🤷‍♂️ W1y d2s a11y h2e to be so b4y c9d a1d i10e? 👿

inhuofficial profile image
InHuOfficial Author • Edited

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 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.

ahferroin7 profile image
Austin S. Hemmelgarn

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.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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!

Thread Thread
ahferroin7 profile image
Austin S. Hemmelgarn

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.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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!

Forem Open with the Forem app