Danny Wieser Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36

Steps to reproduce:

Attempting to use aria-labelledby in conjunction with aria-describedby to provide screenreader users with a two-part, detailed announcement of the purpose/usage of an element.   

Firefox 40.0 with Voiceover on Mac 10.10.5



Actual results:

When element receives keyboard focus, the contents of aria-labelledby is completely ignored, Firefox/Voiceover reads on the description, followed by "button"

Example: "Item 1 Description button"


Expected results:

When element has keyboard focus, both the contents of aria-labelledby and aria-describedby should be read by the screenreader.

Example: "Item 1 Label Button, Item 1 Description"

Note that Windows 7/Firefox 40.0.2/JAWS 16 works as expected.

	Danny Wieser Reporter
	Comment 1 • 9 years ago

The MDN documentation for aria-describedby (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute) indicates "a label describes the essence of an object, while a description provides more information that the user might need."  

This description conveys the essence of what we're trying to accomplish with using the two attributes in conjunction, and why it is incorrect for only the description to be announced by the screenreader.

	Marco Zehe (:MarcoZ) Assignee
	Comment 2 • 9 years ago

I can confirm this bug. The label and descriptions are correctly calculated. But the translation to the Mac a11y layer is faulty somehow.

	Marco Zehe (:MarcoZ) Assignee
	Comment 3 • 9 years ago

What I believe is happening is this:

1. We expose the AccName as the NSAccessibilityTitle attribute as is the correct mapping.
2. In current Firefox, the NSAccessibilityDescription attribute is mapped to the AccDescription. This seems to be obvious from the name, but I believe Apple's definition of this description differs from the rest of the world's. If present and filled, it seems to override everything else, and in our case, always exposes the AccDescription, which trumps the title and possibly other attributes related to describing the element.
3. For theory in 2 speaks that Safari and Chrome expose the equivalent of our AccDescription as NSAccessibilityHelp attribute. Various test pages with aria-describedby confirms that.

So I did the following, but because it's the end of my day, I didn't test it yet:

1. Get rid of the NSAccessibilityDescription attribute. This will make sure (in theory), that all our AccNames are always used.
2. Switch to using AccDescription instead of AccHelp as the mapping for the Mac NSAccessibilityHelp attribute, as is done in Safari and Chrome. I believe Apple doesn't even have a mapping for the MSAA acc_help thing, which I believe relates to some Windows help file originally, if memory serves me right.

David, I am throwing this to you to tell me if I'm making any sense here. ;)

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 4 • 9 years ago

Comment on attachment 8652397 [details] [diff] [review]
Use AccDescription when exposing the NSAccessibilityHelp attribute, and get rid of exposing the NSAccessibilityDescription attribute

Review of attachment 8652397 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah makes sense to me to follow Safari here.

	Marco Zehe (:MarcoZ) Assignee
	Comment 5 • 9 years ago

Comment on attachment 8652397 [details] [diff] [review]
Use AccDescription when exposing the NSAccessibilityHelp attribute, and get rid of exposing the NSAccessibilityDescription attribute

This fixes the problem indeed! And no adverse effects AFAICS.

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 6 • 9 years ago

Comment on attachment 8652397 [details] [diff] [review]
Use AccDescription when exposing the NSAccessibilityHelp attribute, and get rid of exposing the NSAccessibilityDescription attribute

Review of attachment 8652397 [details] [diff] [review]:
-----------------------------------------------------------------

OK with me. Sort of weird that description can just be dropped. I'd like surkov to take a look.

	alexander :surkov (:asurkov)
	Comment 7 • 9 years ago

Comment on attachment 8652397 [details] [diff] [review]
Use AccDescription when exposing the NSAccessibilityHelp attribute, and get rid of exposing the NSAccessibilityDescription attribute

Review of attachment 8652397 [details] [diff] [review]:
-----------------------------------------------------------------

seems pretty straight forward from Marco's comment #3

	Marco Zehe (:MarcoZ) Assignee
	Comment 8 • 9 years ago

For reference: The standard attributes, including the now dropped NSAccessibilityDescriptionAttribute, can be found here.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/#//apple_ref/doc/constant_group/Standard_Attributes

The wording for the NSAccessibilityDescriptionAttribute is pretty vague, and given that we already define the title and help text, and that testing showed the title no longer being trumped, I think this patch is safe.

	Marco Zehe (:MarcoZ) Assignee
	Comment 9 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/f2f4c7d1bd28a023818b0f7df23dc2c3e088a42e
Bug 1198291 - Remove exposure of the NSAccessibilityDescription attribute to guarantee we always expose AccName and AccDescription correctly, r=davidb, r=surkov

	Ryan VanderMeulen [:RyanVM]
	Comment 10 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/f2f4c7d1bd28