Problem with Technique G131 #307
Comments
|
This is a good point, but I think that we don't need the suggested step 4 since this technique isn't about "required" controls. We should adopt the changes in step 2 I think. |
|
+1 to adopting the changes in step 2. Question. What about H65: Using the title attribute to identify form controls when the label element cannot be used https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H65.html I think there should be a reference to H65 in these steps (as in..there are at least 4 exceptions, like input fields for phone numbers as described in H65) |
|
+1 to adopting the changes in step 2. @goodwitch H65 has a contentious history, setting a precedent for no visible label necessary (see its description below). One of these days, maybe after August, we should open it up and edit it so as not to give the impression its OK to have no visible label. In a 3 part phone number the label is "phone number" for the group, and offscreen instructions via the title attribute simple accommodate what is visually conveyed by being them next to each other. (Part 1, 2 ,3)
|
|
-1 for the wording “visible” in step 2. New proposal:
The technique is about the descriptive wording of the label text and not the visibility. For example: 3.3.2 is also valid for a label / input / button combination for a search component. +1 to not including the proposed step 4, same reason as @goodwitch |
|
+1 to Andrew's step 2. Visible is needed here. Both 2.4.6 and 3.3.2 apply to visual labels and not programmatic labels. In Jake's example, the label for the search input is the visible search button. The button in that case labels the search visually and that is the label that this technique is asked to make sure is descriptive. |
|
In regards to H65 the discussion I believe that was approved was to remove the applicability to SC 3.3.2. That is H65 is valid for the other SC but not 3.3.2. |
|
@mraccess77 but the whole point of H65 (and the 4 examples it contains) is ways you can provide some visual clues, without having a visual label on each field. So...as much as I know H65 can be abused, I think it exists for things like phone numbers (broken into area code, prefix, suffix) SSN (broken into 3 parts), pulldown menus that limit a search (as shown as an example in H65).... |
|
@goodwitch in order to be a sufficient technique for SC 3.3.2 it would have to have some visible label check in the check section. The visible label could be a group label for a group of fields like phone. But my point is that we can't have it mapped to 3.3.2 without a check for a visual label because 3.3.2 requires visual labels of some sort (icon, image, text, etc.). I don't consider the title a visual label because it is only display on mouse over for most browsers. Edge and IE on Windows 10 have increased support for keyboard but you shouldn't have to focus a field to see a label. |
|
@mraccess77 could you please explain why visible is needed, I don’t see it that way still. 2.4.6 is also for CSS hidden headings which ‘repair’ the document outline for example and the same for 3.3.2 where another component is not responsible (the button) for NOT having a proper programmatic label (for the input which could be hidden). Also the description of G131 doesn’t give a clue for visibility.
|
|
Hi @goodwitch, Does the respond of @mraccess77 #307 (comment) answers your question / remark sufficiently? |
|
Hi @mraccess77 Did you see my question at #307 (comment) and could you please respond? To recap the issue I see we had a new proposal which is:
Step 4 isn’t applicable for this technique so we’re left with the last bump about the word “visible” in step 2.
As we’re linking to the definition for label, https://www.w3.org/TR/2008/REC-WCAG20-20081211/#labeldef, and the definition already has a note:
It seems redundant to mention this again, if the label is not visible it could be it’s name, https://www.w3.org/TR/2008/REC-WCAG20-20081211/#namedef, not label. Following the description text:
If the “visible label” does not use the “technology-specific techniques for technologies for associating labels with interactive controls” but can be made up from the visible UI (heuristic analysis, which is not waterproof) like the label element / input / button example it won’t be a 100% guaranty to always “allowing the user to identify the purpose of the control” So again I would like to propose to change "visible" for "present":
|
|
@jake-abma I'm reminding myself that this issue is focused on Technique G131...so I'm going to stay focused on just the changes needed there...and note that I remain in agreement with: +1 to adopting the changes in step 2. (and any conversation about H65 can be dealt with at another time). Onwards! |
|
If G131 does not require visible labels and this is a sufficient technique for SC 3.3.2 -- but SC 3.3.2 requires visible and descriptive labels then we would be saying you can pass SC 3.3.2 without visible labels. This technique is also mapped to 2.4.6 which refers to labels as well - labels that must be visible by definition -- but as you point out heading are not required to be visible per the definition -- but I believe the assumption was that they would be visible. Also having descriptive headings that are not visible to users with cognitive disabilities and users with low vision is not helpful to those groups. Sufficient techniques are sufficient -- but not the only way that an SC can be met -- so adding visible doesn't mandate anything. |
|
I think adding "visible" to step 2 of the Test Procedure guidance for Technique G131 would help to clarify the test execution steps. If the label always needs to be visible on the page it would help to just say so in the test step. The definition for a label says that it must be "presented to all users" but it's debatable what "presented" means. In this thread there has been a healthy discussion as to whether or not a "label" that temporarily appears in certain situations (say on focus/hover) is acceptable. Therefore, I think it would be helpful to designers and developers (especially those who are just learning about accessibility) to have clearer guidance in the G131 test procedure steps. To address some of the points brought up in this thread, I propose the following revision to the proposed update to Step 2: It might also be helpful to add a note about the point @mraccess77 brought up earlier in this thread that a user shouldn't have to focus or hover on a field to find out the label for the field. I would also add that I think users should be able to review the values they input/selected compared to the label before submitting their form; so, use of placeholder text that doesn't persist in someway in the visible interface would also not be an acceptable label. Perhaps a NOTE could be added in the technique or test procedure step to explain these examples. For instance: |
|
@jgauvreau great addition to thread, I agree with the help of adding the word "visible". @mraccess77 anything to add? New suggested wording:
|
|
Permanently visible is fine with me -- linking to the definition is good and might be sufficient. From my perspective a label must always be present -- but it can morph. For example, a field might have a visible label using a placeholder but as soon as you type into it a label appears above the field and is visually present. |
|
+1 to what Jonathan said.
I agree with adding the word visible. And I agree that how it is visible
may morph (as Jonathan described).
G
glenda sims | team a11y lead | deque.com | 512.963.3773
*web for everyone. web on everything.* - w3 goals
[image: IAAP International Association of Accessibility Professionals:
Certified Professional in Accessibility Core Competencies (CPACC)]
<http://www.accessibilityassociation.org/certification>
…On Thu, Oct 19, 2017 at 9:28 AM, Jonathan Avila ***@***.***> wrote:
Permanently visible is fine with me -- linking to the definition is good
and might be sufficient. From my perspective a label must always be present
-- but it can morph. For example, a field might have a visible label using
a placeholder but as soon as you type into it a label appears above the
field and is visually present.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#307 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0uWvhDp-ynjFEOl9FAfK9XZOb-BHXLks5st1yLgaJpZM4Ocrlg>
.
|
|
@jake-abma is the text above the new proposal? If so, please respond with NEW PROPOSAL: and the text, and I'll survey it with the group, thanks. |
|
NEW PROPOSAL:
|
|
Great - thanks @jake-abma Surveyed https://www.w3.org/2002/09/wbs/35422/Oct_31_2017/ |
|
If we are dropping the required part of the test procedure don't we also need to do something about example 3 as this now makes no sense here. |
|
Here's the original G131 procedure:
Here's the proposed version:
|
|
I made the comment in the survey as well, but the only change is to the second item. The changes are:
FIrst, we don't need "for the component" as the check is already being done "for each interface component". As James indicates, Example 3 is related to this change. |
|
(Sorry, I updated this comment after I unconfused myself a bit, if you read the email version please re-check before replying.) I'm confused, 3.3.2 doesn't require a visible label:
Having a programatic label is under 1.3.1 with H44, and if there is a visible label it should be understandable under 2.4.6 Headings & Labels. However, that doesn't mean a visible label is required. My understanding of the step "Check that any required label is present." is that it is for scoping: I can see the issue with 'required' in step two, it is confusing this technique with the concept of a required input. Therefore I suggest:
|
|
The definition of a label indicates it is available to all users. It doesn't have to be text -- it can be an image. label Note 2: The term label is not limited to the label element in HTML. |
|
Hi @mraccess77 Sorry, I don't understand why you're highlighting the label definition? (I did update my comment quite a bit since the email-alert went out, has that confused things?) It doesn't imply that a label is required or visible in this context, does it? The test procedure is compatible with that definition. |
|
The problem is that this is mapped to SC 3.3.2. If the intent of the technique is to only check that it is descriptive then it should only be mapped to SC 2.4.6. and we could remove the visible part. But this is listed as a technique for meeting SC 3.3.2. So we are saying if you follow these test below you will pass SC 3.3.2. If it is mapped to SC 3.3.2 then the check needs that language. |
|
It is sufficient only with another technique, there are 10 listed and you need to use one of those as well as G131, including "H90: Indicating required form controls using label or legend." |
|
H90 may cover required status indicated in the label -- but doesn't address a visible label being present there or in a field that isn't required. Why does SC 3.3.2 need to be mapped to G131 at all? Descriptive labels go beyond what is required by SC 3.3.2. |
Maybe that's the issue then. If it should require labels which state 'this input is required' in some form then the commenter has a point. If not, then we should drop the mapping from 3.2.2. I missed the earlier part of the WCAG call (time zone snaffu), but it looks like this one was deferred. Not sure to when... |
|
Thank you to the WG for including this item in your last survey and discussing in your meeting on October 31, 2017. I was the one who originally emailed this question in for guidance from the WG (thanks to Andrew for posting it on GitHub back in July) so I wanted to provide some context on my original request. My goal was to get clarification on the test procedure steps for G131. My colleagues and I were not clear on the intent and were concerned about our project teams being able to consistently interpret and execute the test. For ease of reference, I'm repasting the original question below: Based on the earlier discussions in this thread it seems like the general consensus was that the phrase "required label" was just intended to mean Option B above. Does the WG agree the intended meaning of the phrase "required label" is "the user interface control/component requires a visible label separate from the control itself"? If so, I propose adding a clarifying NOTE to the test procedure explaining the meaning of this phrase. For instance: |
|
Staying close to the original question and the consensus it’s about:
I suggest to change the wording to: NEW PROPOSAL:Procedure For each interface component in the content:
Expected Results Checks When the definition for label is not clear my suggestion would be to change it at the definition of the label and not mention this at the technique part via an elaborated NOTE. Therefore the suggested NOTE, although it may contain value, could be another Github issue. One question remains from this thread about 3.3.2 is: Why is techniques H65 a sufficient techniques as this is not presented to all users as the normative text requires?
Touch screen or keyboard users may never see it. |
|
+1 to Jake's sentiment about H65...
However... part of the current problem there is that the Accessible Name
Calculation defined by the W3C's Accessible Name and Description:
Computation and API Mappings 1.1 Recommendation (
http://w3c.github.io/aria/accname-aam/accname-aam.html#mapping_additional_nd_name)
includes @title as part of the recursive algorithym used to calculate
the Accessible
Name
<http://w3c.github.io/aria/accname-aam/accname-aam.html#dfn-accessible-name>
.
Honestly, I'd vote in a heartbeat to remove that Technique from the list of
Success Techniques, for the reasons Jake notes, but it would take a change
in the ARIA spec (and browser implementations) to effectively scrub that
from the web (and it would have a significant impact on legacy content,
which is a serious concern).
JF
…On Fri, Nov 3, 2017 at 4:30 AM, Jake Abma ***@***.***> wrote:
Staying close to the original question and the consensus it’s about:
B) the type of user interface control/component requires a visible label
separate from the control itself
I suggest to change the wording to:
NEW PROPOSAL:
*Procedure*
For each interface component in the content:
- Identify its purpose.
- Check that it has an associated label.
- Check that the label makes the component's purpose clear.
*Expected Results*
Checks #2 and #3 are true.
------------------------------
When the definition for label is not clear my suggestion would be to
change it at the definition of the label and not mention this at the
technique part via an elaborated NOTE. Therefore the suggested NOTE,
although it may contain value, could be another Github issue.
One question remains from this thread about 3.3.2 is:
Why is techniques H65 a sufficient techniques as this is not presented to
all users as the normative text requires?
1. H65: Using the title attribute to identify form controls when the
label element cannot be used (HTML)
Touch screen or keyboard users may never see it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#307 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-cxWppS3HfCZBDv1JjLtZE9tCMbosks5syt0pgaJpZM4Ocrlg>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
We just need to be clear with the term "associated label." that we aren't saying this only applies to the label element or aria-labelledby -- but instead an implied association is a label in close proximity that is intended to provide a label for the control. |
|
@johnfoliot clear and agreed on, we won't do anything with it for 2.0 @mraccess77 if we link the text "label" to the definition for "label" we make clear what we mean by label |
NEW PROPOSAL:Procedure For each interface component in the content:
Expected Results Checks |
Summary of Issue: Use of the term "required" is ambiguous in Step 2 of G131 Test Procedure
Comment (Including rationale for any proposed change):
In reviewing the Sufficient Techniques for WCAG 2.0 SC 3.3.2, it's unclear to me what is intended by the use of the word "required" in step 2 of the Test Procedure for Technique G131: Providing descriptive labels.
G131 Test Procedure Step 2 currently reads: "Check that any required label is present."
In this context, was "required label" intended to mean:
A) a visible text (or text symbol or icon with text equivalent) indicator that user input in the field is mandatory/required OR
B) the type of user interface control/component requires a visible label separate from the control itself OR
C) both A and B?
Rationale for Option A: Not all UI components require a separate label. A toggle would not need/require a separate label (e.g., element, title attribute or aria labeling technique) since the authored contents between the starting element and closing element can serve as the visible label for the component. In contrast, 2 input text fields would require a visible label to convey to the user what input they should to include in one text field versus the other text field.
Rationale for Option B: The introduction to the G131 technique has a sentence that indicates a required field indicator MAY be included in the label but nothing explicitly states that the label for UI components MUST distinguish whether input in a field is required or optional.
Proposed Change:
Change G131's Test Procedure to clarify the intent of Step 2 and possibly add a fourth Step related to including a cue in the visible label to distinguish the fields for which user input is mandatory vs. optional.
One possible revision follows below:
Procedure
For each interface component in the content:
The text was updated successfully, but these errors were encountered: