-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessible Names Practice: Recommend association via 'for' attribute when using 'label' element #2882
Conversation
content/practices/names-and-descriptions/names-and-descriptions-practice.html
Outdated
Show resolved
Hide resolved
<pre><code><input type="checkbox" name="subscribe" id="subscribe_checkbox"> | ||
<label for="subscribe_checkbox">subscribe to our newsletter</label></code></pre> | ||
|
||
<p> | ||
The other syntax, which doesn't return the correct accessible name in as many combinations of assistive technologies and browsers, is to wrap the checkbox and the labeling text in a <code>label</code> element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the "in as many" sounds like we actually went around counting the totals. i'd generalise it more into something more like... "The other syntax is to wrap […]. However, this syntax is not supported by all combinations of assistive technologies and browsers." (if possible, i'd even be more specific and say which ones, at time of writing, have problems)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made some revisions to address this. Rather than just saying it is not supported, I tried to use words that help the reader understand what is not happening. In general, we avoid naming AT in the APG. We are plannig to provide support data that can show AT specifics via the aria-at data using the AT support tables on the example pages. Over time, that data will be able to surface in more places.
while the implicit/explicit naming isn't in the HTML spec per se, it's a fairly common way of referring to these two syntaxes https://www.google.com/search?q=implicit+explicit+html+label ... including in actual WAI material https://www.w3.org/WAI/tutorials/forms/labels/#:~:text=Associating%20labels%20implicitly,-In%20some%20situations&text=In%20this%20case%2C%20the%20label,better%20supported%20by%20assistive%20technology. |
Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>
@patrickhlauke, @a11ydoer, There is a possibility we will do a publication this week (Dec 12). If so, I'll have to merge this tomorrow (Dec 11) morning if hthis were to be included. Otherwise, it can be published on Dec 19. I'll wait for approving reviews from both of you before merging. |
@mcking65 I reviewed the changes, and it looks good. I fully understand @patrickhlauke's kind intention to help readers with non-supported browsers and AT combinations, but it would be hard to update all the details as technology advances. Furthermore, the AT project will fulfill that need. |
i would still like to see the "implicit vs explicit" mention though, based on #2882 (comment) ... developers do use that terminology, so why try to avoid it for some "the spec itself doesn't call it that"? |
Hi @patrickhlauke, Actually, I suggested a similar thing at the APG meeting last week. Use "implicit vs. explicit" concepts and link those definitions to somewhere, even in the ARIA spec. I see that WAI material used implicit and explicit concepts from your WAI reference. Can you help us to find the definitions of "explicit" and "implicit" so that we can use the words? I am also mentioning @shawna-slh in case she has any info. All the reasoning behind this is that APG is aiming for easy reading, targeting a 6th-grade reading level, aligning with WCAG 3 efforts. This approach is intended for both developers and beginners in ARIA. I've checked, and it seems that "implicit" and "explicit" may not be at a 6th-grade vocabulary level. |
@a11ydoer wrote:
I didn't realize that we had 6th-grade level is a target. I thought that there was so much dispute over the meaning of such measurement systems and the bias built into them that we were explicitly not adopting them. I have simply been striving for clear language that is not more complex than necessary.
I'm a little confused. Is this reason not to use the words "implicit" and "explicit"? If we were to add links to their definitions, it wouldn't change the grade-level of the prose. The APG text itself provides the special contextual meaning of "implicit labeling" and "explicit labeling". So, I suggest that if we add these terms to the text that we would not add definition links. The links would be more distracting than helpful because they would point to another place that provides essentially the same information that is in the APG prose. I'm not sure I understand the value of including the implicit/explicit terminology, but I will add it and people can decide if the content is or is not better with that terminology included. |
i'll admit that i seriously doubt some of the more inherently complex and technical concepts of ARIA will be (easily or at all) conveyable in simple language. in terms of adding a definition, I was thinking along the lines of my original PR - where the concept itself is explained, and then at the end adding |
+1 for keeping the language as simple as feasible thanks for tagging me to weigh in |
I updated the text to include the terms explicit association and implicit association. |
A form control can also be associated with a label by using the <code>for</code> attribute on the <code>label</code> element. | ||
This allows the label and the form control to be siblings or have different parents in the DOM, but requires adding an <code>id</code> attribute to the form control, which can be error-prone. | ||
When possible, use the above encapsulation technique for association instead of the following <code>for</code> attribute technique. | ||
HTML provides two syntaxes for associating a label with a form control. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're aiming for simplicity/understandability (regardless of reading level etc), maybe instead of referring to "syntaxes" we could just talk about "ways" here and subsequently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for considering understandability and simplicity, @patrickhlauke !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revised acordingly.
|
||
<p> | ||
The other syntax, which is known as implicit association, is to wrap the checkbox and the labeling text in a <code>label</code> element. | ||
Some combinations of assistive technologies and browsers fail to treat the element as having an accessible name that is specified by using implicit association. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be prudent to qualify this statement with "Currently, some combinations..." or similar, as the situation may well change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the bugs are fixed and this text is still present, the text will be equally inaccurate whether or not it includes the word "currently". The only way to avoid that problem would be to include a phrase like "as of December 2023", but I'm reluctant to start including such temporal prose in the APG.
So, it is somewhat risky to include any information of this nature. We have tried to avoid doing so. The long term strategy for addressing AT support is interop data from aria--at., which will be updated with each new release of a covered AT
Inspired by #2871, this is an alternative proposal for resolving #2870.
@patrickhlauke, I originally was looking at writing this as a suggestion in #2871, but it became too complicated. I appreciate the time you took to make a PR; I do not intend to be dismissive of your work on the issue.
In addition to reducing word count, here are the notable editorial differences and my reasons for proposing them. Feedback is welcome on all of them.
Preview
Preview of the proposed changes to the names and description practice
WAI Preview Link (Last built on Sun, 17 Dec 2023 08:02:10 GMT).