@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.

@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.

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

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?

Note: 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>.

Regarding 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.

However, it would catch things like <button><h2>Thing</h2></button>

but that's still going beyond syntax (well-formedness) ... so which is it?

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.

I guess there is a difference between syntactical and content model that I'm missing.

Please see my update from 18.07.2022 at the top of the page.

I thought that those types of errors were exactly what 4.1.1 were supposed to catch, i.e. nested according to the spec.

That's the misunderstanding this issue attempts to address. This is about syntactical nesting so web content can be "accurately parsed into a data structure" (quoted from Understanding SC 4.1.1).

The understanding document also says,

The concept of "well formed" is close to what is required here. However, exact parsing requirements vary amongst markup languages, and most non XML-based languages do not explicitly define requirements for well formedness. Therefore, it was necessary to be more explicit in the success criterion in order to be generally applicable to markup languages.

Validating content models goes beyond what is intended here.

I guess there is a difference between syntactical and content model that I'm missing.

it's the difference between syntax and grammar - think of it in terms of a word document...spell checking checks the syntax (words are spelled right), but not grammar (that words are arranged in such a way that they make proper sentences)

If you want to make comparisons with natural language, Chomsky's famous Colorless green ideas sleep furiously is a better analogy: it is syntactically correct and can be parsed into a tree structure. But it makes no sense semantically.

I had a parallel discussion (I was not aware about this proposal yet) in ACT-Rules about something similar (act-rules/act-rules.github.io#1893).

<label for="first-name">
    <span>First name</span>
    <input type="text" name="fn" value="">
</label>

and

<input type="file" id="test" />
<label for="test">Flash the screen 
    <select size="1">
        <option selected="selected">1</option>
        <option>2</option>
        <option>3</option>
    </select>
    times.
</label>

Initially, I was unconsciously supporting this new issue proposal, assuming that "elements are nested according to their specifications" and "H74: Ensuring that opening and closing tags are used according to specification (HTML)" referred to the syntactical rules of their specifications.

But @Jym77 pointed out that

H74 cover the bit about correct nesting (Step 3  in the test procedure). So, I would say that a label with a for pointing elsewhere than the nested labellable does not pass H74 (and certainly does not pass the "elements are nested according to their specifications" bit of 4.1.1).

where, essentially, code examples above are failing 4.1.1 in the first place.
In fact, the examples provided are something not allowed by the label content model specs.

But, per this new proposal,

2. elements are nested according to the syntactical rules of their specifications

...

Note: 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.

if the content model is no longer relevant in terms of 4.1.1 Parsing, they are no longer failing the 4.1.1 SC.

In addition, per Input Accessible Name and Description Computation rules is still not clear how to calculate the label, as point n.2 states

Otherwise use the associated label element(s) accessible name(s) - if more than one label is associated; concatenate by DOM order, delimited by spaces.

which is quite ambiguous as in the first code example, the for attribute does not exist, in the second code example instead we have a combination of both for/id attributes and nested content, which is quite unpredictable.

Last, but not least, browsers behave inconsistently (more details in act-rules/act-rules.github.io#1893); for example Safari provides a label, while Chrome doesn't.

Do we expect this scenario is failing 1.1.1, 1.3.1, 2.5.3, 3.3.2, 4.1.2 success criteria due to the discrepancy with content model but passing 4.1.1 thanks to the correct syntax?

it would likely fail 4.1.2 if the end result is a lack of accessible name, and probably 1.3.1 for lack of explicit association/relationship

But @Jym77 pointed out that

H74 cover the bit about correct nesting (Step 3  in the test procedure). So, I would say that a label with a for pointing elsewhere than the nested labellable does not pass H74 (and certainly does not pass the "elements are nested according to their specifications" bit of 4.1.1).

That does not mean that the code fails SC 4.1.1; it means that the code is not using technique H74. Not using technique H74 does not automatically mean you fail the SC the technique addresses.

Neither of those code examples contains syntactical issues in the context of HTML syntax. In the context of XML syntax, the first example would not be well-formed. But in HTML syntax, the input element has no end tag (it's a void element). Whether the label element can contain an input element is not a syntactical question but a matter of content models, and the content model allows it (i.e. as a way of labelling that input).

The second code example does not exhibit any syntax issues but the label element seems to label two controls, i.e. both the one above it and the one inside it. The HTML specification does not seem to define which type of labelling takes precedence, the one defined by the for attribute or the one based on nesting. Hence, the relationship between the label and the control it labels visually (i.e. the control below it) cannot be determined programmatically in an unambiguous manner, so the code seems to violate SC 1.3.1.

But @Jym77 pointed out that

H74 cover the bit about correct nesting (Step 3  in the test procedure). So, I would say that a label with a for pointing elsewhere than the nested labellable does not pass H74 (and certainly does not pass the "elements are nested according to their specifications" bit of 4.1.1).

That does not mean that the code fails SC 4.1.1; it means that the code is not using technique H74. Not using technique H74 does not automatically mean you fail the SC the technique addresses.

It was not exactly the case; I was supporting the thesis that the label example was not failing 4.1.1 because of point 4 of 4.1.1 sufficient techniques 4 (that includes 3 sufficient techniques), as in my opinion all of them were passed.
@Jym77 just pointed out that the first sufficient technique of these group of 3 one is not passing; he is not saying that for this reason it's a 4.1.1 failure.

Hi @alastc,

I would like to ask you to bring the issue to a decision in a timely manner. Background: In the European Union thousands of web sites are checked according to EN 301 549. Most of the violations are found for SC 4.1.1. As an example I would like to mention the German monitoring report: https://www.bfit-bund.de/DE/Downloads/eu-bericht-pdf.pdf;jsessionid=7266E7F6DCC8058D664888E08830EC21?__blob=publicationFile&v=2, page 102. So it seems that the most important accessibility problem is 4.1.1, because it is violated the most. The problems found with 4.1.1 are largely due to incorrect nesting (which is what this issue is about). Only rarely does a duplicate ID show up as a problem. The other errors described in 4.1.1 do not occur in practice because they are automatically corrected by the browser. If 4.1.1 were reworded as suggested by @cstrobbe, 4.1.1 would finally regain the weight it deserves: namely, a low weight. And we could take care of the really important problems of accessibility!

@GreggVan

NOTE - the fact that browsers accommodate errors was pointed out when working on WCAG 2.0 - but that does not help AT that needs to parse the content. It is only if the browsers actually repair the content - and the AT can use that repaired content — that we can ignore the errors that browsers accommodate. AT developers don’t have as deep of pockets to detect and repair bad content as browsers do.

In the past there was AT, which accessed the source code and not the DOM. That's why correct source code was important. As far as I know, there is no AT today that accesses the source code. If there were, it would be outdated and quite useless, since web content today is not primarily source code, but source code + CSS + Javascript. The browsers create the (corrected) DOM from this and pass this on to the Accessibility API. The AT uses either the API or the DOM. AT, which would use the source code, would not be able to recognize correct content on many pages, because the content is generated or changed dynamically and thus does not appear in the source code at all. That's why I think that for 4.1.1 we should only care about what is generated as DOM by the browsers.

NOTE - the fact that browsers accommodate errors was pointed out when working on WCAG 2.0 - but that does not help AT that needs to parse the content. It is only if the browsers actually repair the content - and the AT can use that repaired content — that we can ignore the errors that browsers accommodate. AT developers don’t have as deep of pockets to detect and repair bad content as browsers do.

note that the error correction mechanisms are now a documented part of the HTML specification (while in the past, this was all undocumented and left up to mysterious black box browser heuristics, which is in part the reason for 4.1.1 because it was trying to avoid that devs just relied on testing in their favourite browser and missed how other browsers would parse broken content)

Double negative?

What follows is another attempt to address Gregg Vanderheiden's comment about something that may look like a double negative.

All SGML-like languages (HTML 4.x, XHTML, HTML 5, SVG, MathML, etc.) rely on hierarchy and a type of syntax tree (of which the DOM is the best-known example). Parsing a document into a syntax tree requires correct nesting at the syntactical level. Each element is always a child of another element, unless it is the document element or root (html in HTML formats). As a consequence, code such as <para>...<bold> ... </para> ... </bold> is prohibited in all SGML-like languages and leads to a parse error, regardless whether the language defines (content models for) para and bold or not. So when we say, "elements are nested according to the syntactical rules of their specifications", we are actually paraphrasing something that SGML, XML and HTML 5 have in common. [1] The exception "except where the specifications allow these features" would not be relevant to these languages.

The exception may be relevant to other types of markup languages, such as TeX and LaTex, but these (1) are geared towards typesetting, (2) would present serious challenges to meet many of the other WCAG success criteria when read directly by user agents and (3) are usually rendered into another format, most frequently PDF. PDF is not a markup language, so SC 4.1.1 does not apply to it. (In practice, we would probably lose nothing by deleting "except where the specifications allow these features", but I don't want to increase resistance to my proposal by adding that change.)

One issue with the current wording is that I haven't commented on yet is how "except where the specifications allow these features" seems to work. "These features" seems to refer to

• "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".

SGML-like languages do not merely "allow" these features, they are rather basic requirements. The intended meaning is "except where the specifications allow exceptions to these requirements", but (1) the current wording says the opposite and (2) I don't know of any markup languages on the web that allow the intended exceptions.

One inconvenience with "elements are nested according to the syntactical rules of their specifications" is that HTML, unlike XML, does not cleanly separate syntax and validity, so a parser will always refer to content models when parsing an HTML document into a tree. For example, <p><h1>Content Model Validity</h1></p> can be perfectly parsed into a tree if syntax is the only thing you look at. But if you look at the content model for the p element in HTML 5, you'll notice that p cannot contain heading elements and that it is an element whose end tag can be omitted when it is followed by a heading element. So the browser turns the code into the following: <p></p><h1>Content Model Validity</h1></p>: it closes the first p element, and the end tag </p> is orphaned, which causes a parsing error. If we want to get around this interference between validity and syntax, it may be better to write something like "elements don't overlap at the syntactical level" or "elements don't overlap in the syntax tree". This would fail something like <strong><em></strong></em> but not <p></p><h1>Content Model Validity</h1></p>. If we also want to fail the latter code sample, we would need to add a condition such as "the syntax tree does not contain orphaned end tags". (I am avoiding the term "Document Object Model", because the DOM is not a data structure or a set of data structures.)

Examples for the Understanding doc

I think it would be beneficial to add some examples to Understanding Success Criterion 4.1.1: Parsing, which currently doesn't have an examples section.

Example 1

<span><div>...</div></span> is not valid HTML because the content model for the span element does not allow div elements. However, the code is syntactically unambiguous and can be parsed into a data structure. Therefore, it does not fail SC 4.1.1.

Example 2

<a href="https://www.w3.org/"><a href="https://www.w3.org/WAI/">Web Accessibility Initiative</a></a> is not valid because the content model for the a element does not allow any other interactive content. However, the code is syntactically unambiguous and can be parsed into a data structure. Therefore, it does not fail SC 4.1.1.

Example 3

<p>The raven himself is hoarse  
<p>That croaks the fatal entrance of Duncan  
<p>Under my battlements. Come, you spirits`

This code snippet meets the success criterion when used in an HTML document (but not in XHTML): it is both syntactically correct and valid. The p element is an element where the end tag is optional. A browser is able to parse it and implicitly add the end tags as follows:

<p>The raven himself is hoarse</p>
<p>That croaks the fatal entrance of Duncan</p>
<p>Under my battlements. Come, you spirits</p>

Example 4

<ul>
  <div>
    <li>List item 1
    <li>List item 2
  </div>
</ul>

This code snippet is not valid because the content model of ul does not allow a div element as a child element. However, the code is syntactically unambiguous and can be parsed into a data structure. Therefore, it does not fail SC 4.1.1.

Example 5

<p><input id="username" name="username" type="text" /></p>
<p><label for="username">College:
  <select size="1">
    <option selected="selected">Foxe College</option>
    <option>Jordan College</option>
    <option>Wordsworth College</option>
  </select>
</label>

This code snippet is invalid because a select element that is a descendant of a label element with a for attribute must have an ID that matches the value of the for attribute. Since the code can be parsed unambiguously into a data structure, it does not fail SC 4.1.1. However, the HTML specification does not define which type of labelling takes precedence: the one defined by the for attribute or the one based on nesting. Hence, the relationship between the label and the control it labels visually (i.e. the control below it) cannot be determined programmatically in an unambiguous manner. If browsers determine that the first input's accessible name is the label element (including its descendant, the select element), the code violates SC 1.3.1.

[1] What is perhaps confusing is that non-XML languages such as HTML 4 and HTML 5 allow certain elements to omit the end tag. (See Optional tags in the HTML 5 spec.) For example, <div><p>Elements have complete start and end tags.</div> is perfectly valid in both HTML 4 and HTML 5 but not in XHTML. The p element is entirely contained in the div element because the browser "knows" that when it encounters the end tag </div>, it can close all child elements where end tags may be omitted, so it silently inserts a </p> just before the </div> and it is perfectly possible to create an unambiguous parse tree. For the purpose of SC 4.1.1, <div><p>Elements have complete start and end tags.</div> is perfectly fine (except in XHTML) since the elements are correctly nested. It is important to bear in mind that the SC requires elements to be properly nested without referring to the details of how optional tags work.

(For tree construction and syntactically correct nesting in HTML 5, I refer to the stack of open elemennts, the section Tree construction and the sections on misnested tags: Misnested tags: <b><i></b></i> and Misnested tags: <b><p></b></p>.)

@bruce-usab

I do not agree with this characterization. The intention of 4.1.1, as with all SC, is to find actual errors

I would disagree with that. On the one hand it says differently in 4 and 4.1 and on the other hand 4.1.1 is about avoiding potential problems that could result from wrong source code / DOM, but don't have to:

Ensuring that Web pages have complete start and end tags and are nested according to specification helps ensure that assistive technologies can parse the content accurately and without crashing.

It's not like every violation of 4.1.1 will crash an AT, but it increases the likelihood that the AT won't work correctly - at least that's the Understanding's explanation, which thus supports my reading rather than yours

@bruce-usab

Citation please for "not always"?

According to the HTML specification, an ul element may contain only li elements. If an ul element contains a div element, this is not a violation of 4.1.2 because an ul is not a user interface component.

Whether it is a violation of 1.3.1 depends on the text content and visual presentation. Visually, it can be a list that contains list items and text that refers to all list items, i.e. is part of the list, but not a list item itself. This is not representable in HTML, but it is visually representable and structurally describable. Thus, an ul with div would not be a violation of 1.3.1 because it correctly reflects the visual information. But: An AT may have problems with div in ul leading to an incorrect structure in the Accessibility API. Another AT has no problems with this. So something like this is only objectionable with 4.1.1 (or 4.1.4).

If I encounter something like this: test page

<button onclick="alert('Goodbye Twitter')">
<a href="https://mastodon.social/@SteveFaulkner">SteveF on Mastodon</a>
</button>

What SC will it unambiguously fail (apart from 4.1.1)?

@stevefaulkner that's the example I raised a year ago and it and other structures cause issues for screen readers and other assistive technology. At the time people were suggesting it could fall under SC 2.1.1 Keyboard but I believe the impact could be greater than that.

@stevefaulkner @mraccess77 From the discussion here, I understand that this is an example that does not fail 4.1.1 since it parses unambiguously. It would, however, fail the proposed 4.1.4 if it is created at some point.

OTOH, <button> <a href="…">Hello</button> </a> would fail 4.1.1 but is actually fixed by the HTML parsing algorithm, so it is never encountered (when using conforming UAs).

So, this example may be a case where there are accessibility issues that are not caught by any other SC. But these issues are also not caught by 4.1.1 (or at least should not be with the intended meaning of 4.1.1 when it was created) and removing 4.1.1 does not change the result of the audit.

What SC will it unambiguously fail (apart from 4.1.1)?

As @Jym77 mentioned, this thread highlights that it wouldn't be caught by (the original intent of) 4.1.1.

In that case, I can think of a few options, in order of personal preference:

• Name role value, the button lacks a name (but has a separate function from the link).
• Focus order: There is a lack of meaning when you have two tab-stops that appear to be in one place.

In general terms, if you have nested controls like that, the function of one of them will be compromised either in functionality or understanding. It might depend on the details of each, but in general I'd look at 4.1.2, 1.3.1, 2.1.1, focus order, and/or headings & labels. Link purpose might be possible for some, although I think "ambiguous to all" probably applies in this case.

Since this is still an open discussion and lists are referenced again, I cite this comment from @giacomo-petri on 5 August:

For example, removing the list-style CSS property (list-style="none"), with Safari + VO elements are no longer announced as list and list items and correct list structure and incorrect list structure are both announced as regular text. […]

Even if I generally agree with your proposal @cstrobbe of clarifying what's impacted by 4.1.1, distinguishing content models and syntactical nesting, I'm a little worried about the possible interpretations and impact of these changes, especially for scenarios like the previous one.

The comment never got a response. I am still curious if every instance of a list with bullets styled away is a failure of 4.1.1 as @cstrobbe explained it. If so, only in Safari? Or if Safari's known removal of list semantics means using list style: none is an automatic 4.1.1 failure according to the original intent.

The comment never got a response. I am still curious if every instance of a list with bullets styled away is a failure of 4.1.1 as @cstrobbe explained it. If so, only in Safari? Or if Safari's known removal of list semantics means using list style: none is an automatic 4.1.1 failure according to the original intent.

I would say no, it isn't a 4.1.1 failure. The browser has made a deliberate choice about how to render content for assistive technologies, and users can choose to use a different browser if they prefer the user experience. If basing a conformance claim on the way a site works with Safari, an author might opt for a different bullet treatment.

https://bugs.webkit.org/show_bug.cgi?id=170179#c1

If there was a failure here, it would be a 1.3.1 failure anyway due to the visual appearance of a list (assuming that the author finds some other, non-semantic, way to covey that there is a list) not being consistent with the information communicated to users, not a 4.1.1 issue.

@aardrian, it was a broader discussion and my feedback was specific to answer/discuss quoted items.

That said, considering the original intent of 4.1.1 SC, I'm in favour of removing it, especially to avoid the high numbers of false positives that do not impact users with disabilities; many times, the 4.1.1 issues are detected by automatic scans and focus the remediation phase on items that shouldn't be treated with this priority.

Moreover, 4.1.4 should help covering these scenarios.

Last, but not least, about the list example: this behaviour is recurrent with Safari (similar behaviour happens for example if you use display:flex on a table). Aware of that, usually if I want to remove the list bullets with "list-style-type:none" CSS property, I also set role="list" to the <ul> or <ol> element, ensuring it works also with Safari. That said, I think is not an author responsibility.

For example, removing the list-style CSS property (list-style="none"), with Safari + VO elements are no longer announced as list and list items and correct list structure and incorrect list structure are both announced as regular text. […]
Even if I generally agree with your proposal @cstrobbe of clarifying what's impacted by 4.1.1, distinguishing content models and syntactical nesting, I'm a little worried about the possible interpretations and impact of these changes, especially for scenarios like the previous one.

The comment never got a response. I am still curious if every instance of a list with bullets styled away is a failure of 4.1.1 as @cstrobbe explained it. If so, only in Safari? Or if Safari's known removal of list semantics means using list style: none is an automatic 4.1.1 failure according to the original intent.

I don't see anything in success criterion 4.1.1 that refers to styling, so I don't see why that would fail the SC. Even using the validation interpretation wouldn't have caused a failure of SC 4.1.1 because an HTML validator doesn't check CSS.

@awkawk I agree.

@giacomo-petri I understand it was part of a larger discussion.

My question was for @cstrobbe, partly because of this comment:

However, for the list with the div inside it, the individual list items were not announced as list items in Firefox. This seems to mean that the list items are not programmatically determinable. This looks like a failure of SC 1.3.1 so there is no need leverage SC 4.1.1 to fail it. In Edge, the div makes no difference at all; each item in the list is announced as a list item (NVDA says "bullet").

Though I should have asked if it fails WCAG by his reading, no matter which SC.

@cstrobbe

I don't see anything in success criterion 4.1.1 that refers to styling, so I don't see why that would feel the SC. Even using the validation interpretation wouldn't have caused a failure of SC 4.1.1 because an HTML validator doesn't check CSS.

Our comments passed one another in the night/morning. I mean to ask if failed any interpretation of WCAG. I should have cited your original comment as well (which I did in the previous comment).

Another argument favour of deprecation.

Trying to redefine SC 4.1.1. to "nested according to the syntactical rules of their specifications" to align with the original intent won't work with the HTML Living Standard. That's because the LS includes content model restrictions as part of the HTML syntax:
https://html.spec.whatwg.org/multipage/syntax.html

This is reflected in the state machine for the HTML parser which builds the DOM. The state machine makes no distinction between handling mis-nested code like <b>1<p>2</b>3</p> and handling content model restrictions like <table><b>Bold</b><tr><td>aaa</td></tr>bbb</table> where <b> is not allowed at the top level of the table.

https://html.spec.whatwg.org/multipage/parsing.html#an-introduction-to-error-handling-and-strange-cases-in-the-parser
https://html.spec.whatwg.org/multipage/parsing.html#creating-and-inserting-nodes

This is theoretically impure, but allows the HTML parser to handle/repair many common HTML authoring errors.

This is very different to XML parsers where there's a core syntax that parses XML into a DOM, and there's a clear separation between the core syntax and the content model provided in a schema/DTD.

Edit: you can see an HTML parser implementation here - this is used by validator.w3.org/nu and by Firefox:
https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/TreeBuilder.java

The outcome from the discussion was that there was good support for removing 4.1.1 from WCAG 2.2. We can circle back later to decide whether to add an errata to 2.0/2.1 for the syntactical aspect.

Since SC 4.1.1 was the main reason Principle 4 is called "Robust", shouldn't the principle be renamed as well?
SC 4.1.2 and 4.1.3 aren't really about robustness but about certain types of information being programmatically determinable. Most other SC that require things to be programmatically determinable are under Guideline 1.3
Perhaps SC 4.1.2 and SC 4.1.3 can be moved elsewhere so Principle 4 removed entirely.

For correctness...

Trying to redefine SC 4.1.1. to "nested according to the syntactical rules of their specifications" to align with the original intent won't work with the HTML Living Standard. That's because the LS includes content model restrictions as part of the HTML syntax: https://html.spec.whatwg.org/multipage/syntax.html

Content model restrictions are actually generally not part of the HTML syntax.

There's a section called "Restrictions on content models", where the content model for table and pre is special because HTML parsing is special, but it doesn't follow that all content models are also part of the syntax or the parser.

This is reflected in the state machine for the HTML parser which builds the DOM. The state machine makes no distinction between handling mis-nested code like <b>1<p>2</b>3</p> and handling content model restrictions like <table><b>Bold</b><tr><td>aaa</td></tr>bbb</table>

Yes it does, the first case is handled by the Adoption Agency Algorithm and the second is handled by Foster Parenting. The goal of these algorithms are to be web compatible, not to match content model restrictions. (However, the behavior of old browsers' HTML parsers can maybe be traced to an HTML DTD, so there is still some correlation.)

Example: this is not a parse error: <b>1<p>2</p>3</b> (despite not being allowed by the content model)

Since SC 4.1.1 was the main reason Principle 4 is called "Robust", shouldn't the principle be renamed as well?...
Perhaps SC 4.1.2 and SC 4.1.3 can be moved elsewhere so Principle 4 removed entirely.

Chair hat on, I don't think that's something that the group would would interested in doing. (Consider that it's not related to a core accessibility requirement, so a couple of objections would prevent it happening as i.)

Even if it were just 4.1.2 left, I don't think we'd update POUR in WCAG 2.x.

Noting that this has been removed this from WCAG 2.2, but leaving open for potential updates to 2.1/2.0