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