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:40:24 UTC