Re: Significant ambiguities in aria-roledescription

Birkir,

One of the use cases for role description came from the education industry and it was discussed at TPAC. Mark Hakkinen stated that there was a disconnect in the classroom as ARIA widgets did not connect with what the teacher was presenting. Consequently, blind users were out of context with what was provided in the class.

Example: Your teach is referring to a pizza with slides on a web page to the class. He is referring to the slices of the pizza and how you can select each slice. At the end of the day this might be implemented as a list box but when the teacher refers to a pizza with slices (each option) the blind user cannot draw a connect. 

So, I agree that in most cases its misuse is problematic for blind users but there are instances where it is extremely important. Also, even in those cases we must be able to refer back to the actual underlying widget semantics. 

It is *extremely* important that our authoring practices clearly state when and how to use this feature. For example, we don’t want the author to immediately stick a role description on everything. That would be very BAD. 

So, I agree with your concerns but there is a need for it and we need to make sure our authoring practices are solid. 

I agree with you about the screen reader view. It is important that we not focus solely on screen reading as ARIA’s value is much more than that. For example, Dragon Natually Speaking, for the longest time, did not process ARIA markup and could not find submit buttons on many pages.  ARIA is extremely valuable for alternative input and low vision solutions. Do to the proliferation of Rich Internet Applications these ATs need to be able to work with ARIA and leverage it. We need to do better education. Perhaps this is an EO issue I should address.

Rich




> On Jul 7, 2016, at 8:39 AM, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote:
> 
> Rich
>  
> Speaking for myself (and I think that is Matt’s point as well, though I am not going to presume that).
> I think our opinions align more closely with yours than you are perceiving from this thread.
> I am worried that this property (aria-roledescription) appears to be created primarily for the benefit of screen readers. I feel this rproperty, though well intentioned, does not really help screen reader users, not with the ambiguities in the spec.
>  
> Sadly, in practice, ARIA is primarily perceived as a screen reader only solution, primarily because of the lack of a.t. / user agent implementation outside of the screen reader space (which is not the fault of the spec).
> But we all want to change this and transform ARIA into a true magic bullet for the largest possible group of people. To that end, any roles and attributes that we can create and target the widest group of users and assistive technologies should have priority over roles that appear to primarily target screen readers.
> That being said, perhaps I am simply not thinking outside the screen reader box enough.
> As you pointed out, there are applications of this property outside of the screen reader space.
>  
> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Thursday, July 7, 2016 9:11 AM
> To: Matt King <a11ythinker@gmail.com>
> Cc: ARIA Working Group <public-aria@w3.org>
> Subject: Re: Significant ambiguities in aria-roledescription
>  
> Matt, 
>  
> While I understand your point, the group’s job is not to design the screen readers for them.
>  
> It is certainly beyond the scope of ARIA 2.0 of directing screen readers how to design their UI. 
>  
> Remember, screen readers have the ability to access the actual semantics. They could so something as basic as 
>  
> - listitem represented as fruit
> - say fruit and then query the actual role of the object. 
>  
> Another concern I have is we are making this all about the blind. Onscreen keyboards can also use this information. I don’t want the ARIA specification mascarading as only a solution for the blind. What you are asking is a slippery slope. 
>  
> Screen reader vendors don’t want us dictating their UI to this degree either.
>  
> I can understand in some cases how you might want to have screen readers address some issues but this is going over the top.   
>  
> Rich
>  
>> On Jul 7, 2016, at 3:17 AM, Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>> wrote:
>>  
>> We have 2 significant ambiguities of which I am now aware in aria-roledescription even with the additional normative statements I added in option 3 of the below proposal.
>>  
>> Ambiguity #1: role none with a role description:
>> <img role=”none” aria-roledescription=”Gotch ya”>
>> <table role=”none” aria-roledescription=”layout table”> <>
>>  
>> What would end up in the AX tree? What should a screen reader say?
>>  
>> Ambiguity 2:  role description on an element whose role is normally suppressed by screen readers:
>> <ul>
>> <li aria-roledescription=”fruit”>Apple</li>
>> <li aria-roledescription=”fruit”>Banana</li>
>> <li aria-roledescription=”fruit”>Orange </li>
>> </ul>
>>  
>> Should screen readers be expected to announce each list item as a fruit? Or, should the screen reader be able to use normal processing for the listitem role and not speak the role description?
>>  
>> It would be a pretty significant issue for authors if every screen reader came up with their own idea about what to do.
>>  
>> Matt
>>  
>> From: Matt King [mailto:a11yThinker@Gmail.com <mailto:a11yThinker@Gmail.com>] 
>> Sent: Tuesday, July 5, 2016 2:28 PM
>> To: 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 “”
>>  
>> 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 <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 <http://rawgit.com/w3c/aria/action2092option1/aria/aria.html>
>>  
>> [2] action2092option2 branch:
>> http://rawgit.com/w3c/aria/action2092option2/aria/aria.html <http://rawgit.com/w3c/aria/action2092option2/aria/aria.html>
>>  
>> [3] action2092option3 branch:
>> http://rawgit.com/w3c/aria/action2092option3/aria/aria.html <http://rawgit.com/w3c/aria/action2092option3/aria/aria.html>
>>  
>> Matt King