Re: WCAG violations or accessibility enhancements

Great discussion, I completely agree....:-)

** katie **

*Katie Haritos-Shea*
*Principal ICT Accessibility Architect *

*WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy,* *IAAP CPACC+WAS = *
*CPWA* <http://www.accessibilityassociation.org/cpwacertificants>

*Cell: **703-371-5545 <703-371-5545>** |* *ryladog@gmail.com
<ryladog@gmail.com>* *| **Oakton, VA **|* *LinkedIn Profile
<http://www.linkedin.com/in/katieharitosshea/>*

People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to
dictate where we are going.

On Fri, Mar 2, 2018 at 1:41 PM, Sean Murphy (seanmmur) <seanmmur@cisco.com>
wrote:

> Duff
>
> Love your analogy. This could break when we have self-driving  cars
> though. :-)
>
> Still a good analogy.
>
>
> Regards
> Sean Murphy
> Accessibility Software ENGINEER
> seanmmur@cisco.com
> Tel: +61 2 8446 7751
>
> Cisco Systems, Inc.
> The Forum 201 Pacific Highway
> ST LEONARDS
> 2065
> Australia
> cisco.com
>
> http://www.cisco.com/go/accessibility
>
> Think before you print.
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> http://www.cisco.com/c/en/us/about/legal/terms-sale-
> software-license-agreement/company-registration-information.html
>
>
> -----Original Message-----
> From: Duff Johnson [mailto:duff@duff-johnson.com]
> Sent: Saturday, 3 March 2018 3: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.
>