E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Terence de Giere
Date: Thu, Jun 26 2003 9:02AM
Subject: Re: Accessibility of complex HTML forms
No previous message | Next message →

Candance Egan wrote:

Having done quite a bit of research into making accessible HTML
forms, I
feel quite confident in regards to simple forms but I am not so sure in
regards to complex forms...

An added note to Jukka's response regarding DHTML. Because some browsers
do not support client-side scripting server-side processing of the form
is essential. On the fly changes in a page generally cannot be read by
screen readers, although recently some technology like IBM Home Page
Reader has been able to extract certain information from JavaScript such
as links embedded in JavaScripted drop down menus. Clear instructions
about what to fill in or not fill in could help a lot as Jukka
mentioned. You could also use a modal approach to form filling with a
long form, using multiple pages, with the information appearing on
subsequent pages dependent on what is filled in on the previous pages.
This requires a server-side application.

The form should always work if the user turns off scripting in his/her
browser, or is filling in the form with a non-scripted browser like the
Lynx text browser. There should be no content or essential functionality
in the form other than trivial format that requires scripting. Client
side scripting can be added to augment the function of the form for the
typical user (for example, validating a particular field with immediate
feedback for an error, rather than waiting for a return page after
submission to report the error) but the server side process must always
back it up when it is unavailable.

Complex client-side scripting also increases the chance that users with
older browsers might have compatibility problems with the script. Long
scripts on the web page also increase download time, especially for
modem users, and long download times reduce usability.

By the way, one of the few free sites that has global web statistics
from a large number of sites has shown an interesting change, but it is
too early to tell if it a trend. Client-side JavaScript being
unavailable, that is not detected, over the past several years had
declined to a fairly steady 10 percent of users, that is, one out of ten
users would not be able to run scripting on a web page, down from 20 to
30 percent some years ago. In the past several months the number of hits
where JavaScript has not been detected has increased to 13 to 14
percent. I am not sure what this means - it might mean small device
users are accessing the web more, but I have no information beyond the
change in the statistic. It might be just normal fluctuations. The
sample was from about 300,000,000 visitors per month.

In many ways accessibility is a very simple model of web interaction. If
we go back about 10 years, most of the requirements for an accessible
web page were in place, and technically the web then was pretty
accessible because it was mostly text based. It is all the technology of
graphical browsers, client-side scripting, embedded applications, etc.,
that have been developed since then, along with the creative use of HTML
to create a graphical interfaces that has reduced accessibility. We need
to find creative ways to use these newer additions to enhance users'
experience and usability of a site without undercutting the basic simple
underlying structure that has made the web so universal.

Terence de Giere
= EMAIL ADDRESS REMOVED =



----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Gerard Corboz
Date: Thu, Jun 26 2003 9:06PM
Subject: Re: Accessibility of complex HTML forms
← Previous message | Next message →

Thanks everyone for your suggestions.

I have to say though that I like Peter-Paul Koch's solution the best. That
said though, his work around for accessibility or rather for the lack of
JavaScript seems like it would only work in some situations.

Is it a given that disabled users turn JavaScript off?

Would it be reasonable to warn a disabled user that the form is dynamic and
uses JavaScript but is accessible if JavaScript is turned off?

This way one could provide a solution which in a sense covers both
Peter-Paul Koch's solution (dyanamic form only showing relevant fields) as
well as Terence and Jukka's solution (show all forms with added instructions
to answer only particular questions).


Regards

Gerard Corboz
---------
Perform
Information Design Solutions
ph: 6214 0968
fax: 6214 0964
mobile: 0402 236 358
http://www.perform.net.au
Join our mailing list - http://www.perform.net.au/News/
---------

Important

The information transmitted in this email is for the use of the intended
recipient only and may contain confidential and/or legally privileged
material. If received in error, please delete all copies and advise the
sender. The reproduction or dissemination of this email or its attachments
is prohibited without the consent of the sender.


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Jukka K. Korpela
Date: Fri, Jun 27 2003 12:16AM
Subject: Re: Accessibility of complex HTML forms
← Previous message | No next message

On Fri, 27 Jun 2003, Gerard Corboz wrote:

> Is it a given that disabled users turn JavaScript off?

No, of course not. But it is a fact that they _may_ do so (or use
completely non-Javascript browsers), and may _need_ to do so.

> Would it be reasonable to warn a disabled user that the form is dynamic and
> uses JavaScript but is accessible if JavaScript is turned off?

No. Never refer to techniques if you can avoid it. Most people don't
even know what Javascript is. (This includes even a large number of Web
authors, who keep confusing it with Java, CSS, and other things.)

But it is possible, though tedious, to provide non-Javascript and
Javascript-enabled presentations in a single document, through judicious
use of Javascript-generated markup and <noscript> markup.

Dividing a large form into smaller parts via server-side interaction, so
that submitting one part causes partial processing of data and getting
back the next form, means a lot of work too. But it's generally the best
approach, since it works independently of browser settings and makes it
possible to request for corrections at an early stage. If you have filled
out a field in an unacceptable way, the sooner this gets reported to you
the better - and this is particularly important to people with cognitive
disabilities.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/