INPUT TYPE="file", speech output, & triggering mechanisms

*/ cross-posted to w3c-wai-ua and www-validator -- should i have used
wai-xtech ? /*

on friday, april 20, 2001, in a post with the subject line "Browse button on
forms", bruce wrote to the WCAG mailing list:

quote
It has just come to my attention that "local file browse" buttons are not
accessible with either JAWS or HPR.  Has this come up before?  Does anyone
know what is wrong?  Thanks.
For an example of such an inaccessible form, please reference URL:
<http://validator.w3.org/file-upload.html>
unquote

aloha, bruce!

the problem is in the INPUT TYPE defined for the "Browse" button:

<input type="file" name="uploaded_file" size="50" />

JFW simply doesn't recognize the INPUT TYPE="file" as anything other than an
"edit box", and, hence, does not include the triggering mechanism that
ostensively endows the user with the ability to select a file using the OS'
native file management system (if available)--the "Browse" button--in its
aural rendering of the document, nor in its navigation sequence...  lynx (at
least Lynx32 2.8.4dev.14) doesn't support the INPUT TYPE="file" either
(because it doesn't support HTTP-PUT natively), and hence doesn't even
render a placeholder for the INPUT TYPE it doesn't recognize...

according to the HTML4 spec, the "file" INPUT TYPE:

quote
Creates a file select control. User agents may use the value of the value
attribute as the initial file name.
unquote

likewise, the "file select" functionality is defined by HTML4 thus:

quote
This control type allows the user to select files so that their contents may
be submitted with a form. The INPUT element is used to create a file select
control.
unquote

this is the real root of the problem -- the "Browse" button is user agent
generated, not merely because the browsing mechanism is UA-dependent, but
because the file select control type that creates this functionality
("file") precludes the use of control types to create an explicit submission
mechanism (that is, "button", "image", "submit", etc.) -- the presumption,
therefore, is that when an author defines an INPUT TYPE="file" control type,
that INPUT element will cause the user agent rendering the page to create
both a text-entry field (into which one can type the URI of the file to be
uploaded and into which placeholder text can be automatically inserted using
the "value" attribute) AS WELL AS the explicit submission mechanism by which
the "Browse" functionality is invoked...

the problem, therefore, as i "see" it, is that the responsibility for
creating the triggering mechanism for the "Browse" functionality belongs to
the user agent, and depends upon the UA's ability to communicate with the
native file management mechanism provided by the OS on which it is
running...  JFW simply isn't privy to the informational loop (if i have
someone click on the "Browse" button, a standard Win2k "Choose File" dialog
is generated, which voices normally and acts as any other file management
dialog, but i can't independently invoke the "Browse" functionality since it
is transparent to JFW...  actually, i can get JFW to announce the "Browse"
button by navigating with JFW's speech cursor (which allows gross navigation
of a document, roughly analagous to what, in the trade, is referred to as
"land swimming"--that is, moving about an open space using one's arms both
as tentacles to feel what is before one, and as protective devices, to
protect oneself from unexpected [aren't they all?] obstacles...  so, if i
route the speech cursor to the "File" text-entry field, i can move to the
"Browse" button manually, and then use JFW's left-mouse click simulation
keystroke to trigger the "Browse" mechanism, but it is merely a matter of
luck that the "Browse" button occupied screen space that the speech cursor
was able to reach, that it was in close proximity to the text input field,
and that JFW was able to read the button's label...  i don't know whether IE
treats the "Browse" button as part of the chrome or as part of the DOM tree,
but however it is generating the "Browse" button, it is obviously
transparent to JFW & HPR...   perhaps someone from IBM and/or microsoft can
explain how (or if) the COM DOM handles the INPUT TYPE="file" (i.e. what
happens when it is encountered?  is the UA-generated button added to the DOM
tree, or is it part of the chrome?)

by the way, my primary ISP, hicom.net, offers a web-based interface which
uses the INPUT TYPE="file" mehanism to provide a "browsing" mechanism for
file attachments, but the front matter to the interface clearly states that
support for the "Browse" feature is browser-dependent (they recommend
upgrading to Netscape 2.0 in order to use it!)...

gregory.
-------------------------------------------------------------------
Chaos is a name for any order that produces confusion in our minds.
                                                -- George Santayana
-------------------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
                           http://www.hicom.net/~oedipus/index.html
-------------------------------------------------------------------

Received on Friday, 20 April 2001 12:30:36 UTC