Re: Use of pre-compilated text-fields in forms

Just to clarify things slightly:

A braille display is an output/input peripheral to a screen reader.  There 
are many kinds of refreshable braille displays, with differing capabilities 
(line length) (they are currently all one line long), cursor routing keys, 
a full or partial braille keyboard, etc.  Screen readers support them in 
different ways; JAWS has three braille display modes.  Many combinations 
can show that a cursor does or doesn't exist, or put a couple of braille 
characters at the beginning of the line to indicate whether this is an edit 
box, button, or neither.  JAWS and Window-Eyes have basically two modes, 
"forms mode" and "virtual cursor or Browse mode).  The HAL screen reader 
somehow attempts to work modelessly on forms.  And these screen 
reader/braille display combinations can be expected to behave differently 
in Firefox than in IE.  (Although I still use Lynx occasionally, it is 
rather hard to use in a Windows console mode because a special Windows 
screen reader configuration is difficult to create for Lynx in console mode.

In my opinion, blind users must learn how to determine the context around 
form controls, as presented by their user agent of choice, because screen 
readers provide incorrect information almost as often as correct, on the 
current generation of web forms.

At 10:34 AM 5/9/2006, you wrote:

>apologies to the list for my thick headed ness.  The below message
>couldn't have said it better.  I sympathize and empathize with all
>three issues, troublesom, confusing and annoying.  I understand
>bbetter now all the players but am still left with a need for
>something which meets all needs.
>
>On May 9, 2006, at 9:21 AM, Alastair Campbell wrote:
>
>
>David Poehlman wrote:
>>It is my understanding that valid html at some level for
>>accessibility is to use text in the forms.
>
>Ok, let's separate this out. I simply meant that blank inputs are valid,
>and should be recognisable via your user agent.
>
>>It's broader than a braille and not braille issue.
>
>Ok, I'm just suggesting that some people with access issues have
>problems with having default text, and some have issues not having it.
>Thus there is a conflict.
>
>>Now, if I could gett my user agent
>>to mark the fields with text for me so that my small screen would
>>recognize or my audio or braille output device, we could retire
>>this  checkpoint with gusto.
>
>Why should your user agent do this? Surely the requirement is that you
>recognise the input field as a text input. That *could* be with default
>text, but could be any number of things, depending on what makes sense
>for that user agent.
>
>For example, a screen reader might read out "text field" for an input
>(and I'm sure they do something like that, I don't have one to hand).
>Within a magnified visual display you could have a custom style for
>inputs, such as a dashed border and different background. My Google
>toolbar adds a yellow background to inputs which it knows the default
>answer for.
>
>>I'm thinking
>>of the still rather large numbers of people using technology which
>>simply does not recognize or report to the user an edit field.
>>Just  because a user agent or user agent at combination or two
>>does, does  not mean the issue is solved.
>
>I'm not going to play a numbers game - that doesn't help any
>accessibility argument. However, I'm sure we agree that there are people
>relying on screen readers, magnifiers, braille displays (if that's the
>right term?) and those without any assistive technology. (Obviously this
>list is far from inclusive, but just for arguments sake.)
>
>Having default text is beneficial to one group because of issues with
>the user agent, harmful to another group, and annoying to the general
>populace. It is also a hassle for those developing web sites, a
>practical issue.
>
>If this checkpoint were kept, it would probably wouldn't even help those
>who currently benefit, as the user agents are less likely to update, and
>the web at large would remain inconsistent (some people complying, many
>not).
>
>Apologies to the list for my stubbornness.
>
>Kind regards,
>
>-Alastair
>
>--
>Alastair Campbell         |  Director of User Experience
>t. +44 (0)117 929 7333    |  ac@nomensa.com
>
>Keep up to date with industry and Nomensa news, sign up to Nomensa
>newsletters:
>http://www.nomensa.com/news/nomensa-newsletters.html

... Creating implements of mass instruction.
Lloyd Rasmussen, Senior Staff Engineer
National Library Service for the Blind and Physically Handicapped
Library of Congress    (202) 707-0535   <http://www.loc.gov/nls>
HOME:  <http://lras.home.sprynet.com>
The opinions expressed here are my own and do not necessarily represent 
those of NLS.

Received on Tuesday, 9 May 2006 15:11:52 UTC