4.1.1 adding note. #3116
4.1.1 adding note. #3116
Conversation
| <p>The following content is left for historical purposes to show the original intent.</p> | ||
|
|
||
| <hr /> | ||
| <p class="note">This SC should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different success criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.</p> |
There was a problem hiding this comment.
| <p class="note">This SC should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different success criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.</p> | |
| <p class="note">This Success Criterion should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different Success Criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.</p> |
Co-authored-by: Mike Gower <mikegower@gmail.com>
| @@ -9,6 +9,8 @@ <h4>Parsing</h4> | |||
| duplicate attributes, and any IDs are unique, except where the specifications allow | |||
| these features. | |||
| </p> | |||
|
|
|||
| <p class="note">This Success Criterion should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different Success Criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.</p> | |||
There was a problem hiding this comment.
In the interest of using the note to minimize drive-by non-conformance claims, I think it would be helpful to reword this somewhat to make it very clear that we are intepreting the existing normative text (specifically, the "except where the specifications allow these features" part) as being automatically met for HTML documents, and not using an informative note to ignore or override the normative text. Particularly, I think the sentence "This criterion can therefore be ignored as being redundant" is problematic; the normative text of the conformance model doesn't allow authors to ignore criteria just because they are redundant.
I think an update along these lines would stay more firmly within the boundaries of the conformance model, but achieve the same intent:
| <p class="note">This Success Criterion should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different Success Criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.</p> | |
| <p class="note">This Success Criterion should be considered as automatically met for any content using HTML. Since this criterion was written, the HTML Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs. Although the HTML Standard treats some of these cases as non-conforming for authors, it is considered to "allow these features" for the purposes of this Success Criterion because the specification requires that user agents support handling these cases consistently. In practice, this criterion no longer provides any benefit to people with disabilities in itself; issues such as missing roles due to inappropriately nested elements or incorrect states or names due to a duplicate ID are covered by different Success Criteria.</p> |
There was a problem hiding this comment.
A small tweak on Dan's modification I'd suggest...
are covered by different Success Criteria.
becomes...
are covered by different Success Criteria and should be reported there rather than as issues with 4.1.1.
There was a problem hiding this comment.
The F70 and F77 failures referenced here also need updated since folks may get to them via Google without seeing the understanding document. Would also be good being explicit in the failures section of the understanding document that they are now non-failures.
There was a problem hiding this comment.
Sorry - comment on wrong file - this refers to understanding/20/parsing.html
|
This was replaced with #3152, closing. |
If this is merged, also merge in #3117 so that the update to the understanding is also made in main.