- From: Greg Kraus <greg_kraus@ncsu.edu>
- Date: Tue, 11 Sep 2012 14:07:56 -0400
- To: "Schnabel, Stefan" <stefan.schnabel@sap.com>
- Cc: Alexander Surkov <surkov.alexander@gmail.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, Steve Faulkner <faulkner.steve@gmail.com>, W3C WAI-XTECH <wai-xtech@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, Marco Zehe <marco.zehe@googlemail.com>, James Teh <jamie@nvaccess.org>
FWIW, in some recent testing I have done with the dialog and alertdialog roles, I have noticed a difference in implementation in JAWS in IE. JAWS in IE does not automatically announce values of text input elements that are children of an element with role="dialog" when the input element receives focus. This is true for pre-populated values and values the user enters into the fields. If the input elements are children of an element with role="alertdialog" everything is read as expected. I think this is probably a bug in JAWS and I have reported it to Freedom Scientific. Since the issue of the appropriateness of alertdialog came up I just wanted to put this out there. Here is a sample page demonstrating it. http://accessibility.oit.ncsu.edu/dev/jaws/debug/role-dialog/ Greg -- Greg Kraus University IT Accessibility Coordinator NC State University 919.513.4087 greg_kraus@ncsu.edu On Fri, Sep 7, 2012 at 7:47 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote: > Alex, > > maps perfectly for me: > > additional" aria-dialogtype=Error/Warning/Info " -> STATE_SYSTEM_ALERT_HIGH/MEDIUM/LOW > > I remember seeing those using Inspect32 with standard windows dialogs in the states enum listed, so I don't know what you mean with " but they weren't ever implemented." > > Stefan > > > -----Original Message----- > From: Alexander Surkov [mailto:surkov.alexander@gmail.com] > Sent: Freitag, 7. September 2012 11:39 > To: Schnabel, Stefan > Cc: Joshue O Connor; Steve Faulkner; W3C WAI-XTECH; Richard Schwerdtfeger; Marco Zehe; James Teh > Subject: Re: suggest deprecating alertdialog role in ARIA 1.1 > > As far as I know there's no difference. MSAA has states like > STATE_SYSTEM_ALERT_LOW/MEDIUM/HIGH but they weren't ever implemented. > I don't recall anything similar in other standards. Anyway many AT > APIs are extensible so it shouldn't be a problem. > > Alex. > > > On Fri, Sep 7, 2012 at 6:23 PM, Schnabel, Stefan > <stefan.schnabel@sap.com> wrote: >> Hi Josh, Alexander >> >> good point having an additional" type=Error/Warning/Info " parameter in ARIA 1.1 for dialog. >> But then we should go overboard and declare also modality (modal/non-modal dialog). >> >> Regarding API mappings, how is the situation in Windows MSAA and let's say typed MessageBoxes ? >> Isn't there a standard way to map these additional properties without borrowing from aria-label? >> >> Regards >> Stefan >> >> >> -----Original Message----- >> From: Joshue O Connor [mailto:joshue.oconnor@cfit.ie] >> Sent: Freitag, 7. September 2012 11:16 >> To: Schnabel, Stefan >> Cc: Steve Faulkner; W3C WAI-XTECH; Richard Schwerdtfeger; Marco Zehe; James Teh >> Subject: Re: suggest deprecating alertdialog role in ARIA 1.1 >> >> Hi Stefan, >> >>> It is not the fault of the ARIA spec that alertdialog is poorly supported in AT. >> >> I completely agree but devs need practical solutions right now.. not >> around the corner and to my mind anything that makes the practical >> accessible web development easier - is a good thing. >> >>> Role "alertdialog" has been invented to indicate simple ok/yes/no/cancel messageboxes in contrast to more >>> elaborated complex dialogs with role "dialog". >>> >>> Therefore, I recommend *NOT* to remove the role entirely, in contrary, it should even be extended to reflect the >>> *type* of "alert" dialog Error/Warning/Info etc. and its usage according to this should be reflected in the AP Guidelines documentation. >> >> Not a bad idea. However, I suggest removing it and actually using the >> role="dialog" as a generic role and allowing it to take the argument >> dialog Error/Warning/Info etc. >> >> Cheers >> >> Josh >
Received on Tuesday, 11 September 2012 18:09:10 UTC