Proposal to Rephrase Success Criterion 4.1.1

[cstrobbe]

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.

In content implemented using markup languages, the following are true, except where the specifications for the markup languages being used allow exceptions to these requirements:

1. elements have complete start and end tags,
2. elements are nested according to the syntactical rules of their specifications,
3. elements do not contain duplicate attributes, and
4. any IDs are unique.

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

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.

Note: When a scripting language is used to manipulate elements or attributes (or both) in the Document Object Model, the resulting in-memory representation is still regarded as "content implemented using markup languages".

Description of the changes:

• The second condition has been reworded to highlight syntactical correctness (as opposed to validity of content models).
• The second note, which is new, draws attention to this. The first note is identical to the note in the WCAG 2.1 recommendation from June 2018.
• The numbering is new; the phrase "the following are true" is copied from other success criteria, such as SC 1.2.1 and SC 2.2.2.
• The third note addresses an issue unrelated to the distinction between correct syntax and validity.

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 #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 div may not be nested inside a span. 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 chapter and says it must contain a chaptertitle followed by at least one para or heading. 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 The section element, which says that this element may only contain flow content.

[GreggVan]

Comments inline marked GV:

gregg

On Nov 4, 2022, at 4:40 AM, Eric Eggert @.***> wrote:

Please copy this email into the "institutional memory" pages so that this can be captured and this discussion, which keeps popping up, can be put to rest.

People may not agree with the decision of the Working Group (and people in the working group had different opinions) - but we need to stay with what was decided and the intent of the working group when it reached consensus.

Sorry, these sentences irked me more than I realize. If a discussion “keeps popping up”, it should be properly resolved, as a normative change to WCAG. Because discussions “keep popping up” because the SC is bad.

There is a difference between
"I think it should be changed normatively" (which is fine - you can propose such a change any time)
And This is what the SC means and we should change understanding document to agree with that interpretation.

When I said it keep popping up - I meant that the question about whether SC 4.1.1 required headings to be nested - keeps popping up. So the answer to that question needs to be documented somewhere (and Understanding WCAG 2.0 is best place) so it doesn’t keep popping up.

I think it is bad form to say “Please take my word as gospel and put it into the ‘institutional memory’ because I know what we meant, and my interpretation is flawless”. There might be no consensus on how to resolve this issue, but I think these discussions, and that they “keep popping up” shows that there is a consensus that it is hard to understand

1) It is not just my opinion. It is what several of us who were in that working group remember and can attest to - and have on the list. The latest other person was Christophe Strobbe

2) as the co-chair of WCAG at that time — I have been asked to document these types of things and their rationale’s so they can be recorded in an "institutional memory" page - lest they get lost. In particular what is most valuable is the rationale for why things were decided the way they were. Sometimes it is not obvious until it is explained. (Even at the time, we sometimes were headed one direction until someone pointed something non-obvious to us which caused us to change to the language used. This is what needs to be captured the most. Which is why I wrote a long email about why — instead of just saying what I remembered or what I thought it should be.

. I think it is generally bad for to claim that the WG has decided something in 2008 or so, and it will be always correct and infallible until the rest of time.

That is the way standards work. When consensus is reached - it becomes the standard - and remains the standard until it is changed. It doesn’t matter if it was yesterday or 3 decades ago. The standard is what the standard was until changed. That said - a standard can be changed at any time. And then what it is changed to becomes the standard - and it does not matter what it was — or how long that was true. The new standard is the standard.

The question here - was not what it SHOULD be. But what it is. That is - "What was it - what did it mean - when it was created (and what it will be until it is changed).

Turns out, the WG is humans, humans are imprecise and a great skill is that we can correct these errors and imprecisions. Let’s do that.

That is fine. And I completely agree. But then you should be arguing for a change. Not arguing that it should mean something other than what it meant when it was created and agreed on (and still means until it is changed).

I will also note that there are provisions in WCAG 2.x that I do not like or do not think should be as they are. But they are what we reached consensus on - and I will defend that - even if I don’t agree with it. If I feel strongly enough - I will argue for it in a future round and see if I can convince everyone to agree to change it. But until it is changed - I need to accept what it is.

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1303303784, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXX3NYUGZSYPLPNEY5DWGTY2ZANCNFSM5ZRXNZ6A. You are receiving this because you were mentioned.

[GreggVan]

That provision is not about understandability. It was only meant to be about mechanical parsing — hence the name.

There is no argument that properly nested heading are easier to understand.
But that is not the topic of this SC and this SC cannot be used to say that it is required.
HTML may require it - but WCAG 2.x does not.

I concur with your comment that the Understanding WCAG 2.x document was meant to aid understanding the SCs - and that in many places it could do better.

gregg

On Nov 4, 2022, at 12:58 AM, Eric Eggert @.***> wrote:

The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content.

Wrongly nested content can impact interpretation in HTML The Living Standard. Alternatively, HTML The Living Standard uses consistent error correction for all the “problems” outlined in the SC, so one could also say that it can always accurately interpret and parse content.

The Accessibility Tree of wrongly nested documents according to HTML The Living Standard will almost always result in inaccurately interpreted content for AT.

Again, I don’t care about the Understanding. It cannot change the words and meaning of the SC and WCAG would be easier to teach, understand, and use, if we wouldn’t say “oh yes, we wrote x in the SC, but if you look at the Understanding, you see that we actually meant seventeen other different things”. It’s fairly ridiculous at this point.

These a “Understanding” documents, not “Well, actually” documents.

(Brief note: The email formatting comes across as plain text, no heading, no marking up quotes. This is super hard to parse and, I would appreciate if one could follow 1.3.1 and at least apply some markup/down for easier reading.)

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1303088420, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXUF7VCZBTDP5377BOLWGS6Y3ANCNFSM5ZRXNZ6A. You are receiving this because you were mentioned.

[yatil]

But then you should be arguing for a change. Not arguing that it should mean something other than what it meant when it was created and agreed on (and still means until it is changed).

But that is what I do. The thread here is called “Proposal to Rephrase Success Criterion 4.1.1“. The whole idea is that we change 4.1.1 to mean something useful. (Or at least clarify the useless intended interpretation.)

[GreggVan]

Very fine

I only posted my comment to comments saying that it just changing the wording to be easier to understand — rather than changing it to mean something different.

Gregg

PS (4.1.1 may indeed have outlived its usefulness since (to my knowledge) AT does not directly read the HTML and try to parse it anymore. (If anyone knows of AT that still does that please post and inform/correct me on this. I would like to know).

If it has - then we should eliminate 4.1.1 going forward.

As to a new SC that requires strict HTML adherence — I would leave that up to the group. We found that it was good in HTML with is NOT regulated — but not of sufficient merit to accessibility to add it where it might result in strict HTML specifications being require by regulation.

If it is only nesting of headers that are of interest - then one might propose just that. And see if there is consensus that that should be regulated.

All the best

g

On Nov 4, 2022, at 3:17 PM, Eric Eggert @.***> wrote:

But then you should be arguing for a change. Not arguing that it should mean something other than what it meant when it was created and agreed on (and still means until it is changed).

But that is what I do. The thread here is called “Proposal to Rephrase Success Criterion 4.1.1“. The whole idea is that we change 4.1.1 to mean something useful. (Or at least clarify the useless intended interpretation.)

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1304302994, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXWW5OFM26ZDHA6R6EDWGWDQ5ANCNFSM5ZRXNZ6A. You are receiving this because you were mentioned.

[bruce-usab]

If a discussion “keeps popping up”, it should be properly resolved, as a normative change to WCAG. Because discussions “keep popping up” because the SC is bad.

What is "properly resolved" when the repeated and unambiguous consensual response from AGWG is "no, sorry, not interested"?

FWIW, I was one of the few making the case that validity (1.0 Checkpoint 3.2) should be used instead of the present SC 4.1.1. I took my lumps and moved on. The SC is what it is. What it was in 2008. For the 2.2 work, the AGWG considered and decided against non-editorial changes to 2.0/2.1. The AGWG also considered and decided against working on a WCAG 2.3. It has been a long-standing principle not to make normative changes via Understanding.

Or at least clarify the useless intended interpretation.

I am of the opinion that this is already inferred by a plain reading of Understanding. Please do propose a tactful PR to Understanding which would help prevent this question from being raised.

[yatil]

I don’t read it that way and I will not provide a “tactful PR” to Understanding because I have no idea how “In content implemented using markup languages, […] elements are nested according to their specifications, […] except where the specifications allow these features.” can be read differently than that nesting of elements must conform to the specification of the markup language.

HTML (living standard) has nesting rules (don’t nest headings inside headings) which are in its specification. It is a markup language.

Again, if you want to have a PR, make a suggestion that makes sense with the normative text. Or just plainly explain how the sentence above does not apply for HTML documents. Is HTML not considered a markup language? This makes no sense.

What is "properly resolved" when the repeated and unambiguous consensual response from AGWG is "no, sorry, not interested"?

I’m merely pointing out that the Working Group is refusing to do their work here. Of course they can say “we don’t care” but that is why W3C has a public phase in the standards process. Not addressing valid public implementation comments is a process violation and I would expect W3C to not have a PR or REC.

[bruce-usab]

I am of the opinion that the present Understanding, especially the Note, explains that "elements are nested according to their specifications" does not mean what you are wishing it to mean.

don’t nest headings inside headings

Is that <h1> hello <h2> world </h2> </h1> or is there more to it? But even if HTML (living standard) prohibits <h1> hello </h1> <h3> world </h3> that would not rise to the level of fail against SC 4.1.1.

One has to read "elements" as the term was understood in 2008. Words shifting in meaning and common use does not change the requirements specified by the SC and how the SC should be understood.

I can't think how Understanding could be better written on this point. You are in position to know what Understanding might include so as to discourage the very line of reasoning you are trying to pursue..

[yatil]

Again, I do not care about the Understanding for this. I only care about the specification, about WCAG, about the normative standard. The Understanding is, for all intents and purposes irrelevant to the question of changing SC 4.1.1

Is that <h1> hello <h2> world </h2> </h1> or is there more to it? But even if HTML (living standard) prohibits <h1> hello </h1> <h3> world </h3> that would not rise to the level of fail against SC 4.1.1.

HTML (living standard) does not allow <h1> hello <h2> world </h2> </h1>. The other example has no nested elements (siblings are not their own children in DOM parlance), so the WCAG clause about nesting cannot apply, irrelevant what HTML (living standard) is saying.

One has to read "elements" as the term was understood in 2008. Words shifting in meaning and common use does not change the requirements specified by the SC and how the SC should be understood.

Correct. An element, as it was understood since HTML 3.2 or something. Look at the HTML 3.2 specification fro 1997: https://www.w3.org/TR/2018/SPSD-html32-20180315/#head

The head element consists out of the start and end tag, all of its content and attributes. This is how elements were understood and are understood since forever. Words have meanings, “elements” in its markup language has definitions.

If WCAG has a radical different understanding of what an element is, one that is not compatible with elements in markup specifications, then please bring that definition.

I can't think how Understanding could be better written on this point. You are in position to know what Understanding might include so as to discourage the very line of reasoning you are trying to pursue..

Again, again, I do not care about the Understanding. I care about the wording of the SC.

I’m happy for someone to explain to me what “nesting elements according to their specifications” means when the “elements” are “HTML elements” and “their specifications” is “the HTML specification”. Show me where in the HTML specification it allows for bad nesting.

This discussion is now going in circles. The SC does not say what WCAG WG wanted it to say, what WCAG WG apparently wants it to say makes little sense since HTML5.

Note: My mental health is suffering quite a lot under this discussion, so I’ll switch off notifications for this thread. It’s pretty clear that people who want WCAG to be the best WCAG it could be are not appreciated. That’s fine, but it is a torture I can only endure for so many hours…

[scottaohara]

Is that <h1> hello <h2> world </h2> </h1> or is there more to it? But even if HTML (living standard) prohibits <h1> hello </h1> <h3> world </h3> that would not rise to the level of fail against SC 4.1.1.

The latter has nothing to do with this conversation. "nesting" refers to the former as that is invalid HTML. The introduction of can heading levels be skipped and using the term "nested" to refer to that has taken this entire conversation down a complete side tangent that keeps being used as an example for why 4.1.1 doesn't apply to what people think it means.

Let's just clear the thread here and specifically call out that

<h2>red</h2>
<h5>herring</h5>

is not what should be discussed in context to 4.1.1 at all.

but

<h1>
  <h2>invalid nesting that creates nonsensical markup</h2>
</h1>

and

<button>
  <h2>also invalid nesting which is problematic for AT</h2>
</button>

and

<button>
  <a href=...>also invalid nesting that is also problematic</a>
</button>

THAT is what "nested according to specification" is being argued as being easily inferred from the current normative wording. Inconsistent and awkward a11y trees ARE created per the above examples. I can create a bunch more, if this conversation continues to get side tracked into irrelevancy.

[cstrobbe]

yatil wrote on 25 September

In the inverse, arguing that some XML rules are meant when that is not part of the success criterion makes the interpretation technology-specific. Of course, you can argue that HTML (living standard) is not meant to be a markup language according to WCAG. Which makes the SC non-applicable to HTML (living standard) documents.

The argument is not that XML rules must be applied to HTML as XML rules, but that the four requirements in SC 4.1.1 must be applied to HTML, which is a markup language. The Understanding document says, “The concept of "well formed" is close to what is required here.”, not that it is identical with well-formedness.

yatil wrote on 3 November

Again, where is that interpretation in WCAG? “elements are nested according to their specifications”. The HTML specification says “it is not allowed to nest an h4 in an h2”.

Do words in WCAG have any meaning?

Nobody is claiming that requirements in WCAG or in the HTML specification have no meaning.

The proposal I submitted on 22 June attempts to bring the wording of SC 4.1.1 in line with the originally intended meaning. That originally intended meaning was not to require validation of content models but to ensure correct syntax, so user agents and AT can build an unambiguous parse tree.

The proposal does not imply that validation has no value.

yatil added in the same comment,

I’m happy for the WG to change 4.1.1 to match the intent (tho it would not improve accessibility at all, compared to actually following HTML which DOES improve accessibility) or get rid of it entirely. If the words of the SC does not match what testers are supposed to test and implementers are supposed to implement, the SC is super useless and distracting.

Nobody has claimed that using HTML according to specification has no benefits for accessibility; that is not what this issue is about.

The meaning of the SC is not defined by what some unidentified testers do, especially if those testers disagree with the people who actually wrote that success criterion.

Whereas following markup specifications is beneficial, some people have complained that requiring validation causes a lot of busy work that has no benefits for accessibility because not every validation error has an impact on accessibility. (This argument probably dates by to WCAG 1.0, which actually required validation.)

It is somewhat strange that some people insist on the validation of content models, while at the same time arguing for its deletion:

(Alternatively: Remove 4.1.1, it's probably beyond its usefulness. See #2676)

So, as long as SC 4.1.1 exists, it should cause as much useless busy work as possible?

yatil wrote on 4 November

Again, I don’t care about the Understanding. It cannot change the words and meaning of the SC and WCAG would be easier to teach, understand, and use, if we wouldn’t say “oh yes, we wrote x in the SC, but if you look at the Understanding, you see that we actually meant seventeen other different things”. It’s fairly ridiculous at this point.

The Understanding document may not be normative, but it is authoritative, whereas the opinion of unidentified “people” (Scott O'Hara: “use 4.1.1 for what people think it's for”) is not.

Since yatil has repeatedly insisted that “elements are nested according to their specifications” is not just about syntax because that is not in the normative text, I would like to point out the following:

• Interpreting “elements are nested according to their specifications” as referring to the validation of content models implies much more stricter rules for element nesting than for attribute syntax. This interpretation creates an inconsistency inside the success criterion. (If that were intended, why doesn't the Understanding document point that out?) Interpreting “elements are nested according to their specifications” as referring to syntax avoids this inconsistency in the normative text.
• Interpreting “elements are nested according to their specifications” as referring to syntax makes the success criterion and the Understanding document consistent with each other. If validation were intended, the Understanding document would have pointed out that “elements are nested according to their specifications” goes beyond the concept of well-formedness.
• Interpreting “elements are nested according to their specifications” as referring to syntax makes the success criterion text consistent with its short name, i.e. Parsing.

yatil wrote on 4 November

Because if we don’t learn from the mistakes, we are to repeat them again. This would be a disservice to billions of people with disabilities that we fail because we are taking up resources with understanding WCAG instead of people actually fixing things. It’s a tragedy.

The web could be so much more, so much better, if we would push WCAG forward instead of relying on and fighting for interpretations in the past and hiding them in Understanding documents. The lack of ambition and defense of the status quo is unfortunate.

This comment implies that people like Gregg Vanderheiden and myself, by taking part in this discussion, are taking up resources instead of trying to make the web better. That really makes me wonder what I have been doing the last 21 years. And Gregg Vanderheiden has been contributing to accessibility for much longer.

It also implies that this proposal exists in isolation, merely trying to take somehting away from WCAG without attempting to fix gaps. My proposal for a New SC (4.1.4?): Native Child-Element Roles is an attempt to put something in place that is more helpful for accessibility than the simplistic validation sledge hammer. But Eric Eggert has resisted that suggestion as well.

[scottaohara]

@cstrobbe referring to my comment as referencing “unidentified” people, seems to be imply I’m trying to make something up here and, ignores that there are people in this thread who have expressed that they thought nesting according to specification referred to the content model.

I can provide more names of people if that would actually be useful. But I do not think that was the intent of why you said that.

[yatil]

@cstrobbe I work with and teach hundreds of people every year. If I put the wording of the SC before them, and ask them “what does that mean”, nobody would interpret it the way you do it. It is just not clear from the SC. Unfortunately, I am unable to name every one of my students, so yes, they remain unidentified. I didn’t know this was a numbers game.

This comment implies that people like Gregg Vanderheiden and myself, by taking part in this discussion, are taking up resources instead of trying to make the web better. That really makes me wonder what I have been doing the last 21 years. And Gregg Vanderheiden has been contributing to accessibility for much longer.

I just said there are more important things than clinging to a many years ago interpretation that is irrelevant in the 2022 web. The only thing I want is that the SC is as clear as possible. And yes, if clarity is avoided, that has an adverse influence on the web, because it eats up explanation time. This is a real impact that cannot be denied.

I am also flabbergasted that it is apparently impossible to grasp that there are two outcomes of this discussion:

1. Consensus becomes that this is mostly about well-formedness → my opinion is that this is not useful and 4.1.1 could probably be safely depreciated.
2. Consensus becomes that this is about nesting as to the specification actually used → 4.1.1 stays relevant and should be improved.

I really don’t care what it is. I want the WCAG WG to decide and then bring their spec language and documentation in order. Peace out.

Note: I am also wondering if there are two people of me, considering I’m sometimes referred to as “yatil” and once as “Eric Eggert”, but as far as I know it’s just me.

[GreggVan]

Hi Eric

I see your point that others read it as you do.
However - it does not matter how many people would read the SC the way you want to read it. It is a standard and it means what the working group at the time meant it to mean.

• it does not matter what someone wants it to mean
• it does not matter what someone thinks it says
• it does not matter what some people in the old working group wanted it to mean
• it does not even matter what the working group today thinks it should have said (unless of course they decide to change it — in which case it will still mean what it meant for past standards - and will mean what they change it to going forward for future revisions of the standard.

The bottom line is - It only means what the working group meant it to mean when the wrote and reached consensus on it.

In this case - it only applied to the syntax and not semantics and is restricted only to PARSING problems — which is why it is named Parsing.

If, as you say, the web has changed and the SC should mean something different now — that is fine. You can propose that the SC be changed for future versions of the standard. And the working group can decide to change it or not change it.

It is not fair or appropriate to say that the working group is ignoring you - if they do not agree with you. If you do not think the WG noticed a comment or suggestion you filed - then you can ping the chairs and ask.

But you can’t ask the working group to change the original meaning of the SC because you think it is worded such that you can interpret it otherwise. It means what it was intended to mean - and the Understanding WCAG 2.0 document was created at the same time as the standard to clear up any ambiguities in reading of the original

You made the point that the understanding document is not normative. The is correct - the understanding document is not normative - but, like legislative record and laws, the role of the understanding document is to make it clear what the intent of the standard is - if not clear from the language. This is one reason why we can’t use the understanding document to 're-interpret' the standard to be different than what the understanding document at the time had said. All changes must be for clarification - not changing interpretation. And in this case the understanding document reinforces the interpretation that working group members at the time have shared with you.

I think enough people have now said this that I hope to not be commenting on this anymore. I know you are unhappy. I know that you think it should mean something else the way it is written. But it doesnt. And you should know that all of the people who have commented on this - have provisions they don’t like or think should be different or think should be interpreted differently etc. Bruce said he himself wanted this one to be different. I was a chair - and lots of things didnt go the way I would have liked them to go. But we don’t get what we want. Or what WE think is right. We get and have to live with what the group was able to reach consensus on - as documented in the Guidelines and Understanding document (again - unless and until the working group changes the SC or creates another in a later version of the standard).

All the best

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 Nov 5, 2022, at 11:24 AM, Eric Eggert @.***> wrote:

@cstrobbe https://github.com/cstrobbe I work with and teach hundreds of people every year. If I put the wording of the SC before them, and ask them “what does that mean”, nobody would interpret it the way you do it. It is just not clear from the SC. Unfortunately, I am unable to name every one of my students, so yes, they remain unidentified. I didn’t know this was a numbers game.

This comment implies that people like Gregg Vanderheiden and myself, by taking part in this discussion, are taking up resources instead of trying to make the web better. That really makes me wonder what I have been doing the last 21 years. And Gregg Vanderheiden has been contributing to accessibility for much longer.

I just said there are more important things than clinging to a many years ago interpretation that is irrelevant in the 2022 web. The only thing I want is that the SC is as clear as possible. And yes, if clarity is avoided, that has an adverse influence on the web, because it eats up explanation time. This is a real impact that cannot be denied.

I am also flabbergasted that it is apparently impossible to grasp that there are two outcomes of this discussion:

Consensus becomes that this is mostly about well-formedness → my opinion is that this is not useful and 4.1.1 could probably be safely depreciated. Consensus becomes that this is about nesting as to the specification actually used → 4.1.1 stays relevant and should be improved. I really don’t care what it is. I want the WCAG WG to decide and then bring their spec language and documentation in order. Peace out.

Note: I am also wondering if there are two people of me, considering I’m sometimes referred to as “yatil” and once as “Eric Eggert”, but as far as I know it’s just me.

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1304605964, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXRRBLRL5Q7MDUCJIRTWG2Q5VANCNFSM5ZRXNZ6A. You are receiving this because you were mentioned.

[JAWS-test]

The discussion here and elsewhere indicates that there is an urgent need to clearly state the intent of 4.1.1 so that all who work with it have the same understanding. Unfortunately, this is not the case at present. Therefore, the SC or the Understanding should definitely be adapted.

[alastc]

Hi everyone,

I'm on the edge of locking this thread as overheated: Please keep discussion focused on the ideas, not the people.

On the substance, the thing I'm trying to square is "elements are nested according to their specifications" with the two interpretations outlined:

• Syntactical: Can parse a programmatic view of the elements.
• Content model: The descriptions of what each element may contain.

I don't spend much time digging into HTML specs, but when WCAG 2.0 was written I think HTML4.01 was the main standard for HTML. That did include DTD type information (and conformed to the ISO for SGML), which was dropped later by HTML5 & the later 'living standard'.

What I can't work out is why "nested according to specification" doesn't include the content model, is there something in how the HTML spec is/was written that separated that out?

[patrickhlauke]

What I can't work out is why "nested according to specification" doesn't include the content model, is there something in how the HTML spec is/was written that separated that out?

This has probably been mentioned before somewhere in this thread, but my understanding has always been: back in HTML 4.x days, there was no consistent error handling when you misnested things (a la <b><i>foo</b></i>), which could then lead to different user agents (including AT) interpreting the markup (read: creating their DOM) in a completely different and incompatible way. To avoid this aspect, the SC leant towards a "well formed" requirement (rather than a "must be valid" like in the old WCAG 1.0 days, which threw up too many false positives/negatives where even something silly like an unescaped ampersand was immediately a FAIL).

Fast forward to HTML 5, which now has an authoritative, documented error correction and handling algorithm, which - for compliant user agents - means that even broken/incorrectly nested markup will be interpreted in exactly the same way and lead to the same DOM in user agents.

[alastc]

Yep, I get that changed, but in terms of the original terminology and meaning, was there anything about the HTML spec(s) which meant that the content model wasn't considered 'according to spec'?

[GreggVan]

On Nov 7, 2022, at 11:57 AM, Alastair Campbell @.***> wrote:

Yep, I get that changed, but in terms of the original terminology and meaning, was there anything about the HTML spec(s) which meant that the content model wasn't considered 'according to spec'?

Not sure I understand the question correctly but

Conformance with the full HMTL spec was considered and the working group decided that requiring conformance to HTML was not within scope for the Working Group - unless specific impact on people with disabilities could be shown that was not true for all users. (I.e. We were told that WCAG was restricted to accessibility and should not stray into usability that everyone experienced.)

After much effort and discussion it was felt that (as Patrick L mentioned - and pasted here) - bad nesting of the start and end tags (Syntax) could break AT Patrick L wrote: "This has probably been mentioned before somewhere in this thread, but my understanding has always been: back in HTML 4.x days, there was no consistent error handling when you misnested things (a la foo), which could then lead to different user agents (including AT) interpreting the markup (read: creating their DOM) in a completely different and incompatible way. To avoid this aspect, the SC leant towards a "well formed" requirement (rather than a "must be valid" like in the old WCAG 1.0 days, which threw up too many false positives/negatives where even something silly like an unescaped ampersand was immediately a FAIL)"

The decision was then made to include this only - in WCAG. It dealt only with PARSING. Hence the name of the SC is "Parsing" and the language in the understand (was meant to) make it clear that it only applied to syntax aspects of the Specification and not the semantic.

This was a very long discussion over a very long time. The SC as written (which was PARSING only) was what the Working group finally agreed on. It was unfortunate that the group used "elements" to refer to the start and end tags since it is often also used today to refer to both as being parts of an element. And the confusion spread from there.

I think the best thing we can do is 1) fix the language in the Understanding WCAG 2.x document to reflect the original meaning of the SC (and maybe a note in the SC?) 2) have the Working Group re-consider this for future guidelines to see if the WG comes to the same conclusion as the original WG or comes to another conclusion and a revised SC (or equivalent)

If you would like more information on the original meaning some people from back then you could talk to are

• Gregg Vanderheiden (Co-Chair and editor)
• Christophe Strobbe (very active and known for careful scrutiny of provisions
• Ben Caldwell (close to full time as editor - and maintained the document so was very familiar with every change)
• David MacDonald (also very conscientious - and advocate for people with disabilities - including low vision/blindness. There are others but I know these were all active and very attentive and attended meetings throughout this period

Hope this helps

PS All this emphasizes the importance of having really good language in the Understanding WCAG document for each SC — for future team members to understand exactly what was meant by each SC as it is created.

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

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1306114769, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXSHK54JHJZU5E5PHRTWHFNMPANCNFSM5ZRXNZ6A. You are receiving this because you were mentioned.

[scottaohara]

I guess that's some of the issue here though, is that while there were changes between the versions and the HTML parser is better now at taking bad markup and rendering a page that doesn't fall down on itself, there still remain issues with the way the a11y tree is constructed if markup is not written / nested according to the specification. Browsers may either revise that content into something sensical they can render, but that may result in awkward patterns that impact everyone - e.g., a hr within a table or a paragraph in a paragraph being corrected into a markup pattern that the browser can render and renders the same for all users. Or there can be content nested within elements where the parser specifically doesn't correct it, but it results in an accessibility tree that may not expose all the data, or not expose it in a way that AT expects to interpret it.

So per:

It dealt only with PARSING.

That's what both sides of this back and forth have been discussing. But maybe there lies another issue of not only is "nested according to specification" mean something different to those reading it, but "parsing" also has different meanings?

[alastc]

Thanks @GreggVan and @patrickhlauke, I do understand the intent. What I'm struggling with is how the original text was intended to convey that it was focused on the syntactical aspect. (Prompting @cstrobbe to create the issue.)

If you read "elements are nested according to their specifications", and then look at the HTML spec, why would you think that excludes the content model?

Was there something in how the earlier HTML specs were written that made that more obvious?

Either way, with modern terminology we know various people are interpreting that in a way that goes beyond the original intent. (See my first comment, or @JAWS-test's comment about the German report.)

In which case it would seem an errata is warranted, the minimal version of which would be the "elements are nested according to the syntactical rules of their specifications" part of the proposal. (And updates to the understanding doc.)

However, given that intent, I think that removes some (all?) of the objections to deprecating 4.1.1 overall. For example, I don't think @mraccess77's examples fail according to this thread.

Do other's concur?

We hadn't got to consensus on deprecating 4.1.1 because it was thought some things would be caught by 4.1.1 that are not caught by 1.3.1/4.1.2, but have we just removed that impediment?

[bruce-usab]

If you read "elements are nested according to their specifications", and then look at the HTML spec, why would you think that excludes the content model?

I am not sure what you mean by "content model" exactly, but DOM was not really a thing in 2008 as screen reading software created its own content model while the browsers did their own.

The line about "elements are nested according to their specifications" was aimed at source code which could be expected to be problematic or even unpredictable. It was not aimed an element just because the validator threw an error.

At the time, I don't think people would have failed cruft like <h1> hello <h2> world </h2> </h1> against 4.1.1 because it is not really problematic in the way that having elements which belonged in head be in body (or vice versa),

Browsers were expected to be fault tolerate with source code, and new elements terminated open elements, so my example rather unambiguously resolves to <h1> hello </h1> <h2> world </h2> (and the trailing </h1> ignored).

[GreggVan]

I do think that 4.1.1. could be deprecated at this point. The problem it was designed to solve is no longer

Trying to deprecate it might stir something up of done now that CR is out. But if you do another CR loop - it could go I think.

People who misread it though would wonder why it was deprecated. It only makes sense to deprecate if it is understood.

But I agree - deprecate - or add explanatory text though that seems to be hard to do….

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 Nov 7, 2022, at 2:52 PM, Alastair Campbell @.***> wrote:

Thanks @GreggVan https://github.com/GreggVan and @patrickhlauke https://github.com/patrickhlauke, I do understand the intent. What I'm struggling with is how the original text was intended to convey that it was focused on the syntactical aspect. (Prompting @cstrobbe https://github.com/cstrobbe to create the issue.)

If you read "elements are nested according to their specifications", and then look at the HTML spec, why would you think that excludes the content model?

Was there something in how the earlier HTML specs were written that made that more obvious?

Either way, with modern terminology we know various people are interpreting that in a way that goes beyond the original intent. (See my first comment, or @JAWS-test https://github.com/JAWS-test's comment about the German report.)

In which case it would seem an errata is warranted, the minimal version of which would be the "elements are nested according to the syntactical rules of their specifications" part of the proposal. (And updates to the understanding doc.)

However, given that intent, I think that removes some (all?) of the objections to deprecating 4.1.1 overall. For example, I don't think @mraccess77 https://github.com/mraccess77's examples https://github.com/w3c/wcag/issues/770#issuecomment-501088439 fail according to this thread.

Do other's concur?

We hadn't got to consensus on deprecating 4.1.1 because it was thought some things would be caught by 4.1.1 that are not caught by 1.3.1/4.1.2, but have we just removed that impediment?

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1306333344, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXV3V2U7CRJGIFSHCYTWHGB2VANCNFSM5ZRXNZ6A. You are receiving this because you were mentioned.

[scottaohara]

@bruce-usab Content model is a concept that has been around in HTML for multiple versions, even prior to 4.0.1. It's purpose was to define the allowed elements that could be nested inside of other elements.

And while the HTML parser does some DOM manipulation to correct the example you have referred to, it does not do the same to correct the following examples:

<ul>
  <h2>foo</h2>
  <li>stuff n' things</li>
</ul>

<!-- or -->
<button><h2>also invalid</h2></button>

or any of the examples mentioned by @mraccess77's https://github.com/w3c/wcag/issues/770#issuecomment-501088439

The line about "elements are nested according to their specifications" was aimed at source code which could be expected to be problematic or even unpredictable.

Again, this is exactly why people have been understanding that 'nested according to specification' means the above examples, because these do cause problematic if not potentially unpredictable outcomes.

But if the wg really has no appetite to make the SC match how people are interpreting it, then yes, please. Just deprecate it. I don't personally see the usefulness in creating a new SC to cover the cases that people are already misunderstanding 4.1.1 to mean though. Either meet people where they already are, or provide understanding docs / techniques about how the issues thought to fall under 4.1.1 actually fall under other existing SCs like 1.3.1 and 4.1.2 - as those have been cited in these discussions on where such issues should have instead been flagged.

[cstrobbe]

What I can't work out is why "nested according to specification" doesn't include the content model, is there something in how the HTML spec is/was written that separated that out?

No, this is unrelated to changes in HTML. My proposal is to reword SC 4.1.1 so it reflects its intended meaning, i.e. the meaning that the working group intended when it wrote WCAG 2.0.

As mentioned before, the intended meaning was nested according to the syntactical rules of the corresponding specification, not the validation of content models.

Whether the start and end tags of element are missing a critical character ("such as a closing angle bracket or a mismatched attribute value quotation mark") is something you can check without reference to a content model; it is a mere syntax check.

"Elements do not contain duplicate attributes" is something you can check without consulting a DTD or similar specification, regardless whether the markup language in question is XML-based (XHTML 1.x, SVG, MathML, ...), SGML-based (HTML 4.01) or merely "SGML-like" (W3C HTML5 and WHATWG HTML). Contrast this with checking whether a specific attribute is allowed on a specific element, or whether an attribute has an allowed value: these would not be syntax checks but require that you consult the definition of the affected elements and attributes, respectively.

Similarly, "elements are nested according to their specifications" was intended as a mere syntax requirement. Requiring the validation of content models would enforce stricter rules for elements than for attributes. And it would require this in spite of the fact that the working group could not reach consensus on requiring validation. (As David MacDonald once wrote, "There was almost WW3 over validation (...).")

The difficulty has always been that checking the correct syntactic nesting of elements has always been easier for XML-based languages than for other markup languages. XML has non-validating parsers, whereas other markup languages don't. (XML parsers are even required to stop parsing when they encounter a violation of a well-formedness constraint.) Both HTML 4.01 and WHATWG HTML (and W3C HTML5) allow optional end tags (and even optional start and end tags for certain elements), and that is why a parser needs to know each individual element's tag omission rules in order to know whether elements are correctly nested, even if the intent is just a syntax check. (Even though WHATWG HTML is not based on SGML, its tag omission concept is evidently borrowed from it. So it doesn't come as a complete surprise that at least one person has created an SGML DTD for W3C HTML5.)

The closest thing to a tool that can check correct syntax for WHATWG HTML without performing full validation is the Nu Validator's Parse Tree Dump. (Enter a URL in the first field, press "Print Tree" and check that there are no errors at the bottom of the document.) This includes checking for duplicate IDs, so I think it shows that such a tool for checking conformance of WHAT WG HTML to SC 4.1.1 can be built.

In summary, WHATWG HTML presents the same type of challenge as HTML 4.01 did. What has changed is that WHATWG HTML has more error handling rules than HTML 4.01 did. It is a good thing that the error handling rules eliminate a number of syntax issues, but I fail to see how that would be an argument for or against reading "elements are nested according to their specifications" as a validation requirement.

(Sidenote: while doing research for SC 4.1.1 in 2005, I found that not all markup languages defined by the W3C required valid code. I think Detlev Fischer did a recheck on this a few years later but I can't find that post in the wai-gl archives right now.)

What I'm struggling with is how the original text was intended to convey that it was focused on the syntactical aspect. (Prompting @cstrobbe to create the issue.)

Well, that is what the current issue attempted to do by proposing the wording "elements are nested according to the syntactical rules of their specifications".

If you read "elements are nested according to their specifications", and then look at the HTML spec, why would you think that excludes the content model?

Was there something in how the earlier HTML specs were written that made that more obvious?

It is quite clear that the current wording can be interpreted as requiring validation. The point of this issue is not to deny that this interpretation exists or even that it is plausible when ignoring the Understanding document. What I am trying to address with this issue is to make the wording of the SC consistent with the originally intended meaning.

This issue did not come into being because HTML 4.01 was succeeded and superseded by W3C HTML5 and WHATWG HTML; it has existed as long as the SC itself.

(...) In which case it would seem an errata is warranted, the minimal version of which would be the "elements are nested according to the syntactical rules of their specifications" part of the proposal. (And updates to the understanding doc.)

That would be excellent and I volunteer to propose updates to the understanding document. (I will work with other people before posting a proposal.)

We hadn't got to consensus on deprecating 4.1.1 because it was thought some things would be caught by 4.1.1 that are not caught by 1.3.1/4.1.2, but have we just removed that impediment?

The issue New SC (4.1.4?): Native Child-Element Roles contains a whole slew of examples that might not all get caught by SC 1.3.1 or SC 4.1.2, but that is a discussion for a separate thread.

With regard to deprecating SC 4.1.1 because of WHATWG HTML's error handling rules: this seems to imply that WHATWG HTML is the only markup language that counts on the web, whereas WCAG 2.x is meant to be technology-agnostic. The argument has been made that "we will use WCAG 2 for at least another 10 to 15 years". Do we know what markup languages will come along in these years? Will they all have the same error handling rules?

(

Content model is a concept that has been around in HTML for multiple versions, even prior to 4.0.1.

As far as I know, the term "content model" is at least as old as SGML, which became an ISO standard in 1986 and predates HTML.

)

[bruce-usab]

Thank you @cstrobbe for that excellent summary and background!

Similarly, "elements are nested according to their specifications" was intended as a mere syntax requirement.

+1 to this, and to the other context you provide as to why that bit is not requirement for validation. Validation was 1.0 checkpoint, and was not carried forward in that form to 2.0. If 4.1.1 was meant to include validations, it would use far fewer words!

I want to mention another term of art I was struggling to recall is "off screen model" which came from the screen reader developers, and predates web browsers and so was larger frame of reference than the DOM.

But if the wg really has no appetite to make the SC match how people are interpreting it...

@scottaohara – The meaning of an SC doesn't change because some people are reading it wrong. I am not excusing inartful phrasing, but there are a few SC, including 4.1.1, where well-meaning SME read more into the text than what is literally there.

I don't personally see the usefulness in creating a new SC to cover the cases that people are already misunderstanding 4.1.1 to mean though.

A new SC is the way to add a new requirement or close a gap. Well intended folks read into 4.1.1 to help improve accessibility. But if the meaning of a standard changes over time, that undermines the standard.

[alastc]

I think the nub of the misunderstanding is here:

Similarly, "elements are nested according to their specifications" was intended as a mere syntax requirement.

If I look at the spec and it says "X element can only contain Y & Z elements", that matches the meaning of the SC as written. I have a lot of sympathy with Eric's comments above.

Requiring the validation of content models would enforce stricter rules for elements than for attributes. And it would require this in spite of the fact that the working group could not reach consensus on requiring validation.

As validation goes beyond nesting, this is a compatible view with including the content model as part of the nesting check. Certainly I'd test 4.1.1 and ignore many things that are part of validation (e.g. by the W3C's HTML validator).

My question about the HTML specs was me stretching for a reason that the original SC didn't include the term 'syntactical', but you've eliminated that :-)

With regard to deprecating SC 4.1.1 because of WHATWG HTML's error handling rules: this seems to imply that WHATWG HTML is the only markup language that counts on the web, whereas WCAG 2.x is meant to be technology-agnostic.

For another (incompatible) markup language to take off and become a mainstream concern would take a while. We could probably add your 4.1.4 on that timescale!

The argument for me is whether 4.1.1 is doing more harm (busy work) than good (preventing real issues). I'm leaning towards the former.

[scottaohara]

where well-meaning SME read more into the text than what is literally there.

Agreed in some instances, but again that's the problem with this particular SC. What's "literally there" in the normative text is exactly why people are interpreting it wrong. But, I will not repeat this any further.

But if the meaning of a standard changes over time, that undermines the standard.

I don't think I can agree with you on that statement as it is too broad and doesn't account for the fact that aspects of standards can and do have their meanings adjusted, if not at least properly clarified to mitigate confusion, over time.

The argument for me is whether 4.1.1 is doing more harm (busy work) than good (preventing real issues). I'm leaning towards the former.

I agree with Alastair here. If the SC cannot be changed to match people's misunderstandings, and clarifying would result in pointing out that what people have been logging as errors are not actually covered by the SC. But rather as Gregg said, what it was meant to account for is no longer an issue, then deprecation seems the best course of action.

[bruce-usab]

I don't think I can agree with you on that statement as it is too broad and doesn't account for the fact that aspects of standards can and do have their meanings adjusted, if not at least properly clarified to mitigate confusion, over time.

My personal experience is that "meaning adjusted" is more about the technology changing in rather fundamental ways. (Much more than the change from 3.2 to living standard.) As an example of technology requirements which demanded interpretation, and increasing more so as the years went by, I offer for comparison the year 2000 Original 508 Standards.

[mraccess77]

I'm trying to understand the "nested to the specification" clause that is being discussed. What I'm perceiving is being discussed is that there is a difference in the ML syntax nesting and the HTML content model nest requirements. That is something like a button within a link is allowed from a syntactical perspective but not a content model perspective and thus it would not fail the criteria because the criteria was only aimed the syntax of ML (or whatever it is) based languages? Is this what is being explained? If so - I don't think that was communicated in the criteria to 99% of the world including most of the people on the accessiblity guidelines working group.

[cstrobbe]

As validation goes beyond nesting, this is a compatible view with including the content model as part of the nesting check. Certainly I'd test 4.1.1 and ignore many things that are part of validation (e.g. by the W3C's HTML validator).

From the point of view that "elements are nested according to their specifications" refers to syntax, this creates more work than the SC requires. At the same time, the statement doesn't read like a vote in favour of that interpretation. From the point of view that " elements are nested according to their specifications" refers to validation, it omits violations of the SC. At the same time, the statement doesn't read like a vote in favour of clarifying that the SC is about syntax. Based on this, I don't know what next step is being suggested.

But rather as Gregg said, what it was meant to account for is no longer an issue, then deprecation seems the best course of action.

Deprecation in the WCAG 2.2 / 2.x?

[scottaohara]

If my vote was to count for anything, it'd absolutely be deprecated in 2.2. I understand the potential implications of doing that during CR. But, having it stick around even longer doesn't seem a much sweeter pill. shrug...

[ericwbailey]

Seems to me that rephrasing may beneficial if you've had ~20 years of the majority of folks—including the people who help work on WCAG themselves—misinterpreting the SC.

[stevefaulkner]

FWIW I would like to see 4.1.1 clarified, but I would not like to see the nesting of interactive elements according to specification aspect go away. This is one of the truly problematic accessibility failures that 4.1.1 catches.

On Tuesday, 8 November 2022, scottaohara @.***> wrote:

If my vote was to count for anything, it'd absolutely be deprecated in 2.2. I understand the potential implications of doing that during CR. But, having it stick around even longer doesn't seem a much sweeter pill. shrug...

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2525#issuecomment-1307813555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGMCE2Y5RKPE2GX3WA7CD3WHK4ZVANCNFSM5ZRXNZ6A . You are receiving this because you commented.Message ID: @.***>

--

Regards

Steve Faulkner Web Standards messaging one t-shirt at a time https://www.etsy.com/uk/shop/HTMLZ

[aardrian]

Long time reader, first time commenter on this thread. I see two straightforward outcomes:

1. Accept the SC as written, or
2. Deprecate.

The claimed intent is not in the language, it has been interpreted as written since 2008 without this issue being filed, 2.2 is in CR, and the industry has seen value in the language as written (as Steve notes just before me). I am in favor of option 1.

[alastc]

@mraccess77:

That is something like a button within a link is allowed from a syntactical perspective but not a content model perspective and thus it would not fail the criteria because the criteria was only aimed the syntax of ML (or whatever it is) based languages? Is this what is being explained? If so - I don't think that was communicated in the criteria to 99% of the world including most of the people on the accessibility guidelines working group.

That's a pretty good summary, yes. Talking to someone in a large accessibility team, they knew the intent but constantly struggled to get the rest of the team to understand that aspect.

@stevefaulkner:

I would like to see 4.1.1 clarified, but I would not like to see the nesting of interactive elements according to specification aspect go away.

That is the wider content-model meaning, so if the SC text were clarified (to the original intent) that would go away.

I think there are 3 options:

1. Adjust the SC text (probably in an errata) to make it "syntactical" only.
2. Deprecate the SC.
3. Adjust the understanding document to clarify that it does include the content-model.

All have problems:

1. Will confuse all the people who've been testing the content model as well.
2. Has a backwards compatibility problem if some things are caught by 4.1.1 that are not caught by 1.3.1 / 4.1.2.
3. Will widen the SC for those people who have been testing syntactical only.

Whilst most people reading it probably take the wider interpretation, I think the tool makers have generally stuck to syntactical.

I'm sceptical that option 3 would be approved, it goes against the original intent.

Personally, I'd favour deprecation as 4.1.1 creates a lot of non-beneficial busy work.

I'd like to survey this soon, if anyone has new/different arguments for one of the above options (or thinks another option is important), please say.

[Jym77]

I'd like to survey this soon, if anyone has new/different arguments for one of the above options (or thinks another option is important), please say.

Would it be an option to

4. Adjust 4.1.1 to make it "syntactical" only + add a new SC for content model and validation?

new SC could be at a lower level (AA or even AAA if it does not create that many problems per se). That could allow both "semantics" people to keep being semantics (just ventilating results over 2 SCs) and "syntactical" people would still need to widen their testing but in a new niche rather than the existing one.

---

There is also a possible tweak on solution 2 to keep 4.1.1 but lower its level. That would acknowledge that it still causes problems, but rarely does so.

[alastc]

Would it be an option to

4. Adjust 4.1.1 to make it "syntactical" only + add a new SC for content model and validation?

Not for WCAG 2.2, but @cstrobbe outlined a potential new SC that would be a replacement in future.

[JAWS-test]

• add a new SC for content model and validation?

See https://github.com/w3c/wcag/issues/2649

[bruce-usab]

... if some things are caught by 4.1.1 that are not caught by 1.3.1 / 4.1.2.

I do not know of any such things, but I though @stevefaulkner or @mraccess77 had a few?

[cstrobbe]

With regard to deprecating SC 4.1.1 because of WHATWG HTML's error handling rules: this seems to imply that WHATWG HTML is the only markup language that counts on the web, whereas WCAG 2.x is meant to be technology-agnostic.

For another (incompatible) markup language to take off and become a mainstream concern would take a while. We could probably add your 4.1.4 on that timescale!

That is not what it takes for SC 4.1.1 to remain relevant. It only takes a new type of user agent (somewhat different from the browsers we're using today) implementing a markup language other than HTML and fetching content over HTTPS. If this new technology reached a market share of e.g. 10 percent in just the "developed world", that would still represent many millions of users, including many with a disability. Within the suggested time frame in which WCAG 2.x may continue to be used (possibly "at least another 10 to 15 years"), that does not seem beyond the realm of plausibility.

In addition, we haven't really verified whether the other success criteria cover all the issues that the error handling defined in HTML5 does not catch when SC 4.1.1 is deprecated. If I get around to checking that in the next few days or weeks, I will report back here.

[alastc]

It only takes a new type of user agent ... implementing a markup language other than HTML and ... reached a market share of e.g. 10 percent

That is true, but I think very unlikely. We already have HTML, PDF, canvas. The thing that was supposed to replace HTML (XHTML) was essentially rejected. The motivation and resources required to popularise something like HTML (but not HTML) would be massive, it would need some 'killer app' or feature that couldn't be done in HTML.

But more to the point, it would be visible to us and take time to get to even 10%, so we could potentially add a similar but updated SC on that timescale. I think more likely is the use of HTML in new environments (e.g. VR/AR), where other SCs would be of more use.

we haven't really verified whether the other success criteria cover all the issues that the error handling defined in HTML5 does not catch when SC 4.1.1 is deprecated.

That is a concern, and leans me towards the update even though I'd like to deprecate it.

I do not know of any such things, but I though @stevefaulkner or @mraccess77 had a few?

From looking at the other thread, I think those examples are not covered by 4.1.1 (as intended), however, I can't be sure that there would not be some gap. It is then whether those gaps are worse than the false-positives that 4.1.1 generates.

[JAWS-test]

Discussion: https://www.w3.org/2022/11/15-ag-minutes.html#item03 PR: https://github.com/w3c/wcag/pull/2793/files

[alastc]

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.

[dylanb]

what is the decision on how to handle those cases where duplicate ID do cause accessibility problems https://github.com/w3c/wcag/issues/2525#issuecomment-1193125248

[alastc]

I think the comment was "Only rarely does a duplicate ID show up as a problem." I.e. come up in the report he was talking about.

Where duplicate IDs can cause issues, aren't they caught because functionality doesn't work? E.g. an aria-labelledby has the wrong accname.

I've found it's more often the case that the duplicates IDs aren't actually available (e.g. display:none), so are really false-positives.

[mraccess77]

FWIW It is my understanding that aria-labelledby and aria-describedby can reference and draw accessible name/description calc from hidden content - e.g. content that has display:none set.

[patrickhlauke]

I believe the idea is that you'd still likely catch weirdness that causes actual real-world accessibility issues due to duplicate ids as part of testing other SCs - 4.1.2 Name, Role, Value, 2.5.3 Label in Name, 1.3.1 Info and Relationships, etc.

[dylanb]

I assume you are aware that this will require exhaustive testing of all cases that might expose incorrect accNames (@mraccess77 is correct that even display:none content can get included in accName calculations) as well as exhaustive testing of all AT-browser-OS combinations that might expose AT interaction issues (interacting with the wrong element for example)

Isn't a wholesale per se banning of these (as is currently done in 4.1.1) a simpler way (it can be 100% automated) to just eliminate the entire category of issues? Why not simplify 4.1.1 to reduce it to JUST no duplicate IDs?

[bruce-usab]

@dylanb if you have cases of duplicate ID actually causing real-world accessibility problems, please do investigate!

As Patrick writes, the consensus is that such case will also be unambiguous failures against other SC.

I assume you are aware that this will require exhaustive testing of all cases that might expose incorrect accNames

A comprehensive audit will flag incorrect accNames regardless of 4.1.1 because it is a rather fundamental accessibility barrier.

a simpler way (it can be 100% automated) to just eliminate the entire category of issues? Why not simplify 4.1.1 to reduce it to JUST no duplicate IDs?

That would be terrible. I find your suggestion to be a good example that illustrates why 4.1.1 is harmful (at this point in time).

A good audit will only flag duplicate IDs as an error when there is a real-world accessibility problem. A real-world accessibility problem (caused by a duplicated ID) will map to another A/AA Success Criteria. A good audit will flag this other SC and suggest the duplicate ID as the root cause of the failure.

An automated test for duplicate ID is noisy because of all the false positives. Audits reporting phantom problems are bad for accessibility. A good audit still has to do exhaustive testing of all cases that might expose incorrect accNames but using 4.1.1 as well means more work sorting out the false positives from duplicate IDs that do not matter.

as well as exhaustive testing of all AT-browser-OS combinations that might expose AT interaction issues

No, that is not correct. The accNames calculation is unambiguous and does not require AT, let alone the multiplying combinations. There are other reasons for testing with AT, but 4.1.1 is not one of them. Flagging duplicate IDs does not help with sorting out AT-browser-OS combinations either.

If your shop (or your service) wants to publish only validated code -- that is great! Please do not characterize reporting on duplicate IDs (absent other SC) as promoting accessibly.

[alastc]

Using duplicate IDs to find issues with accnames would be a good method. Removing 4.1.1 would mean that you are not required to find duplicate IDs that may, or may not, cause issues.