RE: Bad authoring? Bad name computation? Something else?

That's my understanding as well.

I recently added this as a description for the Alternative Text Calculation at
http://whatsock.com/training/matrices/visual-aria.htm#alternative-text-calculation


Which conveys the same.


-----Original Message-----
From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
Sent: Monday, September 21, 2015 3:40 PM
To: Joanmarie Diggs <jdiggs@igalia.com>
Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org>
Subject: Re: Bad authoring? Bad name computation? Something else?

The aria-label comes after aria-labelledby and before the native labeling mechanism in the accessible name computation algorithm.
What the spec is not clear on, in my understanding, is whether user agents who have discovered one source of accessible name should stop and expose that name to the a.t., or whether they should continue looking for other sources and expose these as well.
e.g.
<span id="yeap">Yes</span>
<input type="radio" aria-labelledby="yeap" aria-label="no way" id="r1"> <label for="r1">green</label>

According to ANCA the accessible name should be "yes".
If you look at all possible sources of the name the accessible name should be "yes no green".

My understanding is that all a.t. applications need to adhere to the accessible name calculation algorithm.
It is documented to help developers expose the accessible name in a predictable way.
If some a.t. follow it, others choose not to, it makes the whole concept pretty useless.
In the particular case you showed, it is just a matter of bad coding, and we cannot fix that through use of standards (goodness knows I wish we could sometimes).
I have always found the priorities in the ANCA a little strange, I would have thought that if a label can be derived from the host language labeling mechanism that it should be the first choice of an element's accessible name.
But I am sure there are reasons, and I have always advised developers to follow that algorithm when they need to communicate the accessible name of an element in unconventional ways.



On 9/21/15, Joanmarie Diggs <jdiggs@igalia.com> wrote:
> Hey all.
>
> The following test case is based very closely on something in the wild:
>
> <label>
>   <span>
>     <input role="radio" aria-label="yes" type="radio">
>   </span>
>   <span>yes</span>
> </label>
>
> The way that radio button being exposed on my platform is:
> * accessible name: "yes"
> * labelled-by relation pointing to label with name: "yes yes"
>
> An Orca user reported that Orca is double-speaking the radio button 
> name ("yes yes"). This is because in the case of radio buttons Orca 
> prefers the accessible label gotten from the accessible relationship.
>
> Arguably I could solve the user's problem by having Orca prefer the 
> name instead. But then consider this version:
>
> <label>
>   <span>
>     <input role="radio" aria-label="well, maybe..." type="radio">
>   </span>
>   <span>no</span>
> </label>
>
> That radio button has:
> * accessible name: "well, maybe..."
> * labelled-by relation pointing to label with name: "well, maybe... no"
>
> Given that the label/value sighted users read is "no," it seems to me 
> that preferring the radio button's name would result in the user 
> missing out on important information and thus is not what I should have Orca do.
>
> I'm not sure if this is something we should fix in the authoring 
> guide, the ARIA spec, the name computation spec, or the mapping guide. 
> But I think the current user experience that is resulting is less than ideal.
> And expecting the ATs to have to examine each label+name pair to see 
> if one is contained in the other is not the way to fix it.
>
> Thoughts?
> --joanie
>
>

Received on Monday, 21 September 2015 22:59:34 UTC