RE: 1.4.13 Content on Hover

I’m certainly not going to defend the writing quality in WCAG because some of it is very poor and some is downright contradictory. However, the definition of a label clearly states the difference between a label, which is for all users, and the name, which may only be accessible to assistive technologies.

When creating examples of techniques, there is a balance to be struck. Ideally, you want the example to be as simple as possible, so the technique is clear to see. Adding all the other code you would need to meet other success criteria risks over-complicating the example. For instance, should the search form be in a <search> element? You could probably think of other code that would be required in a full solution.

Steve

From: Guy Hickling <guy.hickling@gmail.com>
Sent: Thursday, September 14, 2023 5:35 PM
To: WAI Interest Group discussion list <w3c-wai-ig@w3.org>
Subject: RE: 1.4.13 Content on Hover

Steve, Kevin, you are quite correct, of course, about the footnote. I suppose what I am criticising here is the language used in G167. That appears very clear in itself. Saying "When a button ... has a clear text label, ... the button also acts as a label for the input field." That makes it seem absolutely definite - the button acts as a label, so you don't need a separate label for the field! The next words reinforce that idea by saying "This label helps users understand the purpose of the field without introducing repetitive text...". Again, quite clear - you don't need to add extra text to label the field! (And a programmatic name is still text when all is said and done, whether as hidden text or as an ARIA label.)

Only below that does it show a display box with the - to some, rather strange - comment about a programmatically determined name, and doesn't say why that is needed. Experts in accessibility understand that, and they also know that is for AT and for blind people particularly. But experts probably aren't looking at the Techniques, they already know how to do things! However, developers that are doing accessibility for the first time may be somewhat vague about what such names are, and what they are for. It's newbie workers that are most likely to be looking at the Techniques in order to find out how to do things, and I think the language of this technique, in the main Description paragraph, is particularly unhelpful and misleading.And not showing the code markup for this example doesn't help either! If it just showed that, all would become clear.