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

Hi Joanie,

> 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>

Based on the markup, it's an author error.  That is, the intended name 
of the radio button is "yes".  The problem is that the author is 
providing it twice using two labelling techniques.  They should use 
either one or the other.

> We are, I believe, telling user agents to:
>
> 1. Calculate the name of the label from contents
>
> 2. Expose an accessible labelled-by/label-for pair between the radio
>     button and label
>
> and then telling ATs to ignore the result of the above.
>
> If the AT should ignore it, wouldn't it make more sense -- and be more
> performant -- for the user agents to not do the above two items?

According to both the core-am text alternative calculation, and the 
html-aam [1], only the aria-label attribute should be used in this 
case.  The <label> should be ignored.  As such, no labelled-by/label-for 
relationship should occur.  The browser is failing to follow the algorithm.

However, (pure speculation ahead, take with a grain of salt) this is 
tricky markup to process.  The browser encounters the <label> element, 
and generates the radio button's accessible name and the 
labelled-by/label-for relationship.  At some other point, it processes 
the <input>, detects the @aria-label, and replaces its accessible name 
with the aria-label text, ending up with 1 and 2 above.  What the 
browser would have to do to fix this is to track all possible names and 
label relationships for this one <input>, and modify names/relationships 
as it processes more elements, and only if a higher precedent labelling 
technique is encountered.  That is a more complicated algorithm.


[1] http://w3c.github.io/aria/html-aam/html-aam.html#other-form-elements

-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Tuesday, 22 September 2015 15:08:06 UTC