Repository navigation
Proposal to Rephrase Success Criterion 4.1.1 #2525
Description
Activity
@cstrobbe I am very grateful for your close analysis and explanation. That said, AGWG has had great difficulty advancing two considerably more trivial (and essentially editorial) changes to normative phrasing in 2.0.
My own preference would be to incorporate all of this into Understanding and other related supporting materials, as you are doing, for example with #2187.
- I think this all goes back to the intent and understand of the people who first created the SC. That would determine if it was errata or a change in their understanding of what the SC was intended to mean. Unfortunately — a) we don’t have the ability to talk to all those on the working group and. b) all public reviewers - both those that commented and those that were satisfied or relied on the wording and therefore did not comment are involved in the process as well. Thus we cannot judge intent or understanding of these — so cannot judge if it is errata. We would need treat is as a change and a loosening of the SC. This things that complied with 2.2 would fail earlier versions - which is something the group so far has been reluctant to do. (Errata change previous versions so the problem does not arise for errata.) Even changing the understanding document to say something other than what the SC says would be a problem. The Understanding doc is just to explain the SC - not to say that something should be different. So the only way this can advance would be for the WG to decide to change current policy. We should gather these types of things up in one place and decide if we want to / should do that or not. g
@GreggVan
My rewording is based on what I remember from the discussions in the WG at the time, the statement in Success Criterion 4.1.1: Parsing that XML's well-formedness is close to what the SC requires (in other words, requiring correct content models goes beyond well-formedness and beyond the SC) and what I could reconstruct from publicly available older discussions (see my comment on What does nested according to the specification mean in SC 4.1.1). The rationale for my proposal is that it represents what was always intended.I understand that we can't contact everyone who was involved in those discussions, but a clarification on what "nested according to their specifications" means has been requested for years. If WCAG 2.2 adopted the proposed wording, non-compliance with older versions would be caused by auditors going beyond the intent of the current SC 4.1.1. If this is better handled by means of errata, then I'm perfectly happy with that.
@zcorpan was also of the opinion like @cstrobbe , but then changed his mind
I think the test for an errata would be whether this would clarify the SC without changing the intended meaning:
"In content implemented using markup languages, elements have complete start and end tags, elements are nested according to the syntactical rules of their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features."
The understanding document includes phrases like:
the content is created according to the rules defined in the formal grammar for that technology. In markup languages, errors in element and attribute syntax and failure to provide properly nested start/end tags lead to errors that prevent user agents from parsing the content reliably. Therefore, the Success Criterion requires that the content can be parsed using only the rules of the formal grammar.
The concept of "well formed" is close to what is required here.
I'm not entirely sure what @cstrobbe meant by "content models", but the above seems like a reasonable suggestion for an errata.
Reacted by JAWS-test, Christophe Strobbe, Bruce Bailey and Mike Gifford- hmmmm I agree with... the test for an errata would be whether this would clarify the SC without changing the intended meaning:The concern here is that the edit narrows and rigidifies beyond the original SC. For example If the spec says "there is no requirement to nest them strictly, but if you do then use this syntax" Your edit would have the effect of deleting the first half of the sentence - and only use PART of the spec that is syntax, and ignoring the part of the spec that says there is no requirement to. So I think the edit can change it. What do you think gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org…On Jul 18, 2022, at 3:11 AM, Alastair Campbell ***@***.***> wrote: I think the test for an errata would be whether this would clarify the SC without changing the intended meaning: "In content implemented using markup languages, elements have complete start and end tags, elements are nested according to the syntactical rules of their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features." The understanding document includes phrases like: the content is created according to the rules defined in the formal grammar for that technology. In markup languages, errors in element and attribute syntax and failure to provide properly nested start/end tags lead to errors that prevent user agents from parsing the content reliably. Therefore, the Success Criterion requires that the content can be parsed using only the rules of the formal grammar. The concept of "well formed" is close to what is required here. I'm not entirely sure what @cstrobbe <https://github.com/cstrobbe> meant by "content models", but the above seems like a reasonable suggestion for an errata. — Reply to this email directly, view it on GitHub <#2525 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUEGL2KLJRLGV4K2VLVUUUT3ANCNFSM5ZRXNZ6A>. You are receiving this because you were mentioned.
Gregg Vanderheiden wrote,
If the spec says "there is no requirement to nest them strictly, but if you do then use this syntax"
Your edit would have the effect of deleting the first half of the sentence - and only use PART of the spec that is syntax, and ignoring the part of the spec that says there is no requirement to.I think the wording of my suggestion avoided that issue:
except where the specifications (...) allow exceptions to these requirements
- It does indeed - but I think it still leaves the ambiguity since people will have trouble determining what that means. Kind of like a double negative — but not exactly. Hmmm how to fix How about a slight tweak to your language My question is - DOES HTML5 strictly require "nested according to it's syntactical rules " I don’t know the answer. BY THE WAY - the INTENT was 1 3 and 4 but NOT requiring strict nesting because HTML then did not require it. So you could have H1 H3 H1 H2 nesting and be ok There was a LOT of discussion and people who argued no H3 without H2, but in the end — what was agreed on did not require this. Best Gregg
BY THE WAY - the INTENT was 1 3 and 4 but NOT requiring strict nesting because HTML then did not require it. So you could have H1 H3 H1 H2 nesting and be ok
There was a LOT of discussion and people who argued no H3 without H2, but in the end — what was agreed on did not require this.but that's not nesting, that's heading levels ... or am i missing something here?
Reacted by JAWS-test, Scott O'Hara, Christophe Strobbe and Ian KerseyReacted by Steve FaulknerNote: Syntactically correct nesting is distinct from nesting according to the content models specified in a technical specification. The second condition of the success criterion does not require correct content models; only correct syntax.
So the following incorrect content model nesting is OK as far as the Criterion is concerned?
<button><a href="#"></a></button>or
<ul> <div> <li> <li> </div> </ul>@GreggVan - My understanding that 4.1.1 is requiring correct nesting of tags, nothing to do with the order of headings (which are under 1.3.1).
Like Steve's button / list example above (which fails in the validator as "Element div not allowed as child of element ul in this context").
The proposed errata (adding "syntactical") could help to disambiguate the perception of it being more than what was intended.
I'm fairly sure the spec on headings doesn't require any particular ordering of heading tags.
However, it would catch things like
<button><h2>Thing</h2></button>.Reacted by Scott O'HaraRegarding the examples in Steve Faulkner's comment: these don't contain syntactic problems, so they meet the SC. (Obviously, their content models are wrong, which is why the validator will report errors for those two examples.)
As Alastair Campbell has pointed out, the hierarchy of headings is irrelevant to this SC. That is not a syntactical issue.
The validator catches
<button><h2>Thing</h2></button>because the content model is wrong. However, from a purely syntactical point of view, the nesting is fine (so it wouldn't violate SC 4.1.1). Browsers can build up an unambiguous parse tree based on that code. However, there may be an issue with the role exposed to the accessibility API. If that is the case, the code snippet violates a different SC, namely SC 4.1.2.Reacted by Patrick H. LaukeHowever, it would catch things like
<button><h2>Thing</h2></button>but that's still going beyond syntax (well-formedness) ... so which is it?
- Ah I see what you mean. OK Would be good to have examples in Understanding doc so people can distinguish between syntactic and content model gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org…On Jul 19, 2022, at 7:56 AM, cstrobbe ***@***.***> wrote: Regarding the examples in Steve Faulkner's comment <#2525 (comment)>: these don't contain syntactic problems, so they meet the SC. (Obviously, their content models are wrong, which is why the validator will report errors for those two examples.) As Alastair Campbell has pointed out, the hierarchy of headings is irrelevant to this SC. That is not a syntactical issue. The validator catches <button><h2>Thing</h2></button> because the content model is wrong. However, from a purely syntactical point of view, the nesting is fine. Browsers can build up an unambiguous parse tree based on that code. However, there may be an issue with the role exposed to the accessibility API. If that is the case, the code snippet violates a different SC, namely SC 4.1.2. — Reply to this email directly, view it on GitHub <#2525 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXXM4VPRREJZX2VSLATVU263BANCNFSM5ZRXNZ6A>. You are receiving this because you were mentioned.
The validator catches
<button><h2>Thing</h2></button>because the content model is wrong. However, from a purely syntactical point of view, the nesting is fine (so it wouldn't violate SC 4.1.1).I guess there is a difference between syntactical and content model that I'm missing.
I thought that those types of errors were exactly what 4.1.1 were supposed to catch, i.e. nested according to the spec.
132 remaining items
Noting that this has been removed this from WCAG 2.2, but leaving open for potential updates to 2.1/2.0
Proposing to close this issue, as 2.0 https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html already mentions "syntax", and note 2 in 2.1 https://www.w3.org/TR/WCAG21/#parsing further clarifies this.
Reacted by Steve Faulkner, Christophe Strobbe, Francis Storr, Baldino Morelli, Eric Eggert and Mike GowerDiscussed at the facilitator meeting today with @alastc @kfranqueiro @bruce-usab - agreed to close this as obsolete.
Since many accessibility testers and other accessibility experts erroneously interpret the phrase "elements are nested according to their specifications" as referring to content models instead of syntactical nesting, a rewording that avoids this misunderstanding is highly desirable. Below is a proposed rewording.
Description of the changes:
Compatibility with existing versions of WCAG 2 and EN 301 549: Since the proposed rewording results in a requirement that is less strict than the interpretation of most accessibility testers, all documents that pass the current version of SC 4.1.1 should also pass its proposed rewording. In this sense, the proposed rewording is compatible with the current version.
Clause 9.4.1.1 of EN 301 549 says, "Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 4.1.1 Parsing". Unless the editors of EN 301 549 want to retain the current version of the success criterion, no rewording of clause 9.4.1.1 is needed beyond, at some future point in time, an update of the referenced version of WCAG.
Not addressed by this proposal: The proposal does not address whether unbalanced attribute quoting counts as a failure of SC 4.1.1. (See the discussion on the failure examples in F70.) The first note mentions "a mismatched attribute value quotation mark" as an example an incomplete start tag, but notes are non-normative and the SC does not say anything about attribute syntax. Adding a fifth condition, such as "attribute syntax is used according to specification", might therefore be interpreted as making the SC stricter than in WCAG 2.1.
The intent of this rephrasing is not to “defend” the many types of validation errors that accessibility testers flag using this success criterion. My intent is merely to eliminate a common misunderstanding about what the success criterion actually means. (See my comment on issue w3c/wcag#978 for notes about how XML's concept of well-formedness informed the wording of the success criterion.) If non-syntactical validation errors which impact accessibility are found, these should be caught either by existing success criteria or by new ones that still need to be created.
Clarification in response to Alastair Campbell's comment on content models (18.07.2022).
"Content models" refers to the descriptions of what each element may contain. For example, in HTML 5 a
divmay not be nested inside aspan. In SGML and in the early days of XML, content models were described in DTDs. For example,<!ELEMENT chapter (chaptertitle, (para | heading)+)>This line declares the element
chapterand says it must contain achaptertitlefollowed by at least oneparaorheading. In HTML 5, content models are not expressed in DTDs, XML Schemas or similar formal languages, but described in text. See, e.g. "content model" under Thesectionelement, which says that this element may only contain flow content.