W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

RE: INPUT TYPE="file", speech output,

From: mark novak <menovak@facstaff.wisc.edu>
Date: Mon, 23 Apr 2001 16:37:09 -0500
Message-Id: <v01540b1bb70a4b6df54d@[]>
To: jim@jimthatcher.com
Cc: w3c-wai-ua@w3.org
hi Jim (see MN below):

>You have heard from Cathy Laws that the Browse Button is recognized with HPR
>and so you can conclude it is in the DOM since that is where HPR gets the
>data to speak.

MN:  I'm not disagree'ing with anything Cathy said, but I still do not
understand "exactly" where the "browse" button is on this scenario.  Is there
a chance that HPR "understands" the INPUT TYPE="file" and creates the
button in its' DOM?  (not even sure I'm asking that correctly...)

>But HPR is missing something. As a sighted user, I can type
>in a file designation in the edit field. I think that is an HPR
>implementation fault (design defect), not seeing that they should also
>provide a text entry field along with the browse button. It isn't an
>accessibility fault, however, since the browse button is adequate.
>I tried Window-Eyes which relies on MSAA, as I understand it. Neither the
>Browse button nor the text entry field are known to them - but please note I
>am not a Window-Eyes expert. That, in my opinion (and interpretation), is a
>bug for MSAA.

MN:  based on the quick test I did prior using the MSAA object inspector,
i'd agree that the button is not properly exposed in IE for MSAA to

>As I understand it, JFW parses HTML and, like HPR, JFW has a flaw in their
>interpretation of the validate page, only finding the edit field, not the
>browse button.
>In all three cases, it seems to me it is not an issue for the content
>provider, but for the assistive technology instead.

MN:  until I understand this, i'm not ready to say that.

Received on Monday, 23 April 2001 17:33:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:30 UTC