-
Notifications
You must be signed in to change notification settings - Fork 257
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
Fixes to WCAG 2.1 Understanding 2.4.6 and 3.3.2 #612
Fixes to WCAG 2.1 Understanding 2.4.6 and 3.3.2 #612
Conversation
Explicitly mention that 2.4.6 is NOT concerned with correct markup/identification of headings/labels.
The "People who have difficulty using their hands" benefit here is not explained, and appears to be more of a benefit assuming that headings are correctly marked up per 1.3.1, and that the users are either navigating an automated TOC that links to headings, or are using additional AT that allows for heading-based navigation. All of this is not related to whether or not headings are actually descriptive. The "This Success Criterion helps people who use screen readers" benefit again hinges more on 1.3.1 first and foremost. As it's not a requirement of THIS particular SC that headings be correctly marked up, it's not really a benefit per se of this SC directly. May reintroduce this in reworded form. The "This Success Criterion may also help users with low vision who can see only a few words at a time" benefit seems to be a complete non-sequitur, as descriptive headings/labels may vary in length and won't necessarily benefit this user group in the way described.
…that it hinges on 1.3.1 additional small correction, for consistency, capitalizing "Success Criterion"
Explicitly mention that 3.3.2 is NOT concerned with correct markup/identification/association of labels/instructions.
The "When label elements are associated with input elements the label is spoken by screen readers..." benefit hinges purely on 1.3.1, not 3.3.2 The "Field labels located in close proximity to the associated field assist users of screen magnifiers..." hinges on the concept of 'proximity', which has nothing to do with this SC, and is not normatively defined anywhere in WCAG?
Made the two remaining benefits more generalized, while providing clearer context.
…efits additionally, split an overly long line in markup to two lines
As auditors (at least in my experience) are often confused by the different, yet complementary, aspects of what is asserted by 2.4.6 and 3.3.2
As auditors (at least in my experience) are often confused by the different, yet complementary, aspects of what is asserted by 2.4.6 and 3.3.2
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.
Structurally this is fine, edits are in the correct place. We might want to decide if it makes sense to continue maintaining Understanding files in a version folder, but it made sense at the time and is what is currently supported.
I question having several paragraphs in a note, as I think notes should be brief and if content is longer it's no longer a note, it should be worked into the main text. I also question whether what appears to be nearly identical content should be in multiple Understanding files, as it's repetitive and reduces the distinction between the relevant SC. But I'll leave those issues for the WG process, this review is just on structural aspects.
@patrickhlauke The WG approves the direction, although @mbgower will have some input on the pull request. :) |
Closes #610
(note I wasn't sure whether to make the fixes on these files, which are in the 2.0 folder, or whether or not I should have created new instances of these in the 2.1 folder)