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

Actually, Home Page Reader is rendering File: [Browse button.] in its text
view  and speech. When the user presses Enter to activate the browse
button, the Windows Choose file dialog is displayed. When the user has
selected a file and presses Enter, HPR fills in the text field with the
filename and renders, for example,  File: [C:\my documents\hpr30demo.htm:
Browse button.] in the text view and speech.

Cathy Laws

IBM Accessibility Center, 11400 Burnet Road,  Internal Zip 9151, Austin,
Texas 78758
Phone: (512) 838-4595, FAX: (512) 838-9367, E-mail: claws@us.ibm.com, Web:
http://www.ibm.com/able


"gregory j. rosmaita" <oedipus@hicom.net>@w3.org on 04/20/2001 11:31:41 AM

Sent by:  w3c-wai-ua-request@w3.org


To:   <w3c-wai-gl@w3.org>, <Bruce.Bailey@ed.gov>
cc:   <w3c-wai-ua@w3.org>, <gerald@w3.org>, <www-validator@w3.org>
Subject:  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 13:32:40 UTC