Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aria-label, aria-labelledby and aria-describedby: very unforeseeable behaviour #5398

Closed
nvaccessAuto opened this issue Oct 5, 2015 · 7 comments
Closed

Comments

@nvaccessAuto
Copy link

@nvaccessAuto nvaccessAuto commented Oct 5, 2015

Reported by jmuheim on 2015-10-05 14:35
I just noticed that although the aria-label, aria-labelledby and aria-describedby attributes are said to work on every element (see http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby), they only seem to work for a few elements like a, and not for e.g. div or p in NVDA and JAWS.

I have created a small codepen to demonstrate the issue (browse it using browse and focus mode):

http://codepen.io/jmuheim/pen/avWbPe

For example, in NVDA, on the a element, the aria-label and aria-labelledby seem to work in both browse and focus mode. But aria-describedby is only announced in focus mode, not in browse mode.

For the input element, none of the attributes seem to work in browse mode, but all work in focus mode.

For "bare" text elements like p or div, none of the attributes seem to work.

In JAWS, it's quite similar behaviour, but at least for the p element, when there is an aria-describedby, it announces that a description can be read by pressing "JAWS + alt + r".

I don't really see a clear pattern for this, so I wonder what are the general rules in NVDA on how to use these attributes? Or better: why don't they simply work for every element, as the spec proposes?

@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Oct 5, 2015

Comment 1 by jteh on 2015-10-05 23:51
They do in fact "work" on every element. However, "work" means that they label/describe an element. The spec does not say anything about whether/how they should affect the content that is rendered in browse mode or equivalent. I've already covered this on several occasions (e.g.e #1354), but here are a few quick points as to why we don't want to do this unconditionally:

  • It does make sense to override the content of a link or button with its label; e.g. +
  • If we overrode the content of a div with its label, labelled landmarks, sections, etc. would completely replace the content with their label; e.g.
    This content would be overridden
  • A description is secondary information. The closest visual representation is a tool tip, which only appears when a sighted user mouses over the element; i.e. they explicitly show interest. Similarly, NVDA reads the description when a user focuses, navigates using single letter navigation or specifically queries the element.
    Changes:
    Added labels: invalid
    State: closed
@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Oct 21, 2015

Comment 2 by jmuheim on 2015-10-21 09:05
Thanks for explaining. I asked the same question on StackOverflow, there's some non-screenreader-speicific information, too:

http://stackoverflow.com/questions/32951169

@lakshmiSachidanandam
Copy link

@lakshmiSachidanandam lakshmiSachidanandam commented Apr 18, 2019

As per JAWS behaviour,
1)aria-label works only for divs/span which has interactive role value
2)aria-describedby works on static text

@alanfluff
Copy link

@alanfluff alanfluff commented May 3, 2019

With NVDA 2018.2.1 | Windows 7 | Chrome 73.xx I am attempting to use aria-describedby to label an image. When I read:

Similarly, NVDA reads the description when a user focuses, navigates using single letter navigation or specifically queries the element.

I was delighted as I assumed an img element could have an alt of, for example, A cat, select for full description and then in another tag linked via aria-describedby I can have A cat sat on a mat about to get into a box in which it will sit because it will fit.

But.

I can only get NVDA to read when I use aria-labelledby, not aria-describedby.

So I went to a W3 example and put this code in an empty HTML5 page.

It reads Lady MacBeth but never reads the content of p1. If I arrow-up and down into the img is does not read it. If I hit Enter on the img or even click it with a mouse, it does not read it. I even tried right-left arrowing into the img but it never seems to act on the aria-describedby attribute.

Searching 'using aria to describe an img' seems to suggest using aria-describedby is perfectly normal.

Am I missing something?

I am loathed to use aria-labelledby (which seems to work) when in this case aria-describedby seems the correct attribute.

Thanks.

@alanfluff
Copy link

@alanfluff alanfluff commented May 3, 2019

Extra: In Firefox, this behaviour is identical, except if I mouse-over the img then the p1 content is read.

I cannot get it read wth Enter or Space on the img and Chrome does not provide this mouse-over output.

@alanfluff
Copy link

@alanfluff alanfluff commented May 3, 2019

This looks like an explanation, if it is, props to powermapper for stating this (I've not read this anywhere else yet):

Note: aria-describedby maps to the accessible description of an object, and is usually only read when a "Say Description" keyboard shortcut is pressed. This is different to the accessible name which is generated from alt / aria-label / aria-labelledby.

Is this the answer and all is well, I just need to have in the alt something like ...please use your say description key to hear a long description?

@alanfluff
Copy link

@alanfluff alanfluff commented May 3, 2019

I cannot find an NVDA ""Say Description" keyboard shortcut", if I use NVDA key + D then I am told there is no long description (as I assume that looks for the longdesc attribute).

So looks like I am still stuck and use of aria-describedby with an img is a no go? Am I really right to conclude that?

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.