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

To move on to ARIA 2.0, I am still hoping it is possible to build consensus around the proposal to postpone the static text role without using a roledescription hack as a stopgap.

 

I think we should step back and really examine the benefits and risks of the static text role and/or the roledescription stopgap solution.

 

As I understand it, only one possible accessibility benefit has been offered in support of this solution -- reducing screen reader verbosity. Screen readers will less often speak the word “image” or “graphic” if we have one of these solutions available.

 

Risks:

1.       The reduced verbosity removes useful semantic information.

2.       The suppressed information also suppresses useful user agent functionality.

3.       The likelihood of misuse and overuse due to misunderstanding is high.

4.       Misuse could render huge chunks of content completely inaccessible.

 

Where other roles and properties have these last 2 risks, they also have huge upside, e.g., the ability to make completely inaccessible content fully accessible. The verbosity reduction that could be achieved with one of these solutions does not have that huge upside.

 

It is also important to consider the frequency or pervasiveness of circumstances where using the text role or roledescription=”” would be the most appropriate or beneficial solution. While they may exist, it has been very difficult to find them. 

 

Matt

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Tuesday, July 5, 2016 3:31 PM
To: James Nurthen <james.nurthen@oracle.com>
Cc: public-aria@w3.org
Subject: Re: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

 

James, 

 

I agree it is a hack. This is temporary. I agree with your reasoning for option 2 even though I understand Matt’s position as we enabling authors with another tool to manipulate how a role is presented verbally to the user. Yet, in the absent of a special role to handle this case this is what we have. 

 

James Craig indicated we should not make this a recommended technique. I agree but it should be a valid option for authors until we release an alternative. 

 

As much as I agree with Matt’s proposal for 1 and 3 we will not reach consensus if we choose 1 or 3 and we will be back to the stale mate we had in the past. I don’t want to open up that can of worms again and we need to get on with ARIA 1.1 so that we can address, frankly, much larger issues with ARIA 2.0. 

 

Rich

 

Rich Schwerdtfeger

 

 

 

On Jul 5, 2016, at 5:09 PM, James Nurthen <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com> > wrote:

 

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 

 <http://www.oracle.com/> <oracle_sig_logo.gif>
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 <mailto:james.nurthen@oracle.com>  
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment 

 

Received on Wednesday, 6 July 2016 10:18:10 UTC