- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 21 May 2015 13:47:04 -0500
- To: Dominic Mazzoni <dmazzoni@google.com>
- Cc: "Gunderson, Jon R" <jongund@illinois.edu>, Matthew King <mattking@us.ibm.com>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
- Message-ID: <OFAF162AF4.763BC56D-ON86257E4C.00663C48-86257E4C.00672FD3@us.ibm.com>
I see your point. When working with Freedom Scientific they made it so that interactive controls would not have the keys stolen. For example, a drop menu button <div role="button" aria-haspopup="true"> does respond to an arrow key without stealing the key and moving the point of regard in the virtual buffer down a row. We did not consider the basic buttons when we added that text. We also were not adding the aria-interactive feature to buttons, checkboxes, and radio buttons. So, we should restrict that text. Rich Schwerdtfeger From: Dominic Mazzoni <dmazzoni@google.com> To: Richard Schwerdtfeger/Austin/IBM@IBMUS Cc: Alexander Surkov <surkov.alexander@gmail.com>, "Gunderson, Jon R" <jongund@illinois.edu>, Matthew King/Fishkill/IBM@IBMUS, "W3C WAI Protocols & Formats" <public-pfwg@w3.org> Date: 05/21/2015 11:53 AM Subject: Re: aria-interactive and the authoring/debug process problems On Thu, May 21, 2015 at 7:02 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: Alex, for ARIA 1.1 we are going to limit the use of aria-interactive. By default, widgets are considered to be interactive. That isn't consistent with the current text of the spec. It says "When a user navigates an element that has aria-interactive set to "true", assistive technologies that intercept standard keyboard events should switch to a mode that passes keyboard events through to the user agent." However, that's not currently how Windows screen readers behave. Buttons, checkboxes, radio buttons, etc. are all "widgets", but screen readers do NOT switch to a mode that passes keyboard events through to the user agent now when elements with those roles are focused, even though that's sometimes what web application authors would like them to do. It'd be most accurate to say that the following roles are already interactive: textbox, combobox, spinbutton, listbox, tab, menubar, menuitem, treeitem, gridcell However, these are not: button, checkbox, radiobutton, link (We should double-check that list. I'll be happy to test it with JAWS, NVDA, and Window-Eyes and figure out the current behavior.) If we indeed want assistive technologies that intercept standard keyboard events to switch to a mode that passes keyboard events through to the user agent, we should allow authors to change a button to aria-interactive=true. - Dominic
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 21 May 2015 18:47:38 UTC