[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?"

[jholman]

I found this example helpful.