- From: Jukka Korpela <jukka.korpela@tieke.fi>
- Date: Tue, 10 Sep 2002 10:35:15 +0300
- To: w3c-wai-ig@w3.org
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