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

Hi Steve,

I appreciate your response.  Let me try to make a clearer attempt at describing my concern here. I realize that failing to provide proper alt text for non-redundant, informative imagery is a failure of 1.1.1.  I wasn't trying pass those snippets off as valid, accessible HTML.  I was trying to put forward the type of code I've seen throughout my career when I've audited sites that are built by well-meaning folks who are not quite sure how to code accessibly.

And, I sincerely hope web production folks get their 1.1.1 errors all cleared up before they come to vetting their content for SC 2.4.12. And that's because, if they don't,  and they are assessing the pass/fail for SC 2.4.12 within the bounds of the SC language  and glossary-referenced terms themselves, there is a real chance that these non-expert web production folks are going to get it wrong here.

Consider David's code snippet again:
<img src="go.jpg"><input aria-label="search" ...>
It seems so obvious to us experts that there is a deeper error that must be addressed in the code above first before we worry about "label in name." However, to the uninitiated, it is likely that they'll read solely within the bounds of a particular SC to vet that "rule" without consideration of the larger standard.  A lot of well-meaning folks are not going to count CSS-generated label images and/or inline images with missing alt text as part of the "label" as defined in the glossary.

Again, that definition of "label" (in part) reads "text or other component with a text alternative that is presented to a user to identify a component within Web content..." Consider a QA tester who has a dedicated role to test SC 2.4.12, plus a few other SC checks.  He checks the page code and finds a graphic next to a search input.  But the graphic doesn't really fall in to a bucket of "text or other component with a text alternative." So, in reading the SC and its linked definition, he makes the decision that the graphic isn't part of the label and does not need to be included as part of the name.  It may seem farfetched, but in my professional experience, this is exactly the type of scenario that will likely play out in real practice for many people who are just trying to follow the rules.

Thanks for the CSS tip!


From: Repsher, Stephen J []
Sent: Friday, September 29, 2017 2:22 PM
To: Newton, Brooks (Legal);
Subject: RE: Problem with definition of "label" linked in SC 2.4.12

Hi Brooks,

Both of the code snippets below are 1.1.1 failures - you cannot have an image without a text alternative (unless it is purely decorative and explicitly hidden from AT via alt="" or aria-hidden="true").  It's not decorative if it's a label.  So the first snippet should be something like:.
<label><img src="go.jpg" alt="Go"><input ...></label>

And yes there is a means to providing alternative text via CSS inserts using ARIA (although this is also documented as a failure for using CSS to insert non-decorative content, although most developers do it anyway):
<label><span class="go-graphic-via-css" role="img" aria-label="Go"></span><input ...></label>

PS - If the CSS is using the content property, you can also insert alternative text like this:
class::before {  content: url(...) / "alt text"; }

From:<> []
Sent: Friday, September 29, 2017 2:23 PM
Subject: Problem with definition of "label" linked in SC 2.4.12

Hi All,

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.

I'm not OK with the definition of "labels" we are linking to in the text of SC 2.4.12<>.

Here's the SC language from 2.4.12:

"For active user interface components<> with labels<> that include text, the name<> includes the text of the label."

Here's is the linked definition of "labels" from the previous sentence:

text<> or other component with a text alternative<> that is presented to a user to identify a component within Web content<>
A label is presented to all users whereas the name<> may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
The term label is not limited to the label element in HTML.
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.  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.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Brooks Newton
Sr. Accessibility Specialist, Legal UX

Thomson Reuters
the answer company

Mobile: +1(918) 316-3949<>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Received on Friday, 29 September 2017 20:37:08 UTC