Re: accessible forms

Imagine a directory http://www.google.com/dirhp?hl=en  with drop down lists.
how would we navigate it?
it would certainly be faster.

if there is an escape key, it is important that it is the same for all
applications,
Having to select a 'dummy value' is not transparently obvious, authors
frequently assume that there list are 'complete'.
One may well wish to tab thru the forms, to get a feel for the document.

Tab is not sufficient in itself. flicking thru the pages of a book is a very
different activity to perusing the contents or index.
tab is not well able to handle both these activities.

If we are to leave it to the author to create the 'semantic' equivalent of
these activities, the least we can do is provide decent accessible examples.
There are very few available on the web. (indexes frequently get rather
large)

how does one efficiently search a dictionary,or encyclopedia using hpr or
another screen reader?
that is in the sense of browsing one, ie noticing the juxtaposition and
relation of words related to their spelling(which surely enhances learning).
stumped, well the reason is staring us in the face, the interface is
deficient.

The peepo script* for using the keyboard is an important innovation(though
certainly a very small part any possible solution.)
I'm facing a very similar problem. Currently whatever letter you press you
go to the page for that letter, wherever you are.
in the future, due to the growth of peepo, your destination will change
depending where you are. This is a subtle but complex difference.
One that I am not sure, will be readily accepted or understood, but which is
to be tried and tested.

For nearly 2 years, we had a system where the 'enter' key was used as an
'escape' so that the next key was interpreted as a drop down the list rather
than a page move.
However it was not a standard, and involved too much training.
http://www.peepo.com/alf/a.html is a working example. type a letter and you
move a page. hit the enter key, then a letter(one related to an image
displayed,) and you visit that specific, offsite link.
Whilst this version did not pan-out, something similar could possibly be
viable.

It may be helpful to compare this with predicitve text messaging?

thanks

jonathan

*typing a letter at the keyboard, selects a page to view, ie A is for apple
unless one is in a data input field, the a-z keyboard is effectively
dead-space, which is a peculiar use for it.

nb: obviously it is important that 'other' comes first, and this may well be
a necessary guideline/technique.


----- Original Message -----
From: "Charles McCathieNevile" <charles@w3.org>
To: "Chris O'Kennon" <chris@vipnet.org>
Cc: "'jonathan chetwynd'" <j.chetwynd@btinternet.com>; <w3c-wai-gl@w3.org>
Sent: Friday, June 21, 2002 8:21 PM
Subject: RE: accessible forms


>
> Well, with a list this big I would look for ways to break it up beyond a
> single menu (a list of 50 states is as frustrating as I ever want to deal
> with, since I live in "other - non-US" which is almost always at the end
of
> things I deal with).
>
> But there is technology that doesn't require this whole list to be
traversed.
> In Lynx (since the early 90s) as soon as you have selected something you
can
> move past the drop-down (unless you configure it otherwise, and even then
you
> can page through the list). Other tools do this - I would be surprised if
HPR
> doesn't.
>
> Cheers
>
> Charles
>
> On Fri, 21 Jun 2002, Chris O'Kennon wrote:
>
>
>   Is the problem, then, one of available technology?  Is there no way to
code
>   for an "escape" from a menu?  And, if someone uses a 200 item menu, will
>   they still conform to the guidelines, or is there a "You did something
too
>   annoying to conform" clause?
>
>   Chris O'Kennon
>   Commonwealth of Virginia Webmaster/
>   VIPNet Portal Architect
>   www.myvirginia.org
>   ______________________________________
>   "Until you have the courage to lose sight of the shore,
>   you will never know the terror of being forever lost at sea."
>
>
>   > -----Original Message-----
>   > From: jonathan chetwynd [mailto:j.chetwynd@btinternet.com]
>   > Sent: Friday, June 21, 2002 2:46 PM
>   > To: Chris O'Kennon; w3c-wai-gl@w3.org
>   > Subject: Re: accessible forms
>   >
>   >
>   > i've already suggested on many occassions that ~10 links is enough per
>   > page(or form in this case) if one is going to run to
>   > hundreds, then one
>   > certainly needs to design a way to break them up.
>   >
>   > w3 uses something in the navigation at the start of a page
>   > that allows one
>   > to jump across links, perhaps it could include a warning, ie
>   > 200 links.
>   > also one really wants an escape key.
>   >
>   > visual navigation needs a different design criterion to auditory.
>   > for instance at http://www.peepo.com i've arranged for the
>   > 'frame' content
>   > which is on every page (ie the alphabet) to frame the pages
>   > visually, but to
>   > be read last.
>   >
>   > in the interim, i'd recommend arranging for these long lists
>   > to be at the
>   > end of the page
>   >
>   >
>   > ----- Original Message -----
>   > From: "Chris O'Kennon" <chris@vipnet.org>
>   > To: <w3c-wai-gl@w3.org>
>   > Cc: <j.chetwynd@btinternet.com>
>   > Sent: Friday, June 21, 2002 7:15 PM
>   > Subject: accessible forms
>   >
>   >
>   > >
>   > > I read the client-side scripting draft [1] and the html
>   > techniques for
>   > wcag
>   > > 1.0 [2].  I don't see anything about coding drop-down menus
>   > so a user can
>   > > move from the menu to the next form field without having to
>   > tab through
>   > > everything else in the menu.  For example, the Virginia Commonwealth
>   > > Calendar [3] has several drop-down menus needed to access
>   > the government
>   > > meetings.  In order to select an agency, a screen reader
>   > would then have
>   > to
>   > > go through the rest of the options before the user could go
>   > to the next
>   > form
>   > > field.  Although this allows the application to be
>   > technically used, the
>   > > difficulty in going through 200 agencies makes it effectively
>   > inaccessible.
>   > >
>   > > Could this be addressed in a future draft of the
>   > client-side scripting
>   > > techniques?  Or is it already there and I just missed it?
>   > >
>   > > [1] http://www.learningdifficulty.org/develop/w3c-scripts.html
>   > > [2] http://www.w3.org/TR/2000/NOTE-WCAG10-HTML-TECHS-20000920/
>   > > [3] http://www.vipnet.org/portal/cgi-bin/calendar.cgi
>   > >
>   > > Chris O'Kennon
>   > > Commonwealth of Virginia Webmaster/
>   > > VIPNet Portal Architect
>   > > www.myvirginia.org
>   > >
>   > > ______________________________________
>   > > "Until you have the courage to lose sight of the shore,
>   > > you will never know the terror of being forever lost at sea."
>   > >
>   > >
>   > >
>   > >
>   > >
>   >
>   >
>
>
> --
> Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409
134 136
> W3C Web Accessibility Initiative     http://www.w3.org/WAI  fax: +33 4 92
38 78 22
> Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
> (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
France)
>

Received on Saturday, 22 June 2002 01:20:03 UTC