Skip to content

Comments

Delete the H44.NotFormControl case#100

Closed
laurentgoncalves wants to merge 1 commit intosquizlabs:masterfrom
laurentgoncalves:master
Closed

Delete the H44.NotFormControl case#100
laurentgoncalves wants to merge 1 commit intosquizlabs:masterfrom
laurentgoncalves:master

Conversation

@laurentgoncalves
Copy link

The H44 test procedure (http://www.w3.org/TR/WCAG20-TECHS/H44) tells to verify each input, select and textarea elements, to check :

  • if there is a label before the element
  • if the for attribute of THIS label identify the element,
  • this label must be visible

There is no rule checking that all labels must have a for attribute identifying an input element.
That's why the sniffer should not check the H44.NotFormControl

The H44 test procedure (http://www.w3.org/TR/WCAG20-TECHS/H44) tells to verify each input, select and textarea elements, to check :
- if there is a label before the element
- if the for attribute of THIS label identify the element,
- this label must be visible

There is no rule checking that all labels must have a for attribute identifying an input element.
That's why the sniffer should not check the H44.NotFormControl
@cchene
Copy link

cchene commented Jan 27, 2015

This tool is a wonderful idea but I cannot use it to check my web pages (under development): these errors are false negatives reported by the analysis.

Looks like the patch is given and quite simple to audit and pull into the repo.
@lwright-sq Any comment/reaction?

@luketw
Copy link
Member

luketw commented Jan 28, 2015

I'm not convinced about the need to remove it, although perhaps it should be dropped to a warning.

The H44.NoFormControl message is supposed to say "you've specified a 'for' ID but it doesn't relate to a form control". To not point it to a form control means the for attribute has no effect:

If the attribute is specified, the attribute's value must be the ID of a labelable element in the same Document as the label element. If the attribute is specified and there is an element in the Document whose ID is equal to the value of the for attribute, and the first such element is a labelable element, then that element is the label element's labeled control. (WHATWG HTML standard)

That means I've taken the assumption that if it is specified and doesn't relate to a form control, then it is being misused or it is potentially a typo. It is probably not something that should fail the whole thing (especially when there are other acceptable methods of associating labels now) but it is something that should certainly be flagged for manual intervention. Hence, should be a warning.

I think there -is- a false positive in the case where the for attribute is empty, however, and that should be removed.

luketw pushed a commit that referenced this pull request Jan 28, 2015
The test that flags "for" attributes on labels that don't point to a form control is now a warning, not an error. It is not a fail in itself (especially now explicit labels are not necessary), but often suggests a misused or typoed for attribute and thus should be manually checked.

Also no error will appear if the "for" attribute is empty (for="").
@cchene
Copy link

cchene commented Jan 28, 2015

Thanks for the update, I see your point.
It turns out that having a label+for that points to a non form-control element may not be a WCAG error, but simply an HTML syntax error.
My mistake!

I guess that lowering this error's severity to warning is a good option.

@luketw
Copy link
Member

luketw commented Feb 3, 2015

Well it's not so much a HTML syntax error, but more that you likely intended for it to point to something, but if it's not pointing to a form control (through typo or other reason), then it's not going to have an effect - therefore it probably should be checked to see if it should be pointing to something else, or removed entirely.

I've made a commit and the reduction to a warning (and removal of errors for blank attributes, ie. for="") is available in Auditor version 2.0.4 (2015-02-02). I'm going to close the pull request in favour of that commit.

Thanks very much for the report!

@luketw luketw closed this Feb 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants