Comment 1 by khsruru on 2015-01-05 07:57
Changes:
Changed title from "A suggestion about NVDA and aira-label." to "A suggestion about NVDA and aria-label."

Comment 2 by jteh on 2015-01-08 08:01
The problem with doing this is that it would result in a huge amount of duplication. For example, if the label was visible on screen, the label would end up being rendered twice: once for the actual label and then again for the "fake" rendering of the label you are proposing. Not rendering the label itself would be bad because this means you lose access to the formatting information for the label. Also, the label might be rendered somewhere else entirely. For example, if the label was actually a column header in a table, that column would appear empty to the user, which would be very confusing.

It's worth noting that you can still access this information by pressing NVDA+tab when you move to the field.

Leaving open because I guess it'd be nice to have a way to do this for cases where the label really isn't rendered anywhere else, but the solution must avoid duplication.
Changes:
Changed title from "A suggestion about NVDA and aria-label." to "Render label in browse mode if it isn't rendered anywhere else (e.g. aria-label)"

Comment 3 by khsruru on 2015-01-08 08:12
Thank you for your reply.
As you said, if type=text have both label and aria-label attribute and NVDA reads both, I agree that it is confusing.
But my suggestion is that type=text has only one attribute, aria-label, not label for attribute.
In that case, if NVDA reads it, it is not duplicated and is needed.
Otherwise, if I use only arrow keys, users doesn’t know the information and more confusing.
Because they might not try to press NVDA plus tab key or consider there is no information text.
Please check this again.

Thank you.

Comment 4 by jteh on 2015-01-08 10:05
At least in Firefox, we don't deal with HTML directly. We deal with labels, independent of the HTML. This means we can't necessarily detect aria-label versus, say, label for or aria-labelledby.

Also, there are other ways to assign labels that aren't immediately visible, such as the title attribute in some cases. Even if we could detect aria-label, it obviously wouldn't cover these cases. We need a better way to handle this than adding more and more special cases for various HTML attributes.

Comment 5 by camlorn on 2015-02-22 20:11
I think the priority here should be higher, and the scope potentially broadened. Google drive is now using aria-label on unorthodox elements, and as far as I can tel both the W3C Aria spec and the WCAG 2.0 are suggesting you do exactly that if it's applicable. On Google Drive specifically, we have the additional oddity that it works if you use object nav, but it's still problematic. I've got someone else who has been trying to use it to deal with the fact that screen readers fail on Unicode as well, which also seems like a pretty legitimate use. I've not looked closely at Disqus because they have other issues, but they claim accessibility as well, and some of the things I see there are another place that I'd personally throw aria-label at.
deduplication may not be feasible. WCAG is suggesting that you use aria-labelledby for things with visible text and not both, so we may need to consider aria-label duplication a fault of the web author. Yes, I know that sentence is cringe-worthy, but I'll take accessible with duplication over not accessible at all if I must.
Alternatively, we revisit the Aria options dialog. Which is even more cringe-worthy.
And the bigger question: is it even possible to fully support all of Aria without accessing the DOM?

Comment 7 by camlorn on 2015-02-22 20:23
I just verified that Disqus does not appear to be a case of this. The bugs with Disqus are interesting, and it might be worth looking at my site to see if we can make some tickets for them because they're similar to what I'm seeing with aria-label with Google Drive: things working with object nav but not with browse mode. Nevertheless, they are not this ticket, not unless the scope widens a whole lot further.

Comment 8 by jteh on 2015-02-22 21:24
This is not to say that this issue isn't valid, but it's worth noting that you'll actually get a better experience if you don't use browse mode for Google Drive. Note also that we already use author overridden labels for elements where the label is effectively the content; i.e. links, buttons, etc. That means that cases like Disqus should probably behave correctly unless they're doing it wrong.

As for doing ARIA with the DOM, that's a separate discussion, but in short, we do not want to go down this path where we can avoid it; i.e. everywhere except MSHTML, where we have no choice. Aside from the fact that certain things are extremely difficult/inefficient with the DOM access an AT can get and that one ends up chasing one's tail dealing with edge cases, it's not at all future proof.

Comment 9 by camlorn on 2015-02-24 17:39
Disqus is specifically weird because it looks like it's doing everything reasonably, but the experience isn't. I need to look into it more; comments on my blog suck if you're blind. But that isn't this ticket because they're not using Aria after all and I'm not ruling out Disqus being at fault, either.
The specific information in question on Google Drive that actually caused this difficulty was not available via anything but browse mode. The details on a specific item don't seem to be something you can get at any other way. I specifically needed to verify that the people I added to the folder were actually in the folder, and I guess they're doing something weird with CSS and feel the need to present the information through aria-label. The equivalent information without using object nav is the first letter of the first name, or something weird along those lines. Taking firebug to drive is difficult, unfortunately, so I wasn't able to tell what they're trying to do there that necessitates it. I got only as far as "without aria-label, this fails". So many nested divs.
But I think the original point is still valid. Aria-labelledby is what you use when there's text to label a form field but it's not actually obvious to a screen reader. Aria-label is full-blown alt text for things that aren't images. I think we should treat it as such, though aria-labelledby might need some more logic. As the web developer, If you have a duplicate label then you shouldn't be using aria-label. But as we know from applications mode, people have a full and complete understanding of Aria and do not abuse it on a regular basis, so.
As for DOM access, NVDA's Aria support isn't complete, and Aria itself looks complicated. It's not future-proof, but it might let the code for Aria be more readily shared between browsers and save us having to wait anywhere from months to years for a specific browser vendor to fix their stuff. But again, this debate is probably not this ticket, and I can't put up a very good argument either way for lack of familiarity with what can specifically be pulled out.

Comment 11 by jteh (in reply to comment 9) on 2015-03-24 04:20
Replying to camlorn:

But I think the original point is still valid. Aria-labelledby is what you use when there's text to label a form field but it's not actually obvious to a screen reader. Aria-label is full-blown alt text for things that aren't images.

There is nothing in the spec to support this assertion. If anything, the spec indicates they should essentially be treated the same way. This also isn't true in the wild. For example, I've seen landmarks labelled with both aria-label and aria-labelledby and this is perfectly valid according to the spec.

Btw, landmarks are perhaps the best example of why we can't just use a label as content wherever one is present without additional logic. If we did that, the entire content of the landmark would be replaced by the label. You can argue that we should make an exception for landmarks, but this is just one specific example. The point is taht this "label always overrides content" behaviour is just not possible. I've had this argument time and time again. If you care, you can go read about it in the various tickets concerning aria-label.

P3 because this can mean the user misses information, but the implementation will take some time.

I think this is also seen when aria-labelledby is used but the idlist element is aria-hidden (The label is read by NVDA, but skipped in browse mode).

I find it particularly bad when navigating with nvda with the navigation mode with the arrows when there are two text boxes in succession, and the nvda in both reads only edit, and does not read the label, in this case to identify what is Requested in the form it is necessarily mandatory to press the nvda + tabe to know what to insert into each text box.To illustrate what I want to discuss, see the website:Http://www.3remetodista.org.br/When opening the page to get faster you can press the letter m twice to go to the second frame.Now navigate with arrows below until you reach the first text box, where nvda will only report editing, press another down arrow and nvda will arrive in the second text box where it will speak again editing.Note that since two text boxes one after the other can generate some confusion in not receiving the label from them, particularly when arriving in the second text box.The announcement of the labels when navigating with the navigation mode could be an option to be marked and unmarked by the user in the panel of the nvda.It is possible to obtain the information with nvda + tabe, however this command may not be known to the new users of nvda.This call took some directions that I did not understand either because I did not have a technical formation in programming, this my comment is more referring to the commentary that opened this call.

Note: In the VBufBackend for gecko, if explicitName and not nameIsContent and not isLabelVisible, then expose alwaysReportName as true.

Specific test case from @syntaxbliss in #5742 (comment):

I have the next markup:

<button aria-label="LEFT BUTTON">left button</button><input type="text" aria-label="INPUT CONTROL" value="5"><button aria-label="RIGHT BUTTON">right button</button>

When I'm standing on the left button and then press TAB, NVDA correctly reads the input aria-label, which is:

INPUT CONTROL edit has autocomplete
selected 5

But if I'm standing on the left button and then press the arrow down key it reads:

edit has autocomplete
5

Note: This refers to pressing down arrow to get to the input field, which suggests screen layout was off for this test.