RE: Form Problem

Thanks everyone of ryour input.  It loooks like I'm flat out of luck
trying to get the user to upload their own images. <sad face>  Guess
we'll do it by e-mail.  I was hoping.

Warmly,
Hy

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
Behalf Of Jukka Korpela
Sent: Tuesday, September 10, 2002 12:35 AM
To: w3c-wai-ig@w3.org
Subject: 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 12:02:05 UTC