Wcag: 4.1.1 Parsing - Duplicate attributes with no user impact cause a conformance failure

[dd8]

Not all attributes affect how content is presented to the user. When attributes with no effect are duplicated, there's no affect on accessibility or the on the end user, but there is a conformance failure.

For example:

a) when the duplicate attribute is not part of HTML/SVG so has no effect at all:

<div not-an-html-attribute='one' not-an-html-attribute='two' >

b) when the duplicate attribute does not affect browser rendering, browser interactions or the accessibility tree:

<meta name='generator' content='WordPress' content='Jekyll' />
<script defer defer> <!-- defer is ignored if src absent --> </script>
<a rel='nofollow' rel='nofollow'>External link</a> <!-- nofollow makes Googlebot ignore link, but has no effect on browser -->

c) when the duplicate attribute is not valid, and has no meaning, for the element it's applied to:

<div alt='Dog' alt='Cat' >

d) when the duplicated attributes specify the same value - because the browser stores exactly one value for this attribute in the DOM, and can choose either with no change in behaviour:

<img src='test.png' width='10' width='10' height='10' />
<img src='test.png' alt='Dog' alt='Dog' />

e) when the duplicated attributes specify have different values with exactly the same meaning - because the browser stores exactly one value for this attribute in the DOM, and can choose either with no change in behaviour:

<input disabled="disabled" disabled /> is same as
<input disabled="disabled" /> and
<input disabled />

Also worth noting that the HTML 5 spec describes behaviour when duplicate attributes are present - browsers must ignore duplicate attributes in HTML documents and use the first value:
https://www.w3.org/TR/html5/syntax.html#attribute-name-state

This behaviour was probably unspecified when WCAG 2.0 was written.

[alastc]

I'm fairly sure that behaviour was unspecified when WCAG 2.0 was written, but also it was common for AT to read the HTML directly as well, which led to very inconsistent results.

4.1.2 does have the get-out clause of "except where the specifications allow these features", which it could be argued is the case now.

However, do you (or anyone) know of cross-AT testing for these examples? In order to update (the understanding doc & techniques primarily) I think we'd need to convince people it really isn't a problem anymore, for which test results would be very useful.

[dd8]

We'll do some testing and publish the results. We'll probably test the following:

1) browser DOM and accessibility tree with duplicate img/alt and input/aria-label attributes in:

• IE 11
• Edge stable
• Chrome stable
• Firefox stable
• Safari stable
• Opera stable
• UC web browser
• Samsung Internet browser

2) screen reader behaviour with duplicate img/alt and input/aria-label attributes in:

• JAWS last 3 versions with IE 11, Chrome and Firefox
• NVDA stable with IE 11, Chrome and Firefox
• Narrator with Edge
• VoiceOver on macOS 10.14 with Safari
• VoiceOver on iOS 12 with Safari
• TalkBack on Android

@alastc - any other combos or attribute combinations worth doing?

but also it was common for AT to read the HTML directly as well,
which led to very inconsistent results.

A former member of the JAWS team said very old versions of JAWS had an HTML parser because until the introduction MSAA in 1997 there was no way to get at the browser DOM, and no accessibility tree, so AT had to grab the raw HTML and parse it.

I'd be surprised if any AT still parses raw HTML because it won't work with any pages using JavaScript to modify the DOM.

[alastc]

There are still cases where AT will cover for lack of browser support, e.g. Jaws and IE. That isn't quite the same thing, but perhaps @stevefaulkner is well placed to comment on this? (I.e. does any modern AT still parse HTML separately which can lead to differences in output?)

For testing, I think the key is the second group, AT on top of browsers.

[mraccess77]

In my personal opinion while it is a technical violation under SC 4.1.1 it may not have any practical impact on the user and would not fail other SC. Generally violations of SC 4.1.1 that impact the user would also fail other SC like 4.1.2 or 1.3.1. So technical conformance violation but may not impact on user.

[alastc]

@mraccess77 you probably know the history better, but I thought the point of this one was to catch technical errors that don't fall under 4.1.2/1.3.1?

I think there's a case that some (or all) of these issues could be ignored now that the HTML spec better defines the behaviors, but it would help to have some data to back that up.

[awkawk]

Building on Alastair's last point, the case to be made that these aren't failures hinges on the part where the SC reads "except where the specifications allow these features". The spec seems to accept that duplicate id's happen and describes how to handle it, but does that constitute "allowing"?

[cwadamsoforacle]

Curt Bellew (a peer of mine who participates in the Aria working group) also informs me that Aria has a specification which allows/supports duplicate ID’s.  I’d have to ask him for the details.

Regards,

Chuck

[mraccess77]

For HTML the nu validator in general gives an error for duplicate ids. Given that it's an error and not a warning I'd say it's an issue -- but perhaps some would say the validator is not correct?

[dd8]

Duplicate IDs (as opposed to duplicate attributes) are definitely still a problem

The DOM 2 and 3 specs said the behaviour is undefined when duplicate IDs are present:
https://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId
https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-getElBId

The WHATWG and DOM 4 specs do define the behaviour when duplicate IDs are present:
https://dom.spec.whatwg.org/#dom-nonelementparentnode-getelementbyid
https://www.w3.org/TR/dom/#dom-nonelementparentnode-getelementbyid

However, if you use labels referencing duplicate ids, then gibberish is read for labels in lots of browser/AT combos:
https://www.powermapper.com/tests/screen-readers/labelling/dupe-ids/

[awkawk]

@mraccess77 - yes, I'm not sure. I wonder what @stevefaulkner would say?

@dd8 - good info. I'd say that for your dupe id labelling example that is a 4.1.2 issue in that the controls do not have the right accessible names.

[patrickhlauke]

Being very picky with the normative wording for 4.1.1

[...]elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

(emphasis added on "allow"). Taking the whatwg living standard for a second:

• unless I'm misreading it, it doesn't allow multiple attributes, it defines them as an error and describes the error correction behaviour parsers should follow https://html.spec.whatwg.org/multipage/parsing.html#parse-error-duplicate-attribute
• while it doesn't define any parsing error that i can see, the spec itself does refer to id as a unique identifier https://html.spec.whatwg.org/multipage/dom.html#global-attributes - what is described in the WHATWG/DOM4 specs for getElementById is arguably error-correction code, and not an indication that having multiple non-unique ids is allowed

While in the real world, for user agents that implement the error correction behaviour which is now defined in the spec, any failures would happen consistently and therefore be noticeable (compared to validation errors back in the days before HTML5, where each browser/UA potentially parsed broken HTML differently, leading to possible unforeseen errors in some UAs that authors may not have tested at the time), the strict reading of the normative wording still applies I'd say. So broken markup that reuses the same id on different elements, or has duplicate/multiple same attributes would still nominally fail (but it's what i generally call a "soft" fail, if it's something that is error corrected consistently nowadays). And yes, this would generally also result in failures of other SCs like 4.1.2 (unless the user happens to be using an older browser or custom UA, which does not do the suggested error correction, which THEN may mask a failure of 4.1.2, or behave in a way where only in that UA there is a 4.1.2 failure, or similar).

Long story short: I'd still flag those as failures, as otherwise we may need to change the normative wording of SC 4.1.1

[cwadamsoforacle]

Oracle's takes the position that 'invalid HTML' will not necessarily be corrected if it's reported by an automated tool but has no negative ramifications on accessibility.

[nitedog]

After related discussion about what constitutes an accessibility barrier vs a WCAG conformance failure, the auto-WCAG Community Group took the literal interpretation outlined by @patrickhlauke in his comment from 6 February for its ACT Rule 'attributes are not duplicated'. I recall it was a borderline decision with some arguing against this rule. Clarification from AGWG would be helpful.

Note: there is another ACT Rule 'ID attribute is not duplicated' but other aspects of SC 4.1.1 (eg. complete start and end tags) were intentionally left out because they generally do not constitute accessibility barriers (anymore).

[alastc]

I think the question we are struggling with is: Given the improved HTML specs and handling by browsers, is this still an accessibility issue? I.e. Does anyone know of examples where these impact AT more than anyone else?

I can't think of an instance from our audits where something fails this _and_ impacts accessibility without also failing 1.3.1 / 4.1.2.

[patrickhlauke]

@alastc agree. IF we're able to make normative changes, then my vote would be to ditch 4.1.1 unless there's clear indication that there are particular situations where invalid markup brings up issues. the only one i can think of at this stage are scenarios of older browsers/user agents which DON'T follow the spec's now clarified error correction algorithm

[zcorpan]

https://html.spec.whatwg.org/multipage/introduction.html#syntax-errors has a discussion about the impact of different syntax error cases. None of these mention accessibility directly, but some might still have an impact on accessibility.

[nitedog]

I think duplicate IDs may still be an accessibility issue? If so, then dropping the entire SC may be going a bit too far.

[awkawk]

@nitedog @zcorpan The big question for me if whether there are errors that aren't covered by other SC in WCAG. For example, if a duplicate ID results in a form control being labeled incorrectly, then the result of the error is covered in a different SC.

[stevefaulkner]

@nitedog yes - in cases where those ids are referenced in headers, for, aria-labelledby, aria-describedby, aria-controls etc.

[mraccess77]

Nesting issue still occur as well so i dont support dropping rhe whole SC.

[awkawk]

@mraccess77 What is the issue that you are referring to?

@stevefaulkner those wind up being covered by 1.3.1 or 4.1.2, don't they?

[zcorpan]

@awkawk An automated checker would not be able to tell if a form control is labeled incorrectly, would it (needs human judgement)? But it can easily check for duplicate IDs. But I suppose it could still give an error for duplicate IDs and cite 1.3.1 or 4.1.2, though I think that's less clear. Moreover, maybe the checker would need to allow some duplicate IDs, like if they're not referenced at all. I'm not sure that's a useful strategy.

Separately, I would argue that duplicate ID is not a parsing issue. The HTML parser does not have knowledge of IDs. Handling of IDs happens in the DOM layer.

Maybe 4.1.1 could be changed to only require unique IDs?

[jared-w-smith]

My $.02... I've been at this a very long time and don't recall encountering a single instance of a 4.1.1 failure that impacts accessibility that is not captured elsewhere in WCAG. I can't think of an instance where multiple id's that impact accessibility wouldn't also be a 4.1.2 or 1.3.1 failure.

On the other hand, I've encountered lots of 4.1.1 failures that have absolutely no impact on anything - yet authors sometimes spend incredible amounts of time making these tool/validation errors (I'd note that WAVE doesn't test such trivialities) go away for "conformance" rather than focusing those efforts on testing or fixing actual accessibility issues. I wouldn't miss 4.1.1 at all.

[zcorpan]

A while back I asked Mike Smith for stats for different error messages in an instance of validator.w3.org. Here are the errors above 0.1% with an example of markup triggering the error and an analysis/guess if it affects accessibility.

| Percent | Message | Example | Error correction | Affects accessibility?
|---------|---------|---------|------------------|--------
| 21.15% | Stray end tag "X". | <div></span></div> | <div></div> | No
| 11.97% | Start tag "X" seen but an element of the same type was already open. | <a>foo <a>bar</a> | <a>foo </a><a>bar</a> | No
| 9.57% | No "X" element in scope but a "X" end tag seen. | <div></p></div> | <div><p></p></div> | No
| 9.11% | End tag "X" seen, but there were open elements. | <div><span></div> | <div><span></span></div> | Maybe?
| 6.69% | No space between attributes. | <div class=""title=""> | <div class="" title=""> | No
| 5.77% | Bad start tag in "X" in "head". | <head><noscript><div> | <head><noscript></noscript></head><body><div> | No
| 5.40% | Duplicate attribute "X". | <div role="none" role="navigation"> | <div role="none"> | Maybe?
| 4.50% | Stray start tag "X". | <div><tr></div> | <div></div> | No
| 3.32% | End tag for "X" seen, but there were unclosed elements. | <i>(EOF) | <i></i></body></html>(EOF) | No
| 2.58% | Quote "X" in attribute name. Probable cause: Matching quote missing somewhere earlier. | <div class=" title=""> | <div class=" title=" "=""> | Maybe?
| 2.46% | Self-closing syntax ("/>") used on a non-void HTML element. Ignoring the slash and treating as a start tag. | <div/> | <div> | Maybe?
| 2.43% | End tag "br". | </br> | <br> | No
| 2.30% | End tag "X" violates nesting rules. | <i><p></i> | Adoption agency algorithm | Maybe?
| 1.40% | Named character reference was not terminated by a semicolon. (Or "&" should have been escaped as "&".) | &nbsp |   | No
| 1.39% | "X" in an unquoted attribute value. Probable causes: Attributes running together or a URL query string in an unquoted attribute value. | <a href=?x=y> | <a href="?x=y"> | No
| 1.25% | Saw "<" when expecting an attribute name. Probable cause: ">" missing immediately before. | <div <p> | <div <p=""> | Maybe?
| 0.98% | A slash was not immediately followed by ">". | <div / > | <div> | No
| 0.93% | Stray doctype. | <div><!doctype html></div> | <div></div> | No
| 0.92% | Saw "<!--" within a comment. Probable cause: Nested comment (not allowed). | <!-- <!-- --> --> | The comment is closed on first --> | No
| 0.71% | "X" element between "head" and "body". | <head></head><link> | <head><link></head> | No
| 0.71% | End tag "X" implied, but there were open elements. | <ul><li><span><li></ul> | <ul><li><span></span><li></ul> | Maybe?
| 0.70% | Non-space character inside "noscript" inside "head". | <head><noscript>X | <head><noscript></noscript></head><body>X | No
| 0.62% | Start tag "X" seen in "table". | <table><div> | <div></div><table> | No
| 0.56% | Saw "X" when expecting an attribute name. Probable cause: Missing "=" immediately before. | <div class="" "> | <div class="" "=""> | Maybe?
| 0.53% | Bad character "X" after "<". Probable cause: Unescaped "<". Try escaping it as "<". | 2<5 | 2<5 | No
| 0.41% | Bogus comment. | <!x> | <!--x--> | No
| 0.33% | "X" start tag in table body. | <table><td> | <table><tbody><tr><td> | No
| 0.31% | Heading cannot be a child of another heading. | <div><h2>Foo<h2><p>bar</p></div> | <div><h2>Foo</h2><h2><p>bar</p></h2></div> | Yes?
| 0.23% | End of file seen and there were open elements. | <div>(EOF) | <div></div>(EOF) | No
| 0.23% | Character reference was not terminated by a semicolon. | &#xD | 
 | No
| 0.23% | End tag had attributes. | </div foo> | </div> | No
| 0.15% | A numeric character reference expanded to the C1 controls range. | € | € | No
| 0.15% | Saw a "form" start tag, but there was already an active "form" element. Nested forms are not allowed. Ignoring the tag. | <form class="outer"><form class="inner"> | <form class="outer"> | No

[alastc]

EDIT: Sorry, my page was stale, I was responding to the 3 hour ago comment!

@zcorpan It's hard to work out from that, the question is whether someone using assistive techology would get a different result. The criteria came from a time (mid 2000s) when screenreaders & other AT often interpreted the HTML themselves, and the browsers gave very different results to validation errors.

If the browsers are generally consistent in how they deal with un-closed tags, nesting, and duplicate / non-unique IDs, there's an argument this criteria doesn't acheive anything (useful) anymore.

ADDITION: the example with duplicate IDs is interesting, as I think it demonstrates why this isn't an accessibility issue anymore:

<div role="none" role="navigation"> Interpreted as: <div role="none">

If the browsers deal with that consistently (my understanding is they do), then the duplication aspect is not important, the role is programatically determined and not ambigious, and we can use 4.1.2/1.3.1 to pick up the results. If it should be 'navigaiton', then role="none" is a fail elsewhere.

[zcorpan]

That's a duplicate attribute, not duplicate id, but yeah.

If the browsers are generally consistent in how they deal with un-closed tags, nesting, and duplicate / non-unique IDs, there's an argument this criteria doesn't acheive anything (useful) anymore.

This has been the case for HTML parsing since browsers implemented the HTML5 parsing algorithm:

| Browser | Version | Release date |
|-------------------|---------|--------------|
| Firefox | 4 | 2011-03-22 |
| Safari | 5.1 | 2011-07-20 |
| Opera | 12 | 2012-08-30 |
| Internet Explorer | 10 | 2012-09-04 |

[DavidMacDonald]

I have taken an action item to propose a resolution to the Working Group on behalf of the AWG.

BACKGROUND

I've always considered myself a WCAG purist and try to represent the text of WCAG along with the historic background of the intention behind an SC, as I remember it, or by reviewing old minutes of meetings and disregard my personal preferences on an SC.

In the case of 4.1.1, at our F2F in about 2005, there were huge debates over validation. The Italian organization for web developers (and other stakeholders) were very vocal advocates of FULL validation. They felt validation improved accessibility and clean code is desirable anyway. However, the counter position was that most of validation does not affect accessibility and we don't want organizations burning their accessibility budgets chasing down issues that don't affect accessibility.

It was one of the longest and most heated debates I remember in WCAG 2.0. In the end a compromise was reached where only a small subset of validation issues which were thought to affect accessibility were included.

• elements have complete start and end tags,
• elements are nested according to their specifications,
• elements do not contain duplicate attributes,
• IDs are unique.

In hindsight, I think these could have gone into 1.3.1 or 4.1.2 but 4.1.1 was a precarious flash point for the validation crowd and it was prudent to give it its own SC called "Parsing" and we negotiated making the first listed sufficient technique to be "Validation", which allowed us to proceed with consensus from all stakeholders.

ANALYSIS

• We kept that subset of 4 validation checks because we felt they affected the way screen readers could interpret the DOM.
• Now there is an even narrower subset that affects accessibility, which can be mapped to 1.3.1 or 4.1.2.
• In my work with large organizations, I have seen a lot of money and time poured into these issues which has negatively affected timelines and budgets. Today we call it "fake work" which hurts everybody including those with disabilities.
• There is still a certain subset of accessibility advocates who strongly advocate full validation, and might resurrect the 2005 discussion if a proposal is made to change it.
• The accessibility support requirements give us a potential avenue to deprecate this SC in WCAG Version 2.2 without hurting backward compatibility with 2.0. We would say that this SC has already been met because its requirements are fulfilled by AT and User Agents. The few things that still affect accessibility such as duplicate ids on interactive elements and improperly formed accessibility attributes or bad nesting are mapped to either 1.3.1 or 4.1.1
• Nesting issues that @mraccess77 mentions are also covered in 1.3.1.
• Bad ARIA mentioned by @mraccess77 is a failure of 4.1.2: Name, Role, Value, (and States and Properties). ARIA says "This specification provides an ontology of roles, states, and properties ... "
• I personally think deprecating the SC is the right thing to do if we can get broad consensus. I think as we add Success Criteria in the 2.x series, it is prudent to try to deprecate requirements that are no longer useful.

Unofficial response for AWG consideration

We agree that the issues you have listed, and other requirements from 4.1.1 do not affect accessibility due to several factors including the progress made in markup standards, browsers and assistive technology since the 2008 release of WCAG 2.0. We are therefore proposing that for WCAG 2.2 we mark 4.1.1 as deprecated with a NOTE that "Several 4.1.1 requirements that affect accessibility such as duplicate ids and improperly formed attributes are already covered in 1.3.1 and 4.1.2". We have also amended F77 and F70 to reflect current accessibility support, and mapped them to Success criterion 1.3.1.

[WilcoFiers]

@DavidMacDonald I think there is a better way to handle this problem. This hinges on how to interpret the word "allow", as Andrew said. I think there are two ways to understand the word "allow"

1. Allow could mean it has to be explicitly permitted, OR
2. Allow could mean that it is permitted when there are accommodations for it (e.g. there is an allowance for it)

AG can decide that the second meaning is the intended one. That an HTML 5 page with duplicate attributes satisfy SC 4.1.1, because HTML 5 has an allowance for duplicate attributes.

Taking that position would mean this stops being something people need to fix in HTML 5 pages, effective immediately. This interpretation can be documented without changing the normative text, so there is no urgency to deprecate the SC. It also means that in technologies that do not describe how to resolve parser errors, this remains an accessibility issue (as I think it should be).

[dylanb]

HTML is a specification for the representation of content, some of which may be accessible and some of which may not.

WCAG is a specification on what is accessible. When applied to Web pages, it specifies how to use HTML and other related technologies to create accessible content.

Please don't defer the role of the WCAG spec to a spec that does not aim to fulfill this role.

Duplicate IDs, regardless of how the browsers handle them, cause problems in some assistive technologies. Most prominently, Dragon triggers the wrong button when two buttons have the same ID in half of the possible uses of those two buttons. The reason for this is simple: getElementById ALWAYS returns the first ID regardless of whether the user is trying to trigger the second button.

Here is a page http://dylanb.github.io/duplicate_ids.html try to trigger the second button

[patrickhlauke]

@WilcoFiers taking the second interpretation then, there is an "allowance" for all the listed original validation issues (unclosed/misnested tags/elements, duplicate id/attribute), as the spec defines how user agents can error correct for this. meaning that we can keep 4.1.1, but say "but it's always a pass as the spec has allowance for borked markup"

[patrickhlauke]

@dylanb to be clear, we're trying to find situations where invalid markup causes real-world problems that specifically impact users with disabilities. it wasn't an attempt to "defer" any kind of responsibility to the HTML spec...

With that out of the way, thank you for providing an example of where duplicate ID has an impact specifically for Dragon users (though that begs the question: is this an issue with Dragon being buggy?)

[alastc]

meaning that we can keep 4.1.1, but say "but it's always a pass as the spec has allowance for borked markup"

That would be a fallback, but it doesn't seem the best way to deal with it, we'd be handwaving and saying "it's still here but just ignore it".

On the dragon example, I'd happily fail that under 1.3.1. as the relationship conveyed through presentation is not programmatically determined. H93 (uniqe IDs) could become a technique under 1.3.1.

@dylanb do you know of any examples that would fail 4.1.1 without failing 1.3.1 / 4.1.2?

[awkawk]

@dylanb you can also see an effect of the duplicate id's when trying to click on the label with the mouse. If you click on the second "search" label the focus goes to the first field. I see that @alastc just beat me to this response, but I would fail this based on 1.3.1.

[dylanb]

@alastc @awkawk I am no fan of 4.1.1 but I would actually like to see it changed and expanded rather than removed. Any 4.1.1 failure that resulted in a real accessibility problem could always previously also be categorized under another SC (as long as WCAG itself covered that issue - which it does not always do)

There is an argument to be made that all of 1.1.1 can actually be categorized under 4.1.2 as can many other failures.

What 4.1.1 is about that is unique in WCAG is: future proofing - its intent is to ensure that stuff that works today, will work in the future. I think it would be great to be able to drop issues which the specs evolve to cover and that also get implemented by all parties involved (not just browsers)

If we are going to remove things, we also need to be able to add things that make sense. We should keep the 4.1.1 intent and expand specifics to include things like ARIA conformance.

[patrickhlauke]

@alastc

That would be a fallback, but it doesn't seem the best way to deal with it, we'd be handwaving and saying "it's still here but just ignore it".

yeah there was an implied "so what's the point then?" in my previous comment

[mraccess77]

Form controls inside of links that are against the spec
< a href="tos.html"> <input type="checkbox" aria-label="I agree"/> I agree to the TOS </a>

I've seen buttons inside of links. Form
<a href="tos.html"> <button>TOS</button></a>

I've seen ARIA markup use aria-owns on controls that contain owning elements.
*Input fields with aria-owns
*Buttons with aria-owns
Use of ARIA owns changes the accessibility tree and can create relationships that should never exist.

I've seen issues with links inside labels that impact Talkback on Android.
<label><input type="checkbox" /> I agree to the <a href="tos.html"&t;Terms of Services</a></label> In this case it's nested in accordance with the specification but isn't supported with all assistive technology.

[zcorpan]

Those cases are not parse errors.

[mraccess77]

@zcorpan The NU Validator says Error: The element input must not appear as a descendant of the a element.
4.1.1 says nested according to their specifications. Is the validator wrong?

[patrickhlauke]

Form controls inside of links that are against the spec
< a href="tos.html"> I agree to the TOS

I've seen buttons inside of links. Form
TOS

do those fail / create problems for all users, or just specifically keyboard and/or AT users?

aria-owns issues...possibly 1.3.1 and 4.1.2 issues?

[DavidMacDonald]

I'd say bad ARIA is almost always a failure of 4.1.2: Name, Role, Value, (and States and Properties).
The ARIA spec says

"This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. "

I say "almost always" out of an abundance of caution. I can't think of when it isn't a failure of 4.1.2.

[zcorpan]

@mraccess77 it's not wrong, it's just reporting all checkable conformance errors, not just parse errors. 4.1.1 is worded like it is specifically to subset all conformance errors to the smaller set of errors that is parse errors, as @DavidMacDonald wrote in "Background" earlier.

If you enter that markup in https://parsetree.validator.nu/ (and include a <!doctype html>) it should give you no parse errors.

But it might still violate other requirements of the HTML standard, that are not in scope for 4.1.1.

[mraccess77]

@zcorpan the normative text doesn't say anything about parsing errors
It says "In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.". So while the short name of the SC includes the word parsing - that is not in the normative text.

The normative text says "elements are nested according to their specifications" -- so whether it is or is not related to parsing it is covered by the SC.

[zcorpan]

Oh, yes, I stand corrected. Content model requirements do fall into that.

[dylanb]

Let me make one more argument in favor of adding ARIA conformance to 4.1.1

When 4.1.1 was created, there were real and important differences in the ways that different browsers and ATs handled non-conforming HTML. This meant that the only way to guarantee consistent behavior across browsers (or as close as possible) was to stick to the spec.

I would say that 4.1.1 served this purpose very well. But the HTML spec has evolved to the point where all of those differences are now gone because they are covered in the (evolved) spec itself.

The implementation of ARIA is in a similar situation today that HTML was 10 ish years ago. There is no specification to say what to do under all of the absurd non-conforming ways the technology might be used. Therefore we would be adhering to the intent of 4.1.1 by dropping the HTML parsing errors and adding ARIA non-conformance.

[alastc]

There is no specification to say what to do under all of the absurd non-conforming ways the technology might be used.

I might be missing something, when would code would fail "ARIA conformance" but not fail 4.1.2?

[DavidMacDonald]

@alastc +1

[WilcoFiers]

@alastc There are a lot of ways to create invalid ARIA without causing accessibility issues. You just slap an random ARIA attribute onto an element that shouldn't have it:

<button aria-colspan="five">Submit</button>

I think the question of should correct use of ARIA be required by WCAG is a separate question. I would suggest opening a separate issue for that.

It seems to me the original intent of 4.1.1 is to handle the problem of ambiguity in markup specs. If a popular inaccessible browser parses something one way, and some AT does it a different way, and the spec isn't clear about which one is correct, content should work in both. That problem was solved years ago, at least as far as technologies web browsers support go. Duplicate IDs, duplicate attributes, incorrect nesting, none of these things are accessibility problems. They can cause them, but they are symptoms of a problem, not the problem itself.

I think AG can simply declare that the HTML 5.x meets the exception in 4.1.1.

[alastc]

Good points @WilcoFiers

It is a separate question, and if we expand/add something to cover ARIA conformance, it would be separate from 4.1.1.

I'd also like to see it looking for outcomes rather than conformance to a spec. I.e. does this thing do what it's supposed to, rather than catching random stuff that has no impact on end users. Otherwise we could be in the same position next time, wondering how to depricate it.

I think AG can simply declare that the HTML 5.x meets the exception in 4.1.1.

That would be one method, I'd like to explore removing it though.

[nitedog]

Do we know the situation with other markup languages, specifically SVG?

[WilcoFiers]

@michael-n-cooper Based on yesterday's discussion, can you assign this to me?

I'm thinking to show that this should be deprecated, what I'll need to do is prove that any type of non-conformance that can come form 4.1.1 is either not an accessibility concern for modern markup technologies, or also a conformance issue under a different success criteria.

[alastc]

I just tried to assign you, but your @WilcoFiers account doesn't seem to be enabled on this repo, probably needs a tweak from Michael.

[awkawk]

@WilcoFiers any updates?

[WilcoFiers]

I've opened an issue here: https://github.com/w3c/wcag/issues/770. I propose we close this thread.

[awkawk]

OK, this conversation is referenced from #770 so I'll close.