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

That's cool ... All screen readers should have a WTF command!

Joanie, I have to disagree that silencing announcement of the role of an elemnt is a harmless hack. As you observe, you could reduce harm by limiting it to non-interactive elements. But, that too is more complexity in support of little or no benefit.

However, even on structural elements, silencing a image, list, table, heading, etc., are also situations that would harm users, and potentially in a significant way.

Even assuming a user will think to use a WTF command is a pretty big leap. They are more likely to say WTF at some point but without having any idea of the actual cause of their frustration.

Matt

-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Wednesday, July 6, 2016 8:35 AM
To: Schnabel, Stefan <stefan.schnabel@sap.com>
Cc: 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 ""

Hi Stefan, all.

Regarding your question: "native" role detection by whom? The AT or the user?

TL;DR: ATs can still detect the real role. ATs can optionally present the real role to the user if that's what the user wants. BUT that's only true if aria-roledescription is used. If a role is used instead, all bets are off.

Verbose version:

Because the value of roledescription does NOT stomp on the native role itself, it does NOT impact the AT's *ability* to present an element.
Given the following from your list of examples:

> 2)  <button aria-roledescription=””>Save</button>
> 4)  <button aria-roledescription=”link”>Save</button>

An AT on my platform (and I'm pretty sure, on all the platforms):

1. Knows the element is a button.
2. Gets appropriate events (e.g. object:state-changed:pressed) 3. Can use the appropriate API to interact with the element
   on behalf of the user (e.g. the "press" or "click" action)

The expectation held by authors is presumably that the AT SHOULD not speak/display "button" to the user; it SHOULD instead say nothing for your example 2 and "link" for your example 4. So the user might not immediately detect the real role.

Why do I say "might" and "immediately"? Because an AT could look at your example 2 and decide that we have a very bad author. After all, a good author would never completely obliterate the presentation of the localized rolename on an interactive element. But if the author did so, and if the user agent didn't ignore it, the AT still has the option to ignore what the author specified and present "button" instead. In which case, the user immediately detects/knows the real role.

Alternatively or additionally, an AT could always respect the rolename provided by the author, but also have a special command to present detailed information about an element upon request. For instance, the following scenario might occur:

1. User presses Tab to give focus to the element.
2. Screen reader speaks "Save" (ex. 2) or "Save link" (ex. 4) 3. User is puzzled and presses CapsLock+W (the WTF command on a laptop) 4. Screen reader speaks "Save, button" or "Save link, button"

Long way of saying that I think aria-roledescription="" is a hack. BUT it's a harmless enough hack. And if the main use case we're trying to accomplish is "don't speak 'image'", this hack should be able to get the job done safely.

Contrast that with this tweaked version of your example 4:

    <button role="link">Save</button>

An AT on my platform (and possibly the other platforms):

1. Knows (or more accurately, "fully believes") the element is a link.
2. Might NOT get the appropriate events:
   a. No object:state-changed:visited upon activation
   b. Might still get object:state-changed:pressed upon activation 3. Might NOT be able to use the appropriate API to interact with the
   element on behalf of the user (e.g. the screen reader command to
   speak the URL fails because the hyperlink interface isn't properly
   implemented because the element isn't really a link; the screen
   reader always reports the "link" is unvisited because STATE_VISITED
   is absent from the accessible state set as a result of the element
   not really being a link).

If the user presses CapsLock+W here, there's not much (and there may not be anything) the AT can do to get the real story and share it with the user. As I said above, if the author changes the role (as opposed to the roledescription), all bets are off and ATs have to hope the author and user agent got things right.

HTH.
--joanie

On 07/06/2016 04:39 AM, Schnabel, Stefan wrote:
> Hi Matt,
> 
>  
> 
> I’d like to ask (using concrete examples) how the actual Core 
> Accessibility Mapping 
> <http://w3c.github.io/aria/core-aam/core-aam.html>
> of aria-roledescription
> <http://w3c.github.io/aria/aria/aria.html#aria-roledescription> will 
> influence the “native” role detection.
> 
>  
> 
> /Characteristics:/
> 
> *Characteristic*
> 
>  
> 
> *Value*
> 
> *Used in Roles:*
> 
>  
> 
> *All *elements of the base markup
> 
> *Value:*
> 
>  
> 
> string <http://w3c.github.io/aria/aria/aria.html#valuetype_string>
> 
>  
> 
>  
> 
> */ARIA 1.1] aria-roledescription
> <http://w3c.github.io/aria/aria/aria.html#aria-roledescription>/*
> 
> *MSAA + IAccessible2*
> 
>  
> 
> Expose the description string in
> IAccessible2 localizedExtendedRole property.
> 
> *UIA*
> 
>  
> 
> Localized Control Type is <value>.
> 
> *ATK/AT-SPI*
> 
>  
> 
> Expose the description string in object attribute roledescription:<value>.
> 
> *AXAPI*
> 
>  
> 
> AXRoleDescription: '<value>'.
> 
>  
> 
>  
> 
> With other words, what will be the expected speech output on element 
> focus (including role, value, label and other) according to the 
> current CAM when testing the code below on all platforms above?
> 
>  
> 
> For instance, in UIA, I expect role identification override issues 
> when the mapping remains as  currently. Also, I am not sure if every 
> role/ roledescription combination has already been pre-evaluated for 
> potential conflicts. IMHO, it is also important to separate clearly 
> between what can be done in the UA Mapping and what are the “additional”
> expectations  that AT has to fulfil. The latter should not remain 
> lugubrious.
> 
>  
> 
> 1)  <button aria-roledescription=”emphasized”>Save</button>
> 
> 2)  <button aria-roledescription=””>Save</button>
> 
> 3)  <button aria-roledescription=” ”>Save</button>
> 
> 4)  <button aria-roledescription=”link”>Save</button>
> 
>  
> 
> 5)  <label for=”i1”>Amount</label><input id=”i1”
> aria-roledescription=”extended” value=”20”/>
> 
> 6)  <a href=”(http ref) aria-roledescription=”button”>More Info</a>
> 
> 7)  <span role=”alert” aria-roledescription=”I am a something type of 
> error” aria-label=”Something happened”/>
> 
> 8)  <span role=”application” aria-roledescription=”I am a custom 
> something”/>
> 
>  
> 
> I think the discussion will benefit from when we are distinct here and 
> willing to actively scan for potential contradictions.
> 
> I can do more examples on request.
> 
>  
> 
> Best Regards
> 
> Stefan
> 
>  
> 
>  
> 
>  
> 
> *From:*Matt King [mailto:a11ythinker@gmail.com]
> *Sent:* Mittwoch, 6. Juli 2016 00:09
> *To:* 'Rich Schwerdtfeger' <richschwer@gmail.com>
> *Cc:* '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 ""
> 
>  
> 
> Option 1 and 3 both specify that a value that is empty or only white 
> space does exactly that; it does not change the processing of the 
> element b/c the roledescription is not exposed.
> 
>  
> 
> *From:*Rich Schwerdtfeger [mailto:richschwer@gmail.com]
> *Sent:* Tuesday, July 5, 2016 2:51 PM
> *To:* Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>
> *Cc:* 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 ""
> 
>  
> 
> … 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
> 
>  
>

Received on Thursday, 7 July 2016 09:07:56 UTC