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

Joanie,

Another interesting variation of this example is when people override
input[type=radio] with role=checkbox, this is used with some standardized
testing web applications.

<label>
  <span>
    <input role="radio" aria-label="yes" type=³checkbox">
  </span>
  <span>yes</span>
</label>



Jon


On 9/21/15, 4:53 PM, "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:55:26 UTC