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