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

Include H90 as a technique for 1.3.1 Info and Relationships #240

Closed
mbgower opened this issue Oct 4, 2016 · 9 comments
Closed

Include H90 as a technique for 1.3.1 Info and Relationships #240

mbgower opened this issue Oct 4, 2016 · 9 comments

Comments

@mbgower
Copy link
Contributor

mbgower commented Oct 4, 2016

H90: Indicating required form controls using label or legend is properly associated with Success Criterion 3.3.2 (Labels or Instructions); however it should also be included in Situation A of 1.3.1 Info and Relationships, item number 10 "Making information and relationships conveyed through presentation programmatically determinable using the following techniques:" All examples in H90 involve putting the indicator of a required field inside these HTML elements, label and legend, to ensure there is a programmatic equivalent to the visual positioning of the indicator, and so are clearly associated with 1.3.1

@joshueoconnor
Copy link
Contributor

I wonder if this is the case because H90 is already covered by 3.3.2 - there is no burning need for it to be covered by 1.3.1 - which is already overloaded as it is IMO.

@mraccess77
Copy link

Keep as is.

@DavidMacDonald
Copy link
Contributor

keep as is...

@awkawk
Copy link
Member

awkawk commented Nov 14, 2016

When we last discussed this (not resolved at that time: http://www.w3.org/WAI/GL/track/issues/15) the point was made that H44 (http://www.w3.org/TR/WCAG20-TECHS/H44.html) suggests using label and you meet 3.3.2 and 1.3.1 at the same time.

Do we feel that programmatic indication of required state is not required by 1.3.1 or that this technique doesn't meet the requirement?

@mraccess77
Copy link

If the required state is indicated visually then it is covered under SC 1.3.1. But if the required state is not indicated visually then it doesn't seem to fall under a requirement of the current SCs.

@mbgower
Copy link
Contributor Author

mbgower commented Nov 14, 2016

I have encountered numerous situations where applications use an asterisk or other symbol to indicate a required field, but the symbol has been located outside the label tag, thereby rendering it not programmatically determinable. The point of including H90 in 1.3.1 is that it specifies the need to ensure any indicator is properly inside the label, thus associating it with the input.
Given some of the other issues, I would rate this as a relatively low priority. But an asterisk outside the label field is a frequent occurrence and rightly fails 1.3.1, not 3.3.2.

@awkawk
Copy link
Member

awkawk commented Nov 14, 2016

@mraccess77 The test procedure for H90 indicates that the required status must be indicated in the label or legend. To meet 3.3.2 this would need to be visually provided, so it seems that if you meet 3.3.2 using this technique that you also meet 1.3.1. Maybe to make a 1.3.1 claim we would need the procedure to be more definitive in the way that H44 is?

@mraccess77
Copy link

I agree if there is a visual representation of required then it would need to be associated some how and this is one way of doing that to meet SC 1.3.1.

@fstrr
Copy link
Contributor

fstrr commented Apr 29, 2022

Closing this as inactive. It also seems to be covered by Label In Name and there's a related issue (#2277) on this. If this is still relevant, please re-open or add into the related issue's discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants