RE: Form Problem

Hy Cohen wrote:

> We are trying to allow the
> uploading of images to our site through a form.  The problem is, the
> "brows" button will not read through my screen reader. 

I have no knowledge about how screen readers handle file input controls, but
I know other factors that make file input problematic. Although part of HTML
specifications since early 1997, and originally defined in 1995, file input
is still rather unsatisfactorily supported by browsers. For example,
Netscape 4 users will, after clicking on the Browse button, get a list of
files in some directory, with the view restricted to HTML files! They can
change the view, or filter, but the situation can be really confusing.
Besides, I think most users have rarely if ever used file input on Web
pages, so they would have to learn to use it, and this would mean some
problems even if the interface were good.

At a more general level, the practical accessibility of Web pages can be
affected by page elements that have "unusual" features in their
implementation in browsers, even if the implementation itself is accessible.
Anything substantially new means a challenge, a necessity of learning
something in order to use, and people's ability (and willingness) to learn
varies greatly. I don't know how this should be addressed in the WAI
guidelines, especially since any formulation that recommends care with the
use of constructs that users might be unfamiliar with could easily be
misunderstood or misrepresented badly. But to return to file file input...

I have written a discussion of the various problems (and partial solutions)
of file input: 
http://www.cs.tut.fi/~jkorpela/forms/file.html

As I mention there, it might be a good idea to provide alternative methods
of sending information that contains a file. It would be not only for people
who _cannot_ use file input; it would also be for people who find file input
in their browser too difficult, or simply don't know how it works.

At the simplest, you could tell people that they can send the image by
E-mail as an attachment, and you might set up a special E-mail account for
the purpose (perhaps to allow automated processing, perhaps just to keep
things separate). In that case, you might either ask them to provide other
information in the body of the E-mail message, or you might have a checkbox
in the form for telling that the image will be or has been sent separately,
hopefully with some way of associating images with form submissions (so you
might ask them to include some specific identifying information into the
E-mail message body).

> Here is the code:
>
> <input type="hidden" name="MAX_FILE_SIZE"  value="50000">
> <label for="logo">Logo of Organization or Activity (50kb  max.):</label>

To do my daily nitpicking, 50000 is probably the limit in bytes (octets),
and then "50 kb max." is not quite correct, since a kilobyte (kb) normally
means 1024 bytes. I would also be a little worried about the comprehensional
accessibility of jargon like "(50kb max.)"; "(50 000 bytes maximum)" might
be little better.

From a completely different viewpoint, namely security, I'd like to note
that putting the file size limit into a hidden field isn't safe. Anyone
could take your form, edit it, and submit 50 gigabytes of junk. So it's
better to have the size limit value built into the server-side form handler,
rather than passed as a parameter in the form data set.

-- 
Jukka Korpela, senior adviser 
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi/  My phone +358 9 4763 0397

Received on Tuesday, 10 September 2002 03:35:54 UTC