RE: Invalid HTML versus not(?) failing 4.1.1: Parsing

If the bad coding doesn't result in any impact on the accessibility, why do you think there should be a way to report it as a WCAG non-conformance?

You would hope that there is a functional specification or some other requirements document or technical specification that mandates HTML validity, because that's where such a requirement belongs. If there isn't, you might raise the issue with the business analysts or whoever wrote the requirements. It might have been an oversight, or they may have made a conscious decision not to require valid HTML.

FWIW, a redundant DIV with an invalid ALT around an IMG with its own ALT will be ignored by every browser there has ever been, not just modern browsers.

Steve Green
Managing Director
Test Partners Ltd


From: Bristow, Alan <Alan.Bristow@elections.ca>
Sent: 01 February 2022 12:28
To: John Foliot <john@foliot.ca>; Patrick H. Lauke <redux@splintered.co.uk>
Cc: Wai-Ig <w3c-wai-ig@w3.org>
Subject: Re: Invalid HTML versus not(?) failing 4.1.1: Parsing


Thank you Patrick, thank you John.



I agree with all your points.



But I am disappointed that a poorly coded CMS, for example, may produce swathes of clearly invalid HTML, and a carefully coded CMF or CMS that produces squeaky clean perfect HTML, will be measured as equal in terms of merit by the manager who just wants to know, did it pass or fail WCAG.



A (redundant) DIV with a clearly invalid ALT around an IMG with its own ALT may be mended by modern browsers, but it ought to be "officially" recognized as poorer than just the IMG+ALT.



Perhaps we need a SC that if failed will signal an official WCAG low quality rating.



I can explain this issues with nuance in a report to a manager, but unless the issue is part of the WCAG spec it's likely many in authority higher up the decision chain will have to say/choose to say, it does not fail QED it does pass, and QED the invalid code fine; nothing to fix.



Educating decision makers is a good thing (that would help the above) but it is a "soft process", I would like to have a hard WCAG that says: this code meets the low quality threshold and gets an official WCAG yellow card (football analogy (if I understand football correctly)).



Alan



________________________________
From: John Foliot <john@foliot.ca<mailto:john@foliot.ca>>
Sent: Monday, January 31, 2022 5:55 PM
To: Patrick H. Lauke
Cc: Wai-Ig
Subject: Re: Invalid HTML versus not(?) failing 4.1.1: Parsing

Ce message a été envoyé par un expéditeur externe. Veuillez faire preuve de prudence et ne pas cliquer sur les liens ou ouvrir les pièces jointes à moins de reconnaître l'expéditeur et de savoir que le contenu est sûr.

This message was sent from an external sender. Please exercise caution and do not click links or open attachments unless you recognize the sender and know the content is safe.


> having invalid attributes is not a failure of 4.1.1

+1 to Patrick.

As an interesting tid-bit, the biggest part of HTML5 wasn't really about adding new elements or attributes to the markup language, but rather the browser vendors standardizing on failures, and/or how browsers can remediate 'broken' code. So today browsers do a lot of 'fixing' of 'invalid' code. Nonetheless I continue to suggest that developers validate their code (it's a Pride of Workmanship thing) because if/when something isn't working right, if I know my code is valid it already eliminates one potential reason why 'it' is failing. (But that's me)

> and F70 https://www.w3.org/WAI/WCAG21/Techniques/failures/F70

It is also worth noting/reminding that "Techniques" are non-normative in WCAG. Furthermore, of all of our Techniques, I assert that "Failure Techniques" are the weakest of the lot (IMHO), because while they document common ways of failing, they do not list ALL of the potential ways you might fail. I cringe every time I see organizations seeking to claim conformance to WCAG by testing that they did not meet any of the Failure Techniques, (so ergo, they did not Fail - and so, the argument continues, they must have succeeded!). That convoluted reverse thinking continues to leave me gob-smacked.

JF

On Mon, Jan 31, 2022 at 5:02 PM Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 31/01/2022 21:37, Bristow, Alan wrote:

> I know 4.1.1 is complex topic, but I have a CMS adding an ALT attribute
> to a DIV (yes, a (redundant) DIV) that is wrapping an IMG. The IMG also
> (validly) has an ALT attribute. Per the spec the DIV's ALT is invalid:
>
> https://html.spec.whatwg.org/multipage/grouping-content.html#the-div-element
> <https://html.spec.whatwg.org/multipage/grouping-content.html#the-div-element>
>
> specifically 'Global attributes'
>
> https://html.spec.whatwg.org/multipage/dom.html#global-attributes
> <https://html.spec.whatwg.org/multipage/dom.html#global-attributes>
>
>
> In short, I assume it is not a fail if someone adds an ALT attribute to
> a DIV, even though it is blatantly invalid HTML, because it does not (I
> sadly think) satisfy the wording of 4.1.1 or F70.

Correct, having invalid attributes is not a failure of 4.1.1. And in
practice, invalid/unknown attributes don't cause any actual
accessibility issues.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke


--
John Foliot |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"