Re: <noscript> interfere with screen readers?

At 16:25 -0400 6/1/01, Shifra Raffel wrote:
>Sorry for a slightly newbie question. On a program I'm building, we're using
>the following format, putting the "submit" button inside a <noscript> tag to
>hide it from all but non-Javascript users, for design reasons. Can anyone
>tell me, does this interfere with the accessibility? Many thanks for word.
>
><form method="post" action="/cgi-bin/something.cgi">
>    <select onchange="JavaScript_does_cgi's_thing_unless_scripting_off">
>      <option value="none" selected="selected">Click below:</option>
>      <option value="foo">Foo</option>
>      <option value="bar">Bar</option>
>   </select>
>  <label accesskey="s"><NOSCRIPT><input type="submit" value="do
>something"></NOSCRIPT></label>
></form>

I am always happy to see a functional alternative between NOSCRIPT 
tags for non-javascript users. However, I would also provide some 
method (outside of the NOSCRIPT tags) for people to access an 
alternative menu. My reasons have nothing to do with screen readers, 
so please forgive me for straying from the question.

Javascript SELECT menus that instantly redirect users with the 
ONCHANGE event handler are an accessibility barrier for many people 
with motor impairments (and there is no reason to assume that these 
people will have javascript turned off in their browsers). Menus of 
this sort cannot be used with keyboard-only input by many people; 
ALT+arrow works on IE Windows, but not on Netscape or IE Mac. 
Moreover, the community of people who cannot use a mouse includes a 
large number of temporarily disabled and newly disabled people (think 
hand injury or repetitive-stress disorder) who are not likely to know 
the alt-arrow key combination. Nor will they know the difference 
between client-side and server-side programming, so the fact that 
other (server-side) menus they encounter work fine with simpler 
keyboard input means that they are not likely to stumble across the 
ALT-arrow solution by trial and error; rather, they will just be 
confused as to why some menus "work" and others don't. (And those 
with severely restricted hand mobility might have difficulty 
executing the key combination even if they know it.)

As the discussion below demonstrates, even experienced users of 
assistive technologies can be thrown and frustrated when their 
expectations about a user interface turn out to be wrong:

----------- begin quoted text------------------
http://www.w3.org/WAI/UA/WAI-USERAGENT-TECHS-19991005/

Point C: As a speech user, I am constantly frustrated and misdirected 
by the use of javascript and event handler controlled pseudo-forms, 
wherein the user is presented with a menu (in the form of a listbox 
in GUI browsers), and is redirected to a different viewport upon 
selection of an OPTION.

PROBLEM STATEMENT FOR POINT C:

The markup behind such pseudo-forms is a mix of javascript (in 
particular the "function switchpage(select)" command) and HTML FORM 
controls, which utilize HTML4's event handler script attributes (in 
particular the "onchange" event handler attribute has been defined. 
An example (gleaned from the document source for one Web site follows:

   <SELECT NAME="condition" onchange="switchpage(this)">

When such a menu is encountered by a Web surfer who is using speech 
synthesis in conjunction with a javascript enabled user agent, his or 
her instinctual reaction will be to use the UA's navigation mechanism 
(usually the up and down arrows) to review the available OPTIONs. 
However, each time a new OPTION is displayed, the user is abruptly 
taken to a new viewport. Conversely, if one is using a user agent 
that does not support javascript (or has javascript support 
disabled), then the menu is displayed, but since there is no SUBMIT 
mechanism associated with it, there is no mechanism by which one can 
use the menu to quickly switch viewports - the apparent purpose of 
this type of pseudo-form. And while one can avoid having the viewport 
abruptly changed when encountering the menu (at least in the Windows 
environment) by using the ALT-LEFT-ARROW keystroke to display the 
menu in a drop-down list, (a) very few users know this keystroke, and 
(b) when one encounters a listbox on a page in an aural environment, 
one usually assumes that he or she is navigating a valid FORM, in 
which there are no unexpected side effects to perusing the contents 
of a SELECT menu using the arrow keys
----------- end quoted text------------------

I would add that people with any degree of shakiness or eye-hand 
coordination difficulty (the elderly, the slightly arthritic, the 
hung-over*) can encounter difficulties with javascript menus because 
they often let go of the mouse on the wrong choice and have to use 
their BACK button to correct their mistake. Having seen this happen 
on many occasions, I'm no longer convinced that menus using an 
ONCHANGE event handler are as much of a time-saver for the user as I 
once thought. And while the absence of a submit button usually makes 
for a more aesthetically pleasing and slick page, I am now reluctant 
to let my design considerations override accessibility concerns.

Apologies for the length of the above.

Jo

(* I know that the hung over are not yet a protected group, but we're 
working on that.)

--
Jo Miller
jo@bendingline.com

Received on Saturday, 2 June 2001 09:57:03 UTC