F70 goes beyond WCAG 4.1.1

[JAWS-test]

F70 contains requirements that go beyond SC 4.1.1. Since it is an failure technique, it should be correct and not contain requirements beyond WCAG, right?

• Example 3: Unbalanced attribute quoting
• Example 4: Lack of whitespace between attributes
• Example 5: Unquoted attribute with whitespace value
• Check whether ... attributes are malformed.

[mraccess77]

I believe some of those are called out in the note on 4.1.1 "Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete."

[JAWS-test]

Ok, I see. The question is whether the note matches the SC text: "elements have complete start and end tags" - there is no mention here of attributes having correct quotation marks.

Let's look at example 5: <input title=Enter name here type=text>
The syntax is correct according to WCAG 4.1.1: we have an input field with 4 attributes, 2 of them are unknown and not allowed in HTML ("name", "here"), but also not forbidden according to SC 4.1.1, right?

[JAWS-test]

F70 seems to me to contain XML rules that no longer apply to HTML:

• Attribute values must always be enclosed in quotes.
• Each attribute must have a value

If I have an XML document, I can check compliance with these rules from F70. The only question is whether the SC text of 4.1.1 really requires this (though the note suggests it, I read the SC text differently)

[cstrobbe]

Please note that the applicability section says, "Markup languages: HTML, XHTML, and other SGML or XML-based technologies." HTML5 is based neither on SGML (but is at best inspired by it), nor on XML.

The HTML 5 specification does not separate correct syntax from correct content models ("validity") in the way that XML-based languages do. The W3C / Nu HTML validator treats the issues in example 5 as validation errors, not as syntax errors.

Example 3, by contrast, represents a syntax error even in HTML 5. HTML 5.2's section on attribute syntax contains the following requirement for double-quoted attributes:

If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.

In example 3, we find the following double-quoted attribute, which is not followed by whitespace: title="name type=". The code text" does not obviously not constitute an attribute at all.

There is a similar requirement for single-quoted attributes:

If an attribute using the single-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.

I can't find anything in that section that allows unbalanced quotes; either you use quotes to enclose the entire attribute value or you don't quote the value at all (see "Unquoted attribute value syntax" in the same section).

One may wish to reword the description of example 3 as follows:

The following code fails because the syntax is ambiguous. From an authoring point of view, the attribute value is missing the closing quote, which makes the boundary of the attribute-value pair unclear. From a parsing point of view, the first attribute value ends at the second quote, so there is no whitespace between the two attributes.

Example 4 also represents a syntax error even in HTML 5 for the same reason quoted above. HTML 5.2 defines exactly four ways for specifying attributes (empty attribute syntax, unquoted attribute value syntax, single-quoted attribute value syntax and double-quoted attribute value syntax). For each of these types of syntax, the specification requires the following (emphasis mine):

If an attribute using ... syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.

Also, F70 does not require that each attribute has a value. The clause "except where the specifications allow these features" in SC 4.1.1 is there to avoid syntax requirements that go beyond those in format specifications.

Conclusion: Only example 5 goes beyond SC 4.1.1 when it is used in an HTML 5 document. None of the examples go beyond the success criterion in an XML context.

[JAWS-test]

@cstrobbe Example 3 and 4 are of course syntactically incorrect. However, 4.1.1 does not check the entire syntax, but only the 4 conditions mentioned in SC 4.1.1. Now the question is, how condition 1 is understood:

elements have complete start and end tags

Why should a tag not be complete if the attributes within the tag are not syntactically correct, but the tag is opened or closed correctly?

I suggest that at least in example 5, as in examples 1 and 2, it is mentioned that it is only a violation in XHTML.

Also, I'm just wondering why example 1 is not a violation of HTML? I think in example 1 the restriction to XHTML could be removed.

[cstrobbe]

The question is whether the note matches the SC text: "elements have complete start and end tags" - there is no mention here of attributes having correct quotation marks.

After looking into this again, I noticed that notes aren't part of WCAG's normative content, so the first note isn't part of the SC's normative content, either. Examples 3, 4 and 5 in F70 illustrate something in the note that may be seen as going beyond the SC (even though it is entirely in the spirit of the SC).

Why should a tag not be complete if the attributes within the tag are not syntactically correct, but the tag is opened or closed correctly?

Well, that's what the SC was intended to mean but failed to capture accurately in its normative part. Unfortunately, addressing this issue requires adding a fifth condition, which might be perceived as making the SC stricter than its current wording. Any changes that cause WCAG 2.2-conforming pages non-conforming to WCAG 2.1 are likely to be rejected by the working group.

This affects examples 3 and 4, which represent syntax errors both in XHTML and in HTML5. Example 5 is a syntax error in XHTML but not in HTML5.

Example 1 is a syntax error in XHTML and HTML5 because the start tag in incomplete. (Unless the parser interprets the text content as attributes, in which case the closing p tag causes a syntax error. This should be explained more clearly.)

Example 2 is explicitly described as an XHTML syntax error. It would be helpful to add that it is not an HTML5 syntax error (nor an HTML5 validation error).

[patrickhlauke]

might be perceived as making the SC stricter than its current wording. Any changes that cause WCAG 2.2-conforming pages non-conforming to WCAG 2.1 are likely to be rejected by the working group

but in this case, if 2.2 is stricter, it will still be ok because if it passes the stricter requirement in 2.2, it will naturally pass the laxer requirement in 2.1.

it's the other way around that won't necessarily be true (something that passed under 2.1 may fail under 2.2)

[GreggVan]

On Jun 23, 2022, at 3:12 AM, cstrobbe ***@***.***> wrote: The question is whether the note matches the SC text: "elements have complete start and end tags" - there is no mention here of attributes having correct quotation marks. After looking into this again, I noticed that notes aren't part of WCAG's normative content, so the first note isn't part of the SC's normative content, either. Examples 3, 4 and 5 in F70 illustrate something in the note that may be seen as going beyond the SC (even though it is entirely in the spirit of the SC). Why should a tag not be complete if the attributes within the tag are not syntactically correct, but the tag is opened or closed correctly? Well, that's what the SC was intended to mean but failed to capture accurately in its normative part. Unfortunately, addressing this issue requires adding a fifth condition, which might be perceived as making the SC stricter than its current wording. Any changes that cause WCAG 2.2-conforming pages non-conforming to WCAG 2.1 are likely to be rejected by the working group.

Hi I think you have this backward. The WG has added new SC — and those would all fail your rule - if it were true. What we have been trying to do is to make it that passing 2.1. (and 2.2). would ALSO pass 2.0. (or 2.1). Not the other way around. So adding a provision to make it accurate would not be a problem. Adding exceptions is a flip side - but I would suggest those too if there was in fact an error in the guideline. Best g

…

This affects examples 3 and 4, which represent syntax errors both in XHTML and in HTML5. Example 5 is a syntax error in XHTML but not in HTML5. Example 1 is a syntax error in XHTML and HTML5 because the start tag in incomplete. (Unless the parser interprets the text content as attributes, in which case the closing p tag causes a syntax error. This should be explained more clearly.) Example 2 is explicitly described as an XHTML syntax error. It would be helpful to add that it is not an HTML5 syntax error (nor an HTML5 validation error). — Reply to this email directly, view it on GitHub <#2187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXVG7HNXILIQWHNBCFLVQQ2BHANCNFSM5MHBSKPA>. You are receiving this because you are subscribed to this thread.

[cstrobbe]

but in this case, if 2.2 is stricter, it will still be ok because if it passes the stricter requirement in 2.2, it will naturally pass the laxer requirement in 2.1.

That's good, but does not address the real issue in F70 as reported by @JAWS-test. Since no one has suggested modifications to the failure technique, my suggestion follows below:

1. Applicability: Change "Markup languages: HTML, XHTML, and other SGML or XML-based technologies." to "Markup languages: HTML 4 (and older), XHTML, other SGML- or XML-based technologies and HTML 5". Rationale: HTML 5 is based neither on SGML nor on XML.
2. Description:
   • Delete "Attribute values that have an opening quote but not a closing quote. Attribute values must be either fully quoted or, in some markup languages, may be unquoted." Rationale: These are real syntax issues but go beyond the SC. They illustrate something mentioned in the note to the SC, but notes are non-normative.
   • Delete "Lack of whitespace between attributes." This is a real syntax issue but see the rationale for the previous deletion.
   • Delete "Unquoted attribute values that have whitespace in the value." This is a real syntax issue but see the rationale for the first deletion.
3. Example 1:
   • Change "Missing angle brackets in XHTML" to "Missing angle brackets in XHTML or HTML 5". (The code sample also represents a syntax issue in HTML 4, but updating F70 to HTML 5 is more important than adding info related to HTML 4.)
   • Change "the intended boundary of the tag is unclear" to "the intended boundary of the start tag is unclear to a parser". (This change is not critical.)
4. Example 2. Add after the current discription: "This does not cause a syntax error in HTML 4 or HTML 5, since the second tag is interpreted as the start tag of a new p element."
5. Example 3: Remove this example, since it illustrates something in the note to the SC but goes beyond the text of the SC itself. (It is clearly in the spirit of the SC, but the note is non-normative.)
6. Example 4: Remove this example. Rationale: same as for Example 3.
7. Example 5: Remove this example. Rationale: same as for Example 3.
8. Example 6: Add after the current discription: "This does not cause a syntax error in HTML 4 or HTML 5, since the second start tag implicitly closes the first p element."
9. Tests: Change "Check whether any opening tags, closing tags or attributes are malformed." to "Check whether any opening tags or closing tags are malformed."

@patrickhlauke Does the WG take over the issue from here or is it more convenient if I create a pull request on Failure F70?

[JAWS-test]

@fstrr Maybe you want to take it over, because you are cleaning up the old documents?

[fstrr]

@JAWS-test Thanks :) I'm working my way through the HTML Techniques at the moment and have about 30 left. After that, I can start on the Failures.