RE: Markup / CSS / XHTML

Hi Anthony,
Thank you for your feedback, it is appreciated. The additional input from you analysts is appreciated. Steve did provide great input  and it was great information.

Have a great day.
Judy

From: Anthony Adams <anthony2adams@gmail.com>
Sent: June 8, 2020 4:27 PM
To: w3c-wai-ig@w3.org
Subject: Re: Markup / CSS / XHTML

Judy,

When I saw this question, I immediately forwarded it to my team. I see that Steve has already provided a reply, but thought our analysts' input below might add some additional color:


1.       WCAG 2.0 doesn’t actually require webpages to pass HTML or CSS validation. WCAG has success Criteria 4.1.1 – Parsing, which provides requirements that are similar to the concept of “well formed” code but which differs in some significant ways. SC 4.1.1 requires that correct syntax for start and end tags are used, that IDs are unique, etc. but the requirements don’t come close to passing HTML validation tools. Much of what might fail an HTML or CSS validator simply doesn’t have a lot of bearing on accessibility.

2.       Change from extensible markup to HTML, a less strict markup language that may reduce some, but certainly not all of the validator’s errors/warnings

3.       Software and hardware is not likely to ignore all CSS on a page if only some of it has errors. If the CSS that has errors due to deprecation or is poorly formed, those pieces of CSS will not be applied to the page. Keep in mind that CSS should only be used for the visual styling of content from HTML, not to insert any meaningful content (this includes meaningful icons with no text alternative. Additionally, if CSS has been used to impose text color but not background color and the user has set their own color scheme for accessibility purposes, then the browser may revert to a mix of default browser styling and user imposed  styles which can create contrast issues making the content unreadable, misplaced images, etc.

4.       See previous comment regarding using CSS to present meaningful content. Disabling the styles on a page can provide a good visual idea of what content the HTML provides and what has been imposed through CSS. The page should still be functional and each section of the content logical when you disable CSS in this way.

5.       WCAG is intentionally technology agnostic, meaning it requires the code to be correct, not that a webpage results in an accessible experience with specific browser and assistive technology combinations. The reason for this is that the browser and assistive technology combinations are many and a web developer cannot be expected to accommodate every permutation. If the underlying code is sound, i.e. it provides all of the information about content in a way that is programmatically determinable, then it is the responsibility of browsers and assistive technology to interpret and present that content. The goal of WCAG and similar standards is to provide a framework for the correct ways to programmatically reveal the information. Separate standards address how assistive technology should interpret that information.


Best,

Anthony
aadams@access2online.com<mailto:aadams@access2online.com>
503-570-6831
FAX: 503-582-8337
Access2online Inc.
29030 SW Town Center Loop East
Suite 202-187
Wilsonville, OR 97070
www.Access2online.com<http://www.access2online.com/>
Prison inmates helping the internet become accessible

On Mon, Jun 8, 2020 at 11:07 AM Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>> wrote:
Hi Judy,
Whoever wrote those statements is seriously over-stretching their case. Most of what they have written is either out of date or plain wrong. My views are:

  1.  WCAG 1.0 used to require that the HTML and CSS validated without errors, but this requirement was dropped in WCAG 2.0, which only requires that “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”.

This means you don’t need to validate the CSS at all. You do need to validate the HTML, but you need to filter the results to only display the relevant ones. You can get a bookmarklet that does this from https://dotjay.github.io/wcag-parsing-filter/bookmarklet/. When you do this on your website, there is only one relevant error, which is a stray closing tag. I have looked at the code, and in this case browsers will ignore it, so it actually has zero impact in practice.

I would never argue against fixing the code so it validates, but almost none of your errors constitute a WCAG non-conformance. If the errors have any impact at all, they are likely to cause browser compatibility issues rather than accessibility ones.
  2.  The presence of xmlns=”https://www.w3.org/1999/xhtml/” in the <html> element does not mean the website is claiming to use the XHTML doctype. The website is using HTML5 as you would expect. I am no expert on namespaces, but the page at https://www.w3..org/1999/xhtml/<https://www.w3.org/1999/xhtml/> says that “The namespace name http://www.w3.org/1999/xhtml is intended for use in various specifications such as…HTML5”.
  3.  The statement is completely untrue. The HTML specification has always stated that pages do not have to validate and that browsers can do what they like if they encounter invalid code. They may choose to ignore that particular piece of code, but they often attempt to fix it by taking a guess at what the author intended.

I would challenge whoever wrote that statement to provide any example (even one they have fabricated) where a browser ignores valid CSS.
  4.  In WCAG 1.0 it was a requirement that pages were usable without CSS, but this requirement was dropped in WCAG 2.0. in order to claim conformance with WCAG 2.0 or 2.1, the website must only rely on “accessibility supported” technologies. CSS is an accessibility supported technology, so conformant websites are allowed to rely on it. See https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head

  5.  From a WCAG conformance perspective, it is irrelevant whether browsers and screen readers exist that do not work with the Durham.ca website. From a validation perspective, the only requirement is that the website uses accessibility supported technologies (which include HTML and CSS) and that certain types of HTML validation errors do not occur. If users choose to use browsers and screen readers that do not work with a WCAG conformant website, that is not the website owner’s problem.

Also, I cannot find anything in AODA that requires anything other than conformance with WCAG 2.1 level AA. The statement that “these problems are causing Durham.ca to be non-compliant with AODA” is not true in my opinion (or it will not be true when the one spurious closing tag is removed, which in any case is not having any effect on anything).
  6.  http-equiv="Content-Style-Type" and http-equiv="Content-Script-Type" do not exist in HTML5, so they can indeed be removed. However, that won’t actually fix anything because browsers will already be ignoring them.

Steve Green
Managing Director
Test Partners Ltd

From: Judy Christianson <Judy.Christianson@durham.ca<mailto:Judy.Christianson@durham.ca>>
Sent: 03 March 2020 16:12
To: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Markup / CSS / XHTML

Hi,
I am not a web developer, but I am working with the accessibility of document. Someone has commented on the accessibility of our website and wondered if I could get input and feedback from you regarding the comments received. What I am looking for is the validity of the six statements below and what you would suggest for fixes if you are able to. The website was developed by a third party service provider.
Comments received are listed below:

  1.  WCAG 2.0 indicates that websites must have correctly formed markup and CSS, but testing today (2020-02-18) with W3C's markup and CSS validators, I see a total of 447 errors and warnings:

Markup: https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.durham.ca%2Fen%2Findex.aspx

CSS: https://jigsaw.w3.org/css-validator/validator?uri=https%3A%2F%2Fwww.durham.ca%2Fen%2Findex.aspx

  2.  At the top of Durham.ca's markup, Durham.ca's webmaster has declared "http://www.w3.org/1999/xhtml" as the website's XML namespace, which means that Durham.ca is claiming compliance with W3C's XHTML standard, even though it isn't.  W3C created the XHTML standard in 1999, and finalized it in early 2000, over seventeen years before Durham.ca was revamped in late 2017.  XHTML also predates the existence of Durham.ca, which wasn't created until 2007 as the replacement for Durham.on.ca<http://Durham.on.ca>.
  3.  CSS errors can cause significant usability problems in web browsers and in screen readers that can parse CSS.  If such software/hardware is unable to parse a website's CSS due to errors in the website's CSS, then it will typically respond by not using any of the website's CSS to render its pages.
  4.  Mozilla Firefox is a web browser with a feature that allows a user to temporarily display a website without the website's CSS.  If you use Mozilla Firefox to access Durham.ca, and then go to "View" menu -> "Page Style" -> "No Style", you'll discover that Durham.ca would be extremely difficult to use without CSS.  You can enable CSS again by going to "View" menu -> "Page Style" -> "Basic Page Style".
  5.  While the web browsers and screen readers that Durham.ca's webmaster used to test Durham.ca may have been designed to work around Durham.ca's markup and CSS problems, I'm not aware of any standards that require all web browsers and screen readers to do this, and there's no guarantee that the most popular web browsers and screen readers will continue to tolerate these problems indefinitely....  More importantly, these problems are causing Durham.ca to be non-compliant with AODA.
  6.  Fortunately, all these problems can be corrected fairly easily.  For example, Durham.ca's "meta" markup elements with attributes http-equiv="Content-Style-Type" and http-equiv="Content-Script-Type" are obsolete vestiges from HTML 4 that don't exist in XHTML, so Durham.ca's webmaster could eliminate two markup errors by simply removing these two elements.
Judy Christianson
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.