Skip to content
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

Merged
merged 8 commits into from
Dec 18, 2023

Conversation

mcking65
Copy link
Contributor

@mcking65 mcking65 commented Dec 6, 2023

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.

  1. It describes the preferred syntax first. It seems beneficial to present the most valuable and important information first and enable people to skip over information they may not use.
  2. It uses more concrete language for explaining the reason for the preference. In particular, help people understand that it is due to specific AT/Browser combinations not calculating the correct name.
  3. It emphasizes the preference by mentioning it two times.

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).

<pre><code>&lt;input type="checkbox" name="subscribe" id="subscribe_checkbox"&gt;
&lt;label for="subscribe_checkbox"&gt;subscribe to our newsletter&lt;/label&gt;</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.
Copy link
Member

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)

Copy link
Contributor Author

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.

@patrickhlauke
Copy link
Member

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.

@mcking65
Copy link
Contributor Author

mcking65 commented Dec 8, 2023

@howard-e @ccanash

The preview link is still missing on this PR even though none of the checks are failing. Is the issue with the build workflow resolved? Is it possible to provide a preview for this PR?

@mcking65 mcking65 requested review from patrickhlauke, a11ydoer and daniel-montalvo and removed request for patrickhlauke December 10, 2023 21:00
@mcking65
Copy link
Contributor Author

@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.

@a11ydoer
Copy link
Contributor

@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.

@patrickhlauke
Copy link
Member

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"?

@a11ydoer
Copy link
Contributor

a11ydoer commented Dec 11, 2023

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.

@mcking65
Copy link
Contributor Author

@a11ydoer wrote:

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 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've checked, and it seems that "implicit" and "explicit" may not be at a 6th-grade vocabulary level.

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.

@patrickhlauke
Copy link
Member

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 This is often called <em>implicit</em> labeling. This, I'd argue, then doesn't need it own dictionary definition of what "implict" means, because if a reader doesn't understand/know that term, they still understand the concept because that explanation was not reliant on it.

@shawna-slh
Copy link

+1 for keeping the language as simple as feasible
+1 for not getting too "hung up" on calculated reading levels
+1 to where the concept itself is explained, and then at the end adding This is often called implicit labeling. -- for us old birds for whom implicit and explicit labels makes sense :-)

thanks for tagging me to weigh in

@mcking65
Copy link
Contributor Author

mcking65 commented Dec 12, 2023

I updated the text to include the terms explicit association and implicit association.

preview here

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.
Copy link
Member

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

Copy link
Contributor

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 !

Copy link
Contributor Author

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.
Copy link
Member

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

Copy link
Contributor Author

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

@mcking65 mcking65 merged commit 966c4ca into main Dec 18, 2023
7 checks passed
@mcking65 mcking65 deleted the naming-guidance branch December 18, 2023 16:38
@mcking65 mcking65 added the enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy label Jan 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants