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

Interesting reply, thank you. 

I was just wondering why one would add an aria-label to a radio button that already has a <label>?

—Michiel

> On 22 Sep 2015, at 00:39, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote:
> 
> 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 23:02:42 UTC