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

Matt,

If you are suggesting this isn't a problem that must be addressed in ARIA
1.1, then we should go with none of the above. As far as the text goes I
prefer option 3 as it is the easiest to understand.  However, I doubt most
developers will be able to interpret any of the options as a solution to a
problem and that putting in any of the options will end up being a hack for
a small group. Since we have folks that insist on always being backward
compatible, the hack will never go away, even if a clean solution is
adopted in ARIA 2.


                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: Matt King <a11ythinker@gmail.com>
To: "ARIA Working Group" <public-aria@w3.org>
Date: 07/05/2016 05:29 PM
Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal
            for handling the role description value of ""



I vote for option 3 in the below proposal. If option 3 is not acceptable to
the group, I vote for option 1.

While allowing ARIA to wipe out screen reader announcement of an element’s
role with an empty roledescription makes ARIA more flexible, I think it is
unnecessary flexibility that increases the risk of negative side effects
and makes debugging problems more complex for authors. As a screen reader
user, I already find roledescription scary enough without this added
complexity.

Matt King

From: Matt King [mailto:a11yThinker@Gmail.com]
Sent: Tuesday, July 5, 2016 1:53 PM
To: ARIA Working Group <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