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

Re: WCAG violations or accessibility enhancements

From: Duff Johnson <duff@duff-johnson.com>
Date: Fri, 2 Mar 2018 11:41:43 -0500
To: w3c-wai-ig <w3c-wai-ig@w3.org>
Message-Id: <C9A3B164-1A50-4EC5-A221-B3C3F3F151C1@duff-johnson.com>
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 not.

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 construct)

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 accessibilty

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 thing. 

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 16:42:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 March 2018 16:42:16 UTC