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

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
query/find.



>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.

mark

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