RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

Matt,

>>> That said, because of the additional assistive technology guidance provided in option 3, a list of graphics on the page would include this image recast as a "love" object.

I do see no contradiction here, but rather inheritance. A "love" image appearing in a list of images is a derivate, a "specialized" image.
The fact that it is *listed* in AT image collections even maintains its original role. This is way better than role override using different ARIA roles for roles of base markup.

And yes,  there can be still keyboard nav and context menu to that one, too.

As I said, the issues come when someone uses contradicting role strings in the roledescription, but we can flag this as authoring error.

Regards
Stefan


From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Donnerstag, 7. Juli 2016 10:00
To: Schnabel, Stefan <stefan.schnabel@sap.com>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com>; 'ARIA Working Group' <public-aria@w3.org>
Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

Stefan wrote:
><span>I <img aria-roledescription="love" src="heart.jpg"> New York</span>
>Should be anounced by screen reader as "I love New York".

Stefan, Very creative ...and yes, option 3 does support this.

It is extremely unlikely I would advise an author to do this because I think it is important for screen reader users to be aware of the presence of the graphic. That said, because of the additional assistive technology guidance provided in option 3, a list of graphics on the page would include this image recast as a "love" object. Similarly, a quick key for jumping to the next graphic would navigate to this "love' object. Typical users would be rather befuttled. But, geeky users could get it and still get the appropriate context menu for the image as well.

Thank you for inventing the "love" object. It is further proof we do not need either null role descriptions or the text role.

Matt

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Thursday, July 7, 2016 12:40 AM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

Matt, Joanie,

Many thanks for answering my questions.

In my opinion, the intent of option 3 is still a default override of the native role string, not as brute as for <button role="link"> but also possible.

The option that AT still can "choose" if they want to speak the native role string if they "want"  is a chip pass for diversity.

>>> <span>I <img aria-roledescription="" aria-label="love" src="heart.jpg"> New York</span>
>>>  Should be anounced by screen reader as "I love New York".

Chances are that these things are interpreted differently unless there is a crystal clear mandatory spec. And we won't get that accepted by AT vendors as I learned here.

Nevertheless I'm OK with that override if we limit the usage to NOT all elements of the base markup along with instructions for AT what exactly to do.
For instance, for an image override as in the example above  it does make sense, but not with empty string (this should be treated as not set).

Instead, there should be a clear value, as this:

<span>I <img aria-roledescription="love" src="heart.jpg"> New York</span>
Should be anounced by screen reader as "I love New York".

Let's talk about it in today's call if limitation to certain elements of base markup is an option.

For instance, personally I find things like

<div role="application" aria-roledescription="My custom control"</div>

Very useful for custom control development using HTML until ARIA 2.0 will hit the shelves.

Best Regards
Stefan



From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Donnerstag, 7. Juli 2016 08:51
To: 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

Birkir,

Yes, those are the 2 possible purposes. The intent of having multiple proposals is to determine whether the group believes it is a good idea to enable roledescription to be used as described in option 2. Or, to see if people believe that allowing an empty roledescription to wipe out speaking of a role carries risk that is not worth the suggested benefit. While I understand the flexibility that option 2 offers, I believe it carries risks that far out way the value of that flexibility. The net effect of this flexibility, when appropriately used, is nothing more than a small reduction in screen reader verbosity that is not necessarily always desirable. When inappropriately used, the net effect is potentially disasterous. And, the challenge with guiding people to appropriate use is far from trivial, especially since the circumstances where it would be justified are extremely difficult to find.  The safest guidance would definitely be to avoid using it. So, why add complexity that has high risk and questionable benefit?

Thus, my vote for option 3.

Matt

From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Wednesday, July 6, 2016 12:00 PM
To: 'Matt King' <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

If the purpose is to disambiguate the aria-roledescription use and support, I agree that proposal #3 is the one to go with.
If, however, the intension is to use aria-roledescription to provide a temporary workaround for the absence of the text role, I would have to vote for option 2 (neither option 1 nor 3 offer that functionality).
For option 2 I would add an example and a note.
The example would be use of aria-roledescription="" to remove semantic info:
<span>I <img aria-roledescription="" aria-label="love" src="heart.jpg"> New York</span>
Should be anounced by screen reader as "I love New York".
The note (or change): If the underlying role is an interactive element, user agents should ignore an empty or null aria-roledescription. That is consistent with how role="presentation"/"none" or aria-hidden cannot be used on focusable elements.
I am on record on this list as not having seen an example where the text role solved an issue for screen reader users, at least not one where an equally good or better solution could be implemented using existing ARIA roles and attributes.
Cheers
-Birkir


From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Tuesday, July 5, 2016 4:53 PM
To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

Proposals to specify how null or empty aria-roledescription values will be handled by user agents and assistive technologies are ready for review.

Following are the proposals. As I explain below, I think this exposes other ambiguities in aria-roledescription that should be plugged.

In branch action2092option1[1], added the following sentence.
"If the value of aria-roledescription is empty or contains only white space characters, user agents MUST treat the element as if the aria-roledescription property were not specified."

In branch action2092option2[2], added the following 2 sentences.
"If the value of aria-roledescription is empty or contains only white space characters, user agents SHOULD expose the value in a manner consistent with how null values are expressed in their platform accessibility API. If the value is empty or null, assistive technologies MAY render the element as if it does not have a role name."

In the process of making the above branches, I noticed that there is still significant ambiguity regarding what an assistive technology should do with the roledescription. The actual intent of the property is not clear. For example, if you provide a roledescription for a region, should the assistive technology still treat the element as a region? This ambiguity also has significant impact on the meaning of the note that tells authors how to limit the use of roledescription.

The issue of how authors, user agents, and assistive technologies may treat null or empty values increases the need to remove these ambiguities. So, I have also proposed an option 3, which equivalent to option 1 but also addresses these issues. I did not make a similar equivalence to option 2 because it is much less clear what the normative authoring and assistive technology guidance should be in that case.

In branch action2092option3[3]:
1. Stated that user agents MUST NOT expose aria-roledescription if it is empty or whitespace (same as option 1)
2. Changed the note that contained an implied normative author SHOULD limiting use of the roledescription into a normative author SHOULD.
3. Added a normative assistive technology SHOULD statement explaining that roledescription should change only how the name of the role of an element is expressed and should not change which assistive technology functions are provided for an element.
4. (editorial) Used a list format to express the authoring and user agent requirements.

[1] action2092option1 branch:
http://rawgit.com/w3c/aria/action2092option1/aria/aria.html

[2] action2092option2 branch:
http://rawgit.com/w3c/aria/action2092option2/aria/aria.html

[3] action2092option3 branch:
http://rawgit.com/w3c/aria/action2092option3/aria/aria.html

Matt King