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

RE: WCAG violations or accessibility enhancements

From: <chagnon@pubcom.com>
Date: Fri, 2 Mar 2018 15:04:14 -0500
To: <w3c-wai-ig@w3.org>
Message-ID: <00fd01d3b261$a376a570$ea63f050$@pubcom.com>
Duff, you and I agree on something!
<quote> Both WCAG 2.0 and PDF/UA-1 confuse this issue: they are both a pastiche of technology AND content requirements. </quote>

So how do we start separating the two types of standards?

We have the HTML + WCAG combo.
And the PDF + PDF/UA combo.
EPUB is in development.

Your car analogy (see Duff's comments below) is good, but it doesn't jive in one key way for us in the technology business: Whatever our manufacturers do in their software affects those who create content and use AT to access it. 

If I make a table in Word, I need a way to designate the user requirement for column headers. Word, the manufacturer, needs to provide me, the content creator, with the tools to do this. I can't do it on my own; the tool has to be there for me to use.

If I take that Word document and convert it to HTML, the web master can always hand code the table to be correctly tagged for headers. Little problem there.

But if I export that Word document to PDF or EPUB, then I'm working with one more manufacturer who has to know that the table headers are required...and they have to correctly interpret my Word table into a PDF or EPUB table with the headers.

Therefore, in these types of digital media, the manufacturers — all of them in the workflow — have to be told somehow what the accessibility requirements are for tables and column headers—what you called the user requirements. And the manufacturers must build their software to let the content creator make a compliant table with column headers.

Software manufacturers are in a way, "users" too.

It's multi-layered standardization. Difficult to separate where to draw the lines for manufacturers, content creators, and AT users. It's a blur. Not as cut and dry as NHTSA car safety standards versus rules of the road.

—Bevi Chagnon
 

— — —
Bevi Chagnon, founder/CEO  |  Bevi@PubCom.com 
— — —
PubCom: Technologists for Accessible Design + Publishing
consulting • training • development • design • sec. 508 services
Upcoming classes at www.PubCom.com/classes
— — —


-----Original Message-----
From: Duff Johnson <duff@duff-johnson.com> 
Sent: Friday, March 2, 2018 11:42 AM
To: w3c-wai-ig <w3c-wai-ig@w3.org>
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 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.

Duff.
Received on Friday, 2 March 2018 20:05:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 March 2018 20:05:41 UTC