RE: simple language testable thing

At 03:37 AM 2004-02-05, Jens Meiert wrote:

>- Is this really an important issue in WAI terms [1]?

>[1] 'The aim of the WAI is to level the playing field for people
>      with disabilities. If people with disabilities have the same
>      problems as people without disabilities, the goal is reached.'
>
>      http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0118.html

>- What wording has to be explained, where ain't an explanation needed?
>- What way(s) of semantic highlighting should be recommended?
>
>If these questions (of course and above all, the first) are answered, there
>should be a general discussion on it, not yet.

[I speak as a fool, or at least as an individual.  Your assertion
is out of order, the chairs of the group set those rules.  But
I, as one voice, do wish to a) meet some of your concerns and b)
diagree with some of the more severe strictures.]

There has always been a tension in the WAI between seeking to
guarantee *any* access and striving to attain *equal* access.

You are reading John's opinion in a particularly strong-one-way manner:

You are claiming that if some TABs, some people-without-disabilities,
encounter the same modality of functional degradation as do people
with disabilities, then that modality of functional degradation is
out of scope for the WAI and the WCAG.

The other way to read John's dictum applies the equal-access standard:
If people with disabilities experience a disproportionate degradation
in usability, it is an access issue.

I believe that your reading is too strong.  I do believe that we should give
priority to things that are readily fixable, but I do not believe we should
rule out-of-scope things that are incremental, but disproportionate,
degradations in usability.

I think that this is one of the lessons learned from trying to deploy WCAG1.
One of the things that we learned, in my opinion, is that the distinction
we drew between Priority 1 and Priority 2 is academic to the people who have
to adopt or implement the guidelines.  It is too 'nice' a distinction to
have been used to cut the pie of exhortations.

Let me remind you:

P1 means there is technically *no way* a function of the web can be
accessed for someone with some condition.

P2 is applied if the function becomes effectively useless because the
degradation in usability is so severe.

In the real world, this distinction doesn't carry any weight.  It only
entered our considerations because we are a caucus of technophiles, on
the whole.

So let me turn from process generalities to "on the product" the standing of

- the interest of dyslexics in simple language -

as a WAI concern.

While overly-complex language does degrade the usability of resources
for the general public,

There are people with reading-related difficulties who are "thrown off
the bus" by this degradation.  It pushes them beyond their ability to
cope, to maintain lock on the story line in prose.

I claim that you could by usability-structured experiments
document that there is a relationship between

- reading level, or any metric of language difficulty you chose to use
.and.
- probability of task failure for dyslexic subjects

So on the 'demand' or 'mission' side, the issue clearly has standing to
be a WAI and WCAG concern, and I believe that this has consistently been
the conclusion of past discussions in the WCAG.

But, on the 'supply' or 'technology' side, is there anything that we
can do about this?

Sniffing code pages is enough of a language-change hint so that its
use in prompting authors for translations should be considered.  And
in checking documents.  That is a technological intervention that one
should regard as likely to prove effective until proven otherwise.

This issue not only passes the PF test for "is this a WAI concern" to wit:

- does this failure mode disproportionately and substantially degrade
the usability of the Web for a recognizable class of PWDs?

It also passes the more severe test:

- is this a make-or-break issue for a recognizable class of PWDs?

It also passes the pragmatism test of "can anything really be done about it?"

So there is no excuse for claiming it is out of scope.  I believe that
addresses your first "prior question."

The other two questions are _what should be discussed_ in a general discussion
or task-team assignment.  But here are some provisional, personal answers.

>- What wording has to be explained, where ain't an explanation needed?

There is no one answer to this.

There are various ways of assessing prognostic language difficulty.  And
the results are points on a continuum of difficulty.  One unifying parameter
is the negative of the logarithm of the probability that the user will
recognize the sense intended.

It is not possible to set a uniform standard for language level across all
documents, but documents internally should police a leveling standard and
apply remedies according to their proper sliding scale.

>- What way(s) of semantic highlighting should be recommended?

Embedding a content model in the markup, and interpretation of this content
model in different ways in the User Agent.

The ways of embedding the content model in the markup include

- RDF in a separate file, available for any and all assertions today
- RDF in the same file, available in SSML, SRGS, and some other contexts today.
- <abbr> markup in HTML4, and its replacement under discussion in HTML WG.
- relationship records in a lexicon referenced from an SSML or SRGS document,
.. available today.

The methods used to convey the content model will vary with the format
employed.  Again, there is no one answer here.  There are general trends:

- put things that are most likely to confuse in the 'push' default presentation
.. example: expand abbreviations (including acronyms) on first use.
.. example: for 'context help' for a form control, we are looking for the
right technique that will make the help text be a selection from the
normally displayed text, in preference to relegating this to a
normally-hidden text fragment.
- put things next most likely to confuse in places where there are "a click
away" such as 'notes' if the medium is a standard digital talking book, 
labels for form controls, and similar opportunities built into the markup 
vocabulary specification.
.. example: index the defining occurrences of jargon terms, support a lookup
function in the User Agent that will return the definitive text when any
instance of the buzzword is queried (as in the Atomica product).
- use more indirect linking mechanisms to make connections that are less 
likely to be needed, but will be needed by some.  The best ways to do this 
linking
are still a matter of differing opinions in the W3C at large.  Watch this
space for clarification.
But examples are:
.. a lexicon referenced from your SSML document.
.. metadata in your SVG document liking terms to WordNet nodes

>Best regards,
>  Jens.

Hoping I have suspended your disbelief, I remain

Your colleague,

Al


>[1] 'The aim of the WAI is to level the playing field for people
>      with disabilities. If people with disabilities have the same
>      problems as people without disabilities, the goal is reached.'
>
>      http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0118.html
>
>
>--
>Jens Meiert
>Interface Architect
>
>http://meiert.com/

Received on Thursday, 5 February 2004 12:42:26 UTC