- From: Bristow, Alan <Alan.Bristow@elections.ca>
- Date: Tue, 1 Feb 2022 12:28:26 +0000
- To: John Foliot <john@foliot.ca>, "Patrick H. Lauke" <redux@splintered.co.uk>
- CC: Wai-Ig <w3c-wai-ig@w3.org>
- Message-ID: <1643718505997.39534@elections.ca>
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> 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"
Received on Tuesday, 1 February 2022 12:28:43 UTC