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

In my opinion we should have a text/static role as (as I stated 
previously). The whole aria-roledescription="" thing sounds like a hack. 
If it were not for the use cases where we need the static role I would 
favour either options (1) or (3) but due to the fact that we have 
abandoned the text/static role - with one of the major arguments being 
that we could use aria-roledescription to accomplish the same thing, I 
feel we have to go for option (2).

Regards,

James


On 7/5/2016 2:50 PM, Rich Schwerdtfeger wrote:
> … or you leave the role description off altogether and the default is 
> to do nothing (don’t change how the role is processed).
>
> I do agree there is a concern that authors will put themselves in a 
> position where they try to be the screen reader vendor and influence 
> the user experience.
>
>
> Rich Schwerdtfeger
>
>
>
>
>> On Jul 5, 2016, at 4:27 PM, Matt King <a11ythinker@gmail.com 
>> <mailto:a11ythinker@gmail.com>> wrote:
>>
>> 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 <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
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment