[Ensorceled]

> They're not saying that using area-* cannot be correct, just that it's so often incorrect as to be a smell.

But do to accessibility correctly you almost ALWAYS need to use aria-*

So it this is just like saying "writing code is a code smell because you'll have bugs" and it turns "code smell" into a useless tautology.

[user3939382]

> But do to accessibility correctly you almost ALWAYS need to use aria-*

What? No... Screen readers do best with standard elements and you're supposed to avoid aria labels where possible, and only as a last resort.

[Ensorceled]

> What? No... Screen readers do best with standard elements and you're supposed to avoid aria labels where possible, and only as a last resort.

Yes, you should avoid overusing them, which is the point the author is turning into a "code smell", but I've no idea how the heck you would pass an AAA or even a AA audit without aria-* labels.

Can you point me to a significant site, i.e. one that's not just a simple content site, that doesn't use aria-* tags at all?

[derefr]

Why do you elevate "significance"? In terms of the number of developers who care, "significant sites" are a minor niche. The web obeys a power law; there are only 1000 "significant" websites in the world, and far more "insignificant" ones.

Most of the world's web developers are creating blogs, business-card-ware (e.g. restaurant websites that let you see the menu as a PDF but don't let you order from it), and HTML-based CRUD UIs for backoffice software (i.e. the thing you get from bog-standard no-other-libraries-needed Django or Rails.) You don't need the aria- tag attributes when building any of those. To achieve accessibility with these, you just need a ca. 2001 CSS Zen Garden-esque understanding of semantic HTML.

[bryanrasmussen]

The vagaries of English being what they are significant does not need mean important, in this case I think they mean a site with a significant amount of work behind it. That is to say not a quick resume site. A real site with a few 100 pages and complicated workflows are significant in the way I believe the OP meant.

>You don't need the aria- tag attributes when building any of those.

what, these are exactly the sites where you need aria tags, because they all have buttons and workflows the context and usage of which are totally obvious to anyone who can see and completely opaque otherwise.

Even IF in one of these sites they order of your markup is such that the elements follow in a correct order and the seen text will be understandable when accessed through the screen reader there are likely to be instances in which, if you care about the experience of a visually challenged user, extra work would be useful to allow for navigating between parts of the site in an understandable way and to do things with a reasonable speed.

[7sidedmarble]

>what, these are exactly the sites where you need aria tags, because they all have buttons and workflows the context and usage of which are totally obvious to anyone who can see and completely opaque otherwise.

The authors point was that you should rely first on the information you can communicate in the actual content, ie, a button with the content of 'submit', when it's inside a form element, is enough to communicate what it does to every user. But if you have multiple buttons that all say 'submit', and you can't consider changing the content to be more explicit, that's when you may want aria-label. The authors point was that this latter scenario is actually less common though, and I agree with them.

[bryanrasmussen]

have you used a screen reader?

If so have you ever used the more advanced navigational methods, here I'll just limit myself to the web-rotor on Voiceover because it is the easiest to think about and to remember how it works - at least for me.

>The authors point was that you should rely first on the information you can communicate in the actual content, ie, a button with the content of 'submit',

I understand the author's point, and the OP discussed that doesn't make any sense because on any 'significant' site you can't rely on that.

So ok, let's take another example. You come into a site as a sighted user

there is a button that says refresh under the User messages heading.

and a button that says refresh under the System messages heading.

As a sighted user you know exactly what the context is of these refresh buttons and you know that in a second.

As a blind user you will probably have to go through the page, at least the first time, and then remember to navigate to System Messages heading next time and go to refresh button after that.

In the sighted user context the nice design is to have all System messages underneath the header followed by the refresh button.

So you need to go through all the system messages to click the refresh button if you are the blind user.

Of course if the refresh button has an aria-label refresh System messages you can go to System messages heading, read the first, hear date has not been updated since last time you read, use web rotor to get refresh system messages button click button (why? Because this is an example of design conditions that affect sighted users and visually disabled users and not of any actual working site)

All of which is a very in depth example of a situation that should be easy to imagine without any detailed explanation of how in a reasonably complex site there can be constructs that will be totally apparent to sighted users and not apparent to people with visual impairments and how just relying on the natural layout of the site would be under-serving screen-reader users.

I admit that a submit button probably won't have this scenario, but there are lots of clickable buttons on most modern sites that are not a submit.

At which point I suppose someone might make the obvious argument that the buttons should have the text Refresh System Messages and Refresh User Messages

but that won't go because

1. buttons with a lot of text on them are harder to understand so now a large portion of the user base needs to be under-served to make things easier for the people who are visually impaired.

2. From a design perspective having Refresh System messages under the System Messages area instead of just Refresh is also grating.

At any rate as said, the above is a completely artificial scenario that should be immediately understandable as an example of the kind of thing to arise on a normal company site by any one who has had to develop for such a site.

And I say this to try to forestall the HN - "but you should not have a refresh button because the data should be pulled periodically" or "why would you come to the site, read a message and then know you should refresh huh?"

[Ensorceled]

So, no examples?

[user3939382]

I work daily on a pretty complex platform that is able to completely bypass them. That’s because Vue, and I imagine other UI frameworks like it, have good support for building components by essentially decorating these simple HTML elements that the screen readers like.

In other words, for example, your dropdown can be a <select> and Vue can still do automagic with it, it doesn’t have to be a pseudo-dropdown built from <div>s that you then need aria for. And in fact even in our complex codebase that’s been universally true.

I’m sure there are exceptions but I assume they’re rare enough that even other large projects don’t have any.

[oneeyedpigeon]

What is the minimum amount of functionality that, in your opinion, would 'elevate' a site beyond 'simple content' territory?

[Ensorceled]

So, no examples?

[oneeyedpigeon]

OK, Eric Meyer's URL Decoder/Encoder:

https://meyerweb.com/eric/tools/dencoder/

[ohgodplsno]

Only if you want to give your users a terrible experience where the screen reader reads a bunch of separate items with no logical connection between them.

A single aria-label describing a component and its actions is always going to be better.

[Ensorceled]

Exactly. I made a large site AODA compliant and, yes, I could have done it without aria-* but it would have been a really shitty UX.

[Vinnl]

They're not saying all aria- attributes are a code smell, just that aria-label is. And they provided an extensive list of common usages where an alternative would usually be better.