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
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>
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/ 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>
> *Sent:* 03 March 2020 16:12
> *To:* 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.
>    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.
>