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>; '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 ""

 

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