Re: Problem with definition of "label" linked in SC 2.4.12

>>  <form><input type=“text” aria-label=“search”/><input type=“image”
src=“go.jpg”/></form>

​> ​
I
​​
would say that this would pass 4.1.2 for the text input but 2.4.12 wouldn’t
apply since there is no visible label (at least in my example)

​Isn't the section input in this example a visible label? It should fail
the new SC, because the Dragon user will say "click go" and nothing will
happen.​


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Sep 29, 2017 at 6:34 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Brooks,
> I separated this comment out from the CFC thread at Andrews request, but I
> do think it is relevant to the discussion of the language used in SC 2.4.12.
>
> Thank you!
>
> I’m not OK with the definition of “labels” we are linking to in the text
> of SC 2.4.12
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Faccessible-name-terminology-sync%2Fguidelines%2F%23label-in-name&data=02%7C01%7C%7C327754c7801c4b4de84f08d507676cc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423063155253291&sdata=1KuBJV0%2F%2BYVBgHnz0rD77X3Ou3UlvS11CJgypeEgQrM%3D&reserved=0>
> .
>
> This definition is unchanged from WCAG 2.0, and the group’s intention was
> to not change it.
>
> If you go back to David’s basic example of an inline “Go” graphic without
> alt text next to a search input with aria-label text of “Search,” we’ve got
> a situation that passes SC 2.4.12 because there is no “component with a
> text alternative.”
> David’s example scenario code:
>
> <img src="go.jpg"><input aria-label="search" ...>
>
> Want to pass S.C. 2.4.12 and still have a fundamental disconnect between
> what’s visible onscreen and what’s announced by AT as the “name” of the
> “user interface component,” just leave out the alt text!  The go.jpg
> graphic in David’s example doesn’t have a text alternative, and under the
> definition of “label” we are using, shouldn’t be considered part of the
> label.
>
> I’m not clear on what this code is showing. Is this “go” image a submit
> button? (it is hard to tell since there is so little context).
>
> If this is trying to show something like:
> <form><input type=“text” aria-label=“search”/><input type=“image”
> src=“go.jpg”/></form>
>
> I would say that this would pass 4.1.2 for the text input but 2.4.12
> wouldn’t apply since there is no visible label (at least in my example)
> I would also say that the image would fail 4.1.2 and 2.4.12 – 4.1.2
> because it is a control with no name and 2.4.12 because the visible label
> can’t match the programmatic name since there isn’t one defined. If the
> image had alt=“go” then it would pass both.
>
> What would happen in the “Go” graphic were implemented into the page via
> CSS, which has no direct means of apply alternate text?
>
> <span class=”go-graphic-via-css”></span><input aria-label="search" ...>
>
> In my opinion, the definition of “labels” needs to be adjusted to make it
> clear that images of text, whether they have alternative text or not,
> should be considered part of a label.
>
> Interesting, I see the issue. I’m going to look back at some of the past
> responses from the group to see if this has come up.
>
> Thanks,
> AWK
>
>
>
> · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
> · ·
>
>
>