W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

RE: The Problem with WCAG (was RE: CSS Techniques for WCAG 2.0)

From: <Kurt_Mattes@bankone.com>
Date: Fri, 20 Aug 2004 12:43:47 -0400
Message-ID: <B239BEDED044074C8E2CCC3A9162F2A90A26D90C@swilnts804.wil.fusa.com>
To: <john_slatin@austin.utexas.edu>, <lois@lois.co.uk>, <w3c-wai-ig@w3.org>
I fully understand the desire for simplified language - benefits go beyond accessibility for people with disabilities
 
However, there is the law of many countries that require certain agreements to be written with specific language - and in the US, provided in a specific text size with specific presentation treatments [e.g in a box with a border of a specific thickness].  Creating a "simple" language, text only, version would be a violation of existing laws and not providing it would be a violation of the W3C 2.0 guidelines.  Should the US section 508 adopt the language guideline I am left to wonder which law wins?  Should I as a web designer/developer even have to contemplate this?  Does the W3C realize they are creating the potential for this situation?
 
IMHO - I would like simpler language in legal agreements also, but realize this is not going to happen for reasons I have little or no control over.  If I want a simple interpretation, I must hire an attorney - paid for by my hard earned money.
 

Kurt Mattes 
Application Development Analyst 
Technical Lead - Web Accessibility 
[302] 282-1414 * Kurt_Mattes@BankOne.com 

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On Behalf Of John M Slatin
Sent: Friday, August 20, 2004 9:36 AM
To: lois@lois.co.uk; WAI list
Subject: RE: The Problem with WCAG (was RE: CSS Techniques for WCAG 2.0)


Lois Wakeman wrote:

<blockquote>
[JMS] ...  Native language, written culture, specialised knowledge, proficiency with words, reading and learning difficulties are, like all human attributes, very variable in the average population. In my opinion, having words that will suit everyone is at least a magnitude of difficulty greater than getting a delivery mechanism that will suits the same audience.

(It's hard enough single-sourcing print and online documentation for exactly the same narrowly defined audience without compromising the usability of one or the other, IME.) Of course, just because it's hard doesn't mean WGAG shouldn't try to address some of the issues, but concepts like simplified vocabularies (which are available and useful for example in aerospace and defence documentation domains) often have no real meaning in the world of e-commerce, creative writing, journalism and so on (even The Sun waxes lyrical occasionally!). And as they are generally deadly dull to read, unlikely to captivate many audiences at all.

And as Rust says, text accessibility is not measurable in any meaningful way (without conducting huge programmes of user testing on every single page).

Just my tuppence,

</blockquote>

 

These are important points, and thank you for stating them so clearly.

 

It's certainly true that we're unlikely to find any interesting writing that's equally accessible to everyone; it's equally true that simplified vocabularies developed for specific contexts such as aerospace engineering or other industries.

 

In my own view, the WCAG 2.0 draft guidelines about use of language (especially under 3.1) do not (and should not) require "one size fits all" approach to text content; that's doomed to failure for many reasons.  But it is possible to provide (for example) summaries or paraphrases of complex texts that use simpler language than the full document, and to provide these as *supplementary* material-- in other words, provide both the complex original and a simpler, shorter version.

 

Before everyone gets riled up about this apparently outrageous demand for extra writing, I'd like to point out that there are many cases and contexts where it's routine to produce such summaries:

- so-called "executive summaries" often accompany lengthy technical reports, policy and legal reviews, research proposals, and so forth.  These are often attempts to "boil down" a long, highly detailed text to its bare essentials, and to present them a highly simplified form, for example as bullet points; the intent is typically to communicate the critical points to people who are assumed (politely) to be far too busy actually to read the entire document, or people in executive positions who lack the specialized knowledge to negotiate the details but who still need a basic understanding of the issues in order to make appropriate decisions.

 

Moreover, I don't think there's a mandate in the WCAG 2.0 draft to make every document on the Web fully comprehensible to everyone on the planet. A technical article on search algorithms need not be accessible to an 11-uear-old child, whether or not that child has cognitive impairments. But there *are* computer scientists who have cognitive impairments or learning difficulties, whether these arise through injury or illness (stroke or automobile accident, for example) or from genetics (dyslexia is a neurological condition). And it might be possible, even desirable, to take a few additional steps to support such colleagues, employing a variety of strategies in the process: clear writing, use of visual materials to illustrate complex processes, and so forth.

 

And there *are* ways to quantify at least some aspects of writing-- at least for English-language text; I'm not sure whether there are comparable things for other languages.  For example, the Accessibility Toolbar recently released by the Accessible Information Solutions group at the Australian National Information and Library Service  ( http://www.nils.org.au/ais/web/resources/toolbar/#download) includes a submenu pointing to tools developed by Juicy Studios.  One of these is a Readability Index.  This yields a page that provides a few measures indicating *roughly* how many years of schooling would be required to read and understand the text on the page.  The report also includes a lucid explanation of the process for generating these measures, and even lists the algorithms for different indices.  It also provides a good explanation of how to read the report.

 

Another useful tool is the Plain Language Audit Tool published by the Northwest Territories Literacy Council in Canada ( http://www.nwt.literacy.ca/plainlng/auditool/cover.htm).  This provides a step by step guide to reviewing documents (print or online) for "plain language," including instructions for creating a readability index based on a sample of five 100-word passages.  It also offers some guidance on what grade-levels (years of schooling) might best be suited to audiences with different characteristics.

 

There are lots and lots of problems with things like readability indices, and I would personally prefer to see much more rigorous and systematic application of human intelligence to the task.  And, as I said earlier, I don't know whether such tools exist for other languages-- I suspect that there are some cultures where the very notion of a readability index would be greeted with a mix of laughter, bewilderment, and rage.    But when used well by people who are reasonably well informed, they can be helpful.  (Just like spell-checkers, accessibility evaluation tools, HTML validators... all require some human judgment, and isn't that a good thing?).

 

Sorry to have gone on so long.

John Slatin



**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
Received on Friday, 20 August 2004 16:44:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:44 UTC