- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Sat, 8 Nov 2014 00:24:09 +0000
- To: Matthew King <mattking@us.ibm.com>
- CC: W3C WAI Protocols & Formats <public-pfwg@w3.org>
- Message-ID: <d5a755b2b12142c5af465d3862c3afe0@BY2PR03MB347.namprd03.prod.outlook.com>
I just ran some tests, and it actually does work well in FF if you don't follow the APG. Specifically where it states: "A non-modal dialog is one which is displayed and focusable at the same time as the application which invoked it. Also like the modal dialog, focus via the tab and shift-tab key must be maintained within the dialog. However, a non-modal dialog should have a keyboard mechanism to return focus to the application while leaving the dialog open." If you ignore the part about the tab and shift+tab keys, you can navigate out of a non-modal dialog, but if you do follow the guide, then you cannot; being trapped within the container using JAWS. Granted Escape can close a dialog and return focus, but if this is the only mechanism for achieving this, then it negates the guidance "a non-modal dialog should have a keyboard mechanism to return focus to the application while leaving the dialog open" I guess this should probably be clarified further while we work on the guide. From: Matthew King [mailto:mattking@us.ibm.com] Sent: Friday, November 07, 2014 3:53 PM To: Bryan Garaventa Cc: W3C WAI Protocols & Formats Subject: RE: @inert and @aria-inert for disambiguating modal states Which JAWS behavior is inconsistent with the APG guidance on non-modal dialogs? The guidance does not say what AT should do. But, it does say: "Also like the modal dialog, focus via the tab and shift-tab key must be maintained within the dialog. However, a non-modal dialog should have a keyboard mechanism to return focus to the application while leaving the dialog open. " Assuming such keyboard function is provided by the application, when it is invoked, I assume JAWS would switch between 2 different virtual buffers: one containing the dialog content and one containing other application content. Of course, whether or not the screen reader operates in this manner or some other is the prerogative of the screen reader vendor. I would personally find such behavior very beneficial and analogous to comparable desktop experiences. Matt King IBM Senior Technical Staff Member I/T Chief Accessibility Strategist IBM BT/CIO - Global Workforce and Web Process Enablement Phone: (503) 578-2329, Tie line: 731-7398 mattking@us.ibm.com<mailto:mattking@us.ibm.com> From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> To: Matthew King/Fishkill/IBM@IBMUS, Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org<mailto:public-pfwg@w3.org>> Date: 11/07/2014 03:18 PM Subject: RE: @inert and @aria-inert for disambiguating modal states ________________________________ Matt, would it be worth filing a bug with FS regarding the handling of role=dialog in FF? This functionality goes against the guidance at http://www.w3.org/TR/wai-aria-practices/#dialog_nonmodal From: James Nurthen [mailto:james.nurthen@oracle.com] Sent: Thursday, November 06, 2014 12:40 PM To: public-pfwg@w3.org<mailto:public-pfwg@w3.org> Subject: Re: @inert and @aria-inert for disambiguating modal states I see the need for a developer to state whether their dialogs are modal or not. In the Modal case, for AT which uses a virtual buffer model, it would allow the AT to prevent the user from interacting with the base page using the virtual buffer when a modal dialog is open. If the dialog is not modal then AT should allow interaction with the base page. JAWS does this today for the dialog role but IMO this is not correct because dialogs do not have to be modal. I don't care how this problem is solved. aria-inert seems like one possible solution, but alternatively there could be an aria-modal property on the dialog role - or even a new role entirely for modal dialogs. Regards, James On 11/6/2014 10:08 AM, Dominic Mazzoni wrote: On Thu, Nov 6, 2014 at 10:01 AM, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote: On Nov 5, 2014, at 11:17 AM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote: > Dominic, @inert is an indicator of state - like aria states and properties. It does not have to do the actual function. This is a false statement. @inert is useless if it does not provide the function. By the same logic, I can see no possible way that @aria-inert would be useful or even possible to implement. Exactly, I don't see any purpose in @aria-inert that reports to AT and doesn't actually do anything. What is the AT supposed to do if events fire on nodes that have aria-inert=true? -- Regards, James [Oracle]<http://www.oracle.com/> James Nurthen | Principal Engineer, Accessibility Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> Oracle Corporate Architecture 500 Oracle Parkway | Redwood City, CA 94065 [Green Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment
Attachments
- image/gif attachment: image001.gif
- image/gif attachment: image002.gif
Received on Saturday, 8 November 2014 00:24:44 UTC