W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

GL 2.5 Remaining 3 issues

From: Andi Snow-Weaver <andisnow@us.ibm.com>
Date: Wed, 8 Jun 2005 07:48:14 -0500
To: w3c-wai-gl@w3.org
Message-ID: <OF5267CA26.5F5C8DA8-ON8625701A.0042A477-8625701A.00465580@us.ibm.com>

There are 3 remaining issues with 2.5.

- questions the number 75 in L3 SC 1.

<current wording>
Where text entry is required for which there is a known set of less than 75
valid choices and they can be provided without jeopardizing security or
purpose, users are allowed to select from a list of options as well as to
type the data directly.
<end current wording>

<proposed wording>
If there are more than 75 choices, selection lists must not be the only
means of providing the input choice. Another input method, such as a text
entry field, text typing to select items from list, or a search function,
must be provided instead of, or in addition to, the selection list.
<end proposed wording>

- Survey results indicate that all but one responder prefer the proposed
- At the teleconference on 19 May, 2005, Gregg indicated that this success
criterion is misplaced because it is about efficiency for keyboard only
users, not about avoiding or correcting errors.

- I propose moving this SC to GL 2.1 Level 3 because it is about efficient
keyboard operation.
<end proposal>

- objects to Level 3 SC 2 on spell checking - conflicts with usability -
the decision to offer spell checking and to suggest correct spellings
should be left to the content author because the usability of the outcome
depends on many things including the quality of the dictionary, the
language used by the user which may be different from the language of the
page, and terms and names used.

<current wording>
If possible for the natural language of the text, an option is provided to
check text entries for misspelled words with suggestions for correct
<end current wording>

- Survey results on removing this criterion are mixed. Jason suggests
something less than a spelling check that can reasonably be required,
depending on the nature of the input? For example, basic validity checks
(syntax of telephone numbers, e-mail addresses etc.) can be performed; if
the text entry is selecting tems from a list or database, the closest
matches can be found using approximate searches etc.
- Our current wording is already teetering on the edge of not being
testable ("If possible for the natural language of the content..."). I
think we can resolve the issue by generalizing this to something that
"suggests" spell checking but leaves the ultimate decision to the developer
about what is appropriate assistance for the context.

<proposed wording>
An option is provided for additional context relevant assistance such as
checking for spelling errors or providing close matches for search results.
<end proposed wording>

- challenges the benefit claimed for identifying typing errors - it is
difficult for people with dyslexia to select the correct word from a list
of similar words.

<current wording>
Identifying typing errors helps individuals with writing disabilities and
people with dyslexia who often have difficulty writing text in forms or
other places that need text input.
<end current wording>

- Survey results on removing this benefit are mixed. I suggest we use some
of John's words on the spell checking issue to generalize the benefit which
will resolve the issue raised against dyslexia

<proposed wording>
Identifying typing errors helps blind users, individuals with motor
disabilities who often press keys by mistake, and those with certain types
of learning disabilities who have difficulty writing text.
<end proposed wording>

IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo
Received on Wednesday, 8 June 2005 12:48:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:59:37 UTC