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

Does IE put the 'browse' button in the DOM or only to the screen through MSAA?

The INPUT type="file" element is a bit different, in that legal user inputs
here are not identified by type, strictly speaking, but by class.  Any object
with a 'copy' method (provided by a file system in the typical legacy-friendly
OS) is a legal selection, without regard to what is in it.

Windows has the sub-session window labeled well.  The operation that the user
should be offered is to _select a local file_.  Naming the file and browsing
the file catalog are two ways to do it.  The trick is that somehow the
implementation of a combo box for the one HTML element screws up communication
between the IE module and the front end as to what actions are available.

Has anybody tried this with Window-Eyes?

Al

PS (notes):

terminology: Please don't call the action of invoking the file catalog
browsing
a 'submission.'  In a forms context, this term is best be reserved for
providing the answers to the questions to the recipient indicated in the
ACTION
of the form.

process (keyword = xtech):  My textbook answer would be to reply on the list
where the discussion is active already with copies to the chairs of any other
groups you think are implicated.  But there is no solid basis in experience or
CG consensus for any specific guideline on this point.

theory:  Wow, input (type=file) is a barn-door escape from "accessible by
construction" as big as scripting!  There is no schema knowledge or control at
all over what can be included here.
Do internet appliances let server thunks create files on your device?  So
is it
possible that this is usable on an internet appliance?

At 12:31 PM 2001-04-20 -0400, gregory j. rosmaita wrote:
>*/ 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>http://validator.w3.org/file-up
load.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>http://www.hicom.net/~oedipus/inde
x.html
>-------------------------------------------------------------------
>

Received on Friday, 20 April 2001 13:50:50 UTC