Doc title (2779a5) allows pass, ignoring 4.1.1

[tombrunet]

Regarding testcase https://act-rules.github.io/testcases/2779a5/2d775d11ea501f97cf182fa8091373ebaddc7b9a.html

On https://act-rules.github.io/rules/2779a5 it is argued that this is a pass because:

Note: The HTML 5.2 specification requires that a document only has one title element, and that it is a child of the head element of a document. However, HTML 5.2 also describes what should happen in case of multiple titles, and titles outside the head element. Because of this, neither of these validation issues causes a conformance problem for WCAG.

HTML 5.2 directs the browser to deal with mis-usage, so I understand that this may no longer be a violation of 2.4.2, however, it would then be a violation of 4.1.1:

elements are nested according to their specifications

I'm not sure how you handle situations like this where it's still a violation, but not necessarily against the conformance criteria that the rule has targeted. Do you require a separate ACT rule to handle the related violation?

[WilcoFiers]

You definitely have a point there. There are significant differences in how 4.1.1 is tested between testers. Some are very strict about it, arguing things like nesting p > p is invalid because you're not allowed to put block elements inside of other block elements according to the spec. Others simply ignore such things arguing that because the HTML spec says what parsers should do with these things, it isn't a parser error at all.

I tend to fall at the more lenient side of things. I wouldn't consider this a failure of WCAG, but I'll bring it up with the group for dicussion.

[tombrunet]

I think where it gets dicey is that it may work fine for Chrome and Firefox, but somebody has to pull something up in lynx, or they have some other niche, non-webdriver based way to access something that you're not expected, and they can run into failures. Yes, you're running into the niche of the niche, but that's really what 4.1.1 is all about.

As for p > p, or even p > div... you can't detect that in the DOM because the parser won't generate it that way. You can only get that situation in the DOM for dynamically added content, which is post-parse, and not really covered by 4.1.1.

[WilcoFiers]

If Lynx does this different from Chrome and Firefox that should be in accessibility support. We haven't tested Lynx. I'm not aware of anyone using Lynx to browse the web, let alone any websites that take Lynx into account. But yeah, if you've tested with Lynx and it doesn't use the first title element in the page, or if it ignores the title if it exists outside the head, that should be mentioned in accessibility support.

[tombrunet]

I haven't looked at Lynx specifically, but used that as an example of a non-standard browser. The entire reason 4.1.1 exists is because it's not good enough to work properly in the popular environments. It's there to ensure that standards are followed enough that non-popular environments also work.

[spanchang]

About :elements are nested according to their specifications"
This again is an example of where multiple SCs apply to a particular element.
True while browsers on a platform may self-correct the issue, this essentially the content author's responsibility and one should simply not rely on the browser's fallback mechanism.
This is under the 'Robust' principle and one may not know why accessibility degradation is occurring in a particular case one one platform and not on the other.
My view has been: check for validation issues and conformance for SC 4.1.1 before doing the remainder of the accessibility tests.
Thanks,
Sailesh

[EmmaJP]

I think its a difficult balancing act between encouraging adherence to advised code specifications, and recognising that browsers know how to handle certain deviation (as advised in those specifications) whether it is intentional or not. As Shadi pointed out in today's meeting, perfect code is not the responsibility of accessibility.

Perhaps a workaround is to be clear in the example description (as well as earlier notes or assumptions in the rule) that two titles is a deviation mentioned by the specifications, and if correctly handled by the browser does not cause accessibility issues, ie. the code still passes.

This would be different to thinking up all the multitude of ways code could be badly written and pass or fail a SC, as it would be something specifically mentioned by a related specification.

...

What would an ACT rule for 4.1.1 look like? For me ... the code passes an appropriate W3C validator check. I wouldn't see much point to try and duplicate what those tools already do. Though I'm aware ACT already has a few related individual rules, such as ID value is unique. It could mean something passes all rules except that one, but I think that would be fair. Well formed code is a good first step toward accessible code.

[WilcoFiers]

The solve for this is for someone to write a rule for 4.1.1. The issue with that though is that AGWG couldn't even agree to publish the duplicate ID rule, so I don't imagine a rule that is even stricter about how HTML is used has much of a chance of ever getting approved.

If someone's willing to put in the work, they're welcome to. But since this has not been updated in over a year I'm going to close the issue.