Render label in browse mode if it isn't rendered anywhere else (e.g. aria-label) #4773

Open
nvaccessAuto opened this Issue Jan 5, 2015 · 11 comments

Projects

None yet

3 participants

@nvaccessAuto

Reported by khsruru on 2015-01-05 07:56
Hello, I’m Hyongsop Kim in Korea.
I have a suggestion about NVDA and aria-label.
Let’s suppose that one html code is blow.
<input type=”text” aria-label=”type keyword”
In that case, if I press tab to approach to the edit box, NVDA reads aria-label attribute.
But in browse mode, if I press arrow key to approach, NVDA reads only edit, not read the aria-label text in Internet Explorer and Firefox.
In my opinion, aria-label text is used for the screen reader users in case not available to write visual text, NVDA should read the aria-label text even if use arrow keys.
Please check this issue.

Thank you.

@nvaccessAuto

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

@nvaccessAuto

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)"

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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?

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@jcsteh jcsteh added the p3 label Oct 7, 2016
@jcsteh
Contributor
jcsteh commented Oct 7, 2016

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

@derekriemer
Collaborator

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

@jcsteh jcsteh added the ARIA label Jan 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment