W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2018

Re: WCAG violations or accessibility enhancements

From: Michael Gower <michael.gower@ca.ibm.com>
Date: Fri, 2 Mar 2018 09:24:30 -0800
To: Duff Johnson <duff@duff-johnson.com>
Cc: w3c-wai-ig <w3c-wai-ig@w3.org>
Message-Id: <OFC68BC198.E2A2A57C-ON88258244.005E5997-88258244.005F9F68@notes.na.collabserv.com>
Thanks for many insightful comments, Duff.

As noted, the WCAG 2.0 criteria tend to move from one of your paradigms to 
the other through the levels, with many of the AAA WCAG 2.0 success 
criteria biased to usability, with the As at the opposite end of the 

It's been a fun, fascinating occasionally frustrating experience being on 
the working group effort on 2.1 these past 18 months, after spending two 
decades working daily with users with disabilities trying to ensure the 
technology, processes and applications they use actually enable them. As 
noted by some, it's important to bring the abstract discussions back to 
end user experiences, and vice versa.

Thanks for the discussion, folks. It may not always seem like it, but all 
these different perspectives help us move towards a more usable world.

Michael Gower
IBM Accessibility

1803 Douglas Street, Victoria, BC  V8T 5C3
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034

From:   Duff Johnson <duff@duff-johnson.com>
To:     w3c-wai-ig <w3c-wai-ig@w3.org>
Date:   2018-03-02 08:54 AM
Subject:        Re: WCAG violations or accessibility enhancements

A fascinating discussion! I want to offer a couple of points:

1)  We are living in an HTML world, and HTML is a lousy language for 
semantics. The reason why the world ever started to use <h1> to tag a 
document’s title is that HTML’s developers thought that “title” was a 
metadata concept, not a page-content concept. They were wrong… and the 
HTML-based world now lives with the consequences. This is a good reason, 
btw, to avoid thinking of HTML as definitive of content semantics; it’s 

2) This failing of HTML with respect to semantics in general and the title 
concept in particular, is a good vector for understanding the problem of 
skipped headings. When there’s fundamental confusion over the purpose of 
<h1> (title? first section heading??), you can expect headings in general 
to suffer. This is *before* we get to the problem that most authors are 
thinking of style, not structure, when they use heading tags.

3)  HTML-thinking encourages several unspoken assumptions about content, 
most egregiously, the idea that:

- HTML pages are relatively short; most with relatively few headings
- Each page is an independent entity (not a part of a larger semantic 

These assumptions drive users to:

- Treat headings as semi-arbitrary styling rather than critical semantics
- Fail to consider larger documents when considering what’s necessary to 

For the record… I am a BIG FAN of requiring (for accessibility purposes) 
that headings do not skip. It’s fair to say that it’s my fault (along with 
some collaborators) that such a requirement was included in PDF/UA-1.

I still feel that headings should not skip - and that (admitting some 
edge-cases) any specification for accessible content should require they 
do not. However, as a professional standards developer, I now believe that 
it’s not appropriate for PDF/UA (or any technology specification) to 
include such a requirement.. and indeed, the WG developing PDF/UA-2 has 
removed this requirement - along with other content requirements - from 
its draft.

One must understand that standards are intended for very specific 
purposes. Technology requirements are quite distinct from content 
requirements. An analogy might help.

Consider a car. It’s a bundle of technologies that enable travel from A to 
B. Correct use of a car includes little things like:

- Don’t drive on the sidewalk
- Stay on your side of the road
- Dip your headlights around other vehicles at night
…and so on.

These things are critical to safe use of the car. However, it would be 
wrong to try to include these requirements as part of safety 
specifications *for the car*. We certainly need specifications to define a 
safe car (bumpers, headlights, airbags, seatbelts, etc.)… but we need 
*other* specifications for the “users” - the human drivers. We call these 
the "rules of the road".

OK, returning to the accessibility world.. 

File-formats (HTML, PDF) are vehicles for content; they are not content 
incarnate. The formats need to include all the necessary structures such 
that it’s possible to use the format in an accessible way. But a rule such 
as “don’t skip headings” is not a file-format issue; it’s a usage issue, 
analogous to the “rules of the road”.

We need two kinds of standards for accessibility. For technology we need 
rules to ensure that relevant objects are available and representable. For 
users we need rules to ensure that accessibility considerations are part 
of the authoring process. 

Both WCAG 2.0 and PDF/UA-1 confuse this issue: they are both a pastiche of 
technology AND content requirements.

I understand why the world developed this way: people want software to 
somehow automagically impose content  requirements because otherwise 
authors get it wrong, and/or must be laboriously trained to do the right 

Governments want to keep things simple… so requiring that software adhere 
to one standard and users adhere to another seems “confusing”… until you 
realize that handing drivers a list of requirements for safe car design 
doesn’t help them learn how to drive safely… and handing car manufacturers 
a copy of the Rules of the Road doesn’t help them to make better seatbelts 
or headlights.

The government uses completely separate agencies to regulate car 
manufacturing and driving regulations. Our problem in this industry is 
that we’re using the *same* agency to try to accomplish distinct, 
divergent objectives.


Received on Friday, 2 March 2018 17:25:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 March 2018 17:25:19 UTC