Problem with Technique G131 #342
Comments
|
From @awkawk on July 19, 2017 12:50 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. |
|
From @goodwitch on July 19, 2017 16:0 +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) |
|
From @DavidMacDonald on August 7, 2017 19:59 +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)
|
|
From @jake-abma on August 8, 2017 5:57 -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 |
|
From @mraccess77 on August 8, 2017 13:32 +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. |
|
From @mraccess77 on August 8, 2017 14:19 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. |
|
From @goodwitch on August 8, 2017 14:48 @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).... |
|
From @mraccess77 on August 8, 2017 14:52 @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. |
|
From @jake-abma on August 8, 2017 14:55 @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.
|
|
From @jake-abma on October 7, 2017 9:25 Hi @goodwitch, Does the respond of @mraccess77 w3c/wcag21#307 (comment) answers your question / remark sufficiently? |
|
From @jake-abma on October 7, 2017 9:57 Hi @mraccess77 Did you see my question at w3c/wcag21#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":
|
|
From @goodwitch on October 7, 2017 20:59 @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! |
|
From @mraccess77 on October 19, 2017 2:33 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. |
|
From @jgauvreau on October 19, 2017 4:11 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: |
|
From @jake-abma on October 19, 2017 5:16 @jgauvreau great addition to thread, I agree with the help of adding the word "visible". @mraccess77 anything to add? New suggested wording:
|
|
From @mraccess77 on October 19, 2017 14:28 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. |
|
From @goodwitch on October 19, 2017 14:34 +1 to what Jonathan said. I agree with adding the word visible. And I agree that how it is visible G glenda sims | team a11y lead | deque.com | 512.963.3773 [image: IAAP International Association of Accessibility Professionals: On Thu, Oct 19, 2017 at 9:28 AM, Jonathan Avila notifications@github.com
|
|
From @joshueoconnor on October 24, 2017 15:28 @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. |
|
From @jake-abma on October 24, 2017 18:18 NEW PROPOSAL:
|
|
From @joshueoconnor on October 25, 2017 9:26 Great - thanks @jake-abma Surveyed https://www.w3.org/2002/09/wbs/35422/Oct_31_2017/ |
|
From @jnurthen on October 26, 2017 21:26 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. |
|
From @awkawk on October 26, 2017 21:42 Here's the original G131 procedure:
Here's the proposed version:
|
|
From @awkawk on October 26, 2017 21:54 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. |
|
From @alastc on October 31, 2017 14:52 (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:
|
|
From @mraccess77 on October 31, 2017 15:24 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. |
|
From @alastc on October 31, 2017 15:36 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. |
|
From @mraccess77 on October 31, 2017 15:40 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. |
|
From @mraccess77 on October 31, 2017 15:49 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. |
|
From @alastc on October 31, 2017 17:21
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... |
|
From @jgauvreau on November 2, 2017 14:46 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: |
|
From @jake-abma on November 3, 2017 9:30 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. |
|
From @johnfoliot on November 3, 2017 13:52 +1 to Jake's sentiment about H65... However... part of the current problem there is that the Accessible Name Honestly, I'd vote in a heartbeat to remove that Technique from the list of JF On Fri, Nov 3, 2017 at 4:30 AM, Jake Abma notifications@github.com wrote:
-- Advancing the mission of digital accessibility and inclusion |
|
From @mraccess77 on November 4, 2017 19:9 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. |
|
From @jake-abma on November 10, 2017 6:52 @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 |
From @awkawk on July 19, 2017 12:49
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:
Copied from original issue: w3c/wcag21#307
The text was updated successfully, but these errors were encountered: