Tech failure name not label text

[detlevhfischer]

Rawgit version:
https://rawgit.com/w3c/wcag/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html

[patrickhlauke]

would it be possible to have some actual <pre><code>...</code></pre> blocks that show the markup, rather than just explaining it in prose, for the failures?

[detlevhfischer]

@patrickhlauke code examples - that should be doable (just a matter of having too many balls up in the air). :)

[lauracarlson]

+1

[detlevhfischer]

Have added example code for the three examples.

[allanj-uaag]

+1

…

On Wed, Aug 29, 2018 at 9:48 AM Detlev Fischer ***@***.***> wrote: Have added example code for the three examples. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#457 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG_WLyuuQ0nbanPvzfxy4jV5DE9xPjb8ks5uVqm_gaJpZM4WGJdD> .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

[detlevhfischer]

Changed last example from button to input, for variety. It would be nice if someone with easy access to speech input software like Dragon could confirm on this page under Example 2 that the input can indeed not be activated by speaking "click search" or "click button search" (according to the Dragon cheat sheet there is no independent command for speech-activating inputs, which are visually indistiguishable from buttons anyway, so that makes sense).

[marcjohlic]

+1

Looks good! There is something about this sentence though that was hard for me to parse:

When techniques such as the use of accessibly hidden text, aria-label, or aria-labelledby attributes are used to add to the visible label text in order to provide more context, and this addition is placed before the visible label text, speech users may equally be unable to directly activate that control.

Perhaps re-swizzle it to:

When techniques such as the use of accessibly hidden text, aria-label, or aria-labelledby attributes are used to provide more context to the visible label text, and this addition is placed before the visible label text, speech users may equally be unable to directly activate that control.

[jake-abma]

Failure example 3:

Because label takes precedence over the value

=> Because aria-labelledby takes precedence over the value

[detlevhfischer]

@jake-abma agree with all your suggestions for rewording and will implement - not sure about extension to iOS / Android, though. Why pull in the OS level? There may be differences in support for things like concatenation of accName text but it seems irrelevant to me whether this in the mobile OS/ UA field or on the desktop

[goodwitch]

Hey Y'al, I was experimenting with this failure technique today...and created a little testing page at http://glendathegood.com/a11y/WCAG21/a11ynamefailures.html

Then I tested using the following:

• Dragon Professional Version 15
• Chrome (with Dragon Web Extension installed)
• Windows 10

My results...were not what I expected at all. Maybe it is the default Dragon settings? Or Dragon and Chrome.

1. Example 1 works (whether I say "Click Cat" or "Click Dog".
2. Example 2: It only works when I say "Click A. C." (it ignores me when I say "Click A. B. C.")
3. Example 3: It only works when I say "Click Bong" (it ignores me when I say "Click Bing")

Any ideas why I'm getting these odd results?

[awkawk]

A few things:
Example 1 - it would be interesting to see what happens when you use aria-labelledby for this case.

Example 2 - visibility:hidden hides the info from assistive technologies also, perhaps you should try hiding the link text without using that.

Example 3 - I'm not sure if this is not behaving the way you expect because it is using labelledby instead of label (part of the reason for my example 1 suggestion) or if inputs with type=submit are just different from buttons. Perhaps a 3b with aria-label?

[goodwitch]

Hey @awkawk thanks for the suggestions. Let me tell you why I did what I initial did:

Example 1: I used aria-label because I was following exactly what I saw documented as a failure (in example 1 in this rawgit version https://rawgit.com/w3c/wcag/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html )

Example 2: Doh! I just removed the "visibility:hidden;"
@detlevhfischer I suggest you might want to change the following line in this example to read "accessibly-offscreen" instead of "accessibility-hidden" to prevent people like me from making a silly mistake.
Download gizmo specification

Example 3: I used aria-labelledby because I was following exactly what I saw documented as a failure (in example 2 in this rawgit version https://rawgit.com/w3c/wcag/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html )

I'll add an Example 1_5 (and use aria-labelledby)
I'll add an Example 3_5 (and use aria-label)

See the latest at http://glendathegood.com/a11y/WCAG21/a11ynamefailures.html

I'm headed into an onsite client gig that will keep me off-grid until after October 1st. So, if I'm quiet, is because I have not figured out how to clone myself.
G

[mraccess77]

@goodwitch For #1 I believe Dragon is smart enough to either work on the button's native semantics or what is provided in the accessible name calc through ARIA. I imagine this could mean that it relies both on DOM and accesibility API or something like DOM and proprietary reading of ARIA properties via the DOM.

For #3 there are some known issues with Dragon working with aria-labelledby inconsisently on different controls. This has been a long running issue and has also been discussed on WebAIM if you are looking for some context.

[alastc]

For all controls with a visible label (e.g. link text, button text, programmatically linked label, value of input), check if

Are images of text included? This is the most common type of this issue we have been finding so far.

Re: iOS/Android, I'd avoid specific references to those for native apps. They can use web-content in apps, but I don't think refering to the specific coding of native apps in used for that.

I'm struggling to follow the UA testing here, are people happy that this works as intended? (Or rather, doesn't work as intended!)

[mraccess77]

I'd say images of text are included.

[patrickhlauke]

Are images of text included?

my interpretation has been that yes, they are / they count as a "visible label" in my mind. The fact that they're not listed in the parenthetical that follows is irrelevant, as that list is not exhaustive. Would be good to clarify in understanding/add an example in understanding to that effect though.

[mbgower]

typo: elemwents

[jake-abma]

+1

[Ryladog]

+1 for Me and +1 for Glenda who did some testing on this

[goodwitch]

+0.5 (y'all can move forward. if I discover something in future testing...I'll just ask another question)

[michael-n-cooper]

I pushed a commit to normalize the applicability statement, otherwise looks good.