RE: Objectives of action 1490

Cynthia,

My two cents to TABBING OUT: 
Classy win combos yes (popup will close on TAB), classy win menus (such as Menu Button or Windows App Menu) NOT (menu popup won't close on TAB)

Is it so in all platforms?

- Stefan

-----Original Message-----
From: Cynthia Shelly [mailto:cyns@microsoft.com] 
Sent: Mittwoch, 17. Februar 2016 19:56
To: Richard Schwerdtfeger <richschwer@gmail.com>; Matt King <a11ythinker@gmail.com>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; ARIA Working Group <public-aria@w3.org>
Subject: RE: Objectives of action 1490

But, that's not how native comboboxes work. Why would a web combobox work like that?

-----Original Message-----
From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Wednesday, February 17, 2016 10:44 AM
To: Matt King <a11ythinker@gmail.com>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Objectives of action 1490

Make it possible so that ATs are aware if the resulting popup operates in a modal fashion so that they can let the user know that the keyboard tab navigation is limited to that popup window and the only way to get out is to complete a selection or hitting escape.  

Rich


> On Feb 17, 2016, at 12:39 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Note: the topic of the thread has changed with this reply.
> 
>> From action 1490[1], the objectives of the changes are as follows.
> 
> Objectives:
> 1. Allow combobox to popup grid, tree, and dialog in addition to listbox.
> 2. Allow aria-controls so screen reader users can see a rendering of 
> the popup in reading mode.
> 3. Remove ambiguities from the spec to improve understanding and 
> simplify authoring.
> 4. Do it all without breaking any existing implementations.
> 
> [1] https://www.w3.org/WAI/ARIA/track/actions/1490
> 
> Matt King
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
> Sent: Wednesday, February 17, 2016 10:12 AM
> To: Matt King <a11ythinker@gmail.com>; ARIA Working Group 
> <public-aria@w3.org>
> Subject: RE: ACTION-1490 Resetting the combobox discussion -- part 1 
> -- textbox/popup relationship
> 
> One thing I'm not clear on is why we are talking about completely 
> redesigning how ARIA Comboboxes work for ARIA 1.1.
> 
> This whole thread seems to be under the assumption that ARIA 
> Comboboxes are intrinsicly broken and we need to fix them, but they 
> already work when programmed accessibly.
> 
> The only issues that I'm currently aware of that role=combobox has, 
> are
> these:
> 
> 1. The use of role=combobox can't be assigned a Value in the 
> accessibility tree when applied to a simulated element. This is a 
> nice-to-have, but not a critical issue that requires total revamping.
> 
> 2. The necessity that aria-activedescendant can only be applied to 
> owned children, which is likely broader than just role=combobox 
> obviously, but it is something that is important not to require 
> because there will always be occasions when it's not possible or 
> desirable to make everything that this is applicable to an owned child 
> of a referencing parent container. This is especially true if event 
> bubbling is the only reason for doing this. And as I've already 
> demonstrated, this is already working in the browsers. It doesn't 
> require total revamping either, just a spec text change. Please correct me if I'm wrong.
> 
> That's about it. ARIA Comboboxes already work accessibly if you move 
> focus into the controlled component using JavaScript .focus(), at 
> which point you can use any keyboard paradigm you wish, then press Tab 
> or Enter or Escape or
> Alt+Up as desired to do whatever you want and move focus appropriately 
> Alt+after
> that.
> 
> The same is true using aria-activedescendant while focus remains on 
> the element with role=combobox, which correctly sets the accessibility 
> tree to point to the referenced element so that it appears to ATs that 
> this is currently the focused element.
> 
> If aria-modal is made a general property, I can see adding this to the 
> element that includes role=listbox, or whatever, if literal focus is 
> moved into that control for the purpose of navigation. This would then 
> instruct ATs that they need to keep Virtual Buffer navigation confined 
> within that content. In most cases, if these widgets are programmed 
> properly though, these should be in Forms Mode or Applications Mode anywhay for such widgets.
> 
> I'm confused by this Matt:
> 
> "When experimenting with this approach, I observed one problem that I 
> hope could be easily resolved. When the target of 
> aria-activedescendant is a textbox in Firefox or IE, JAWS and NVDA do 
> not track the caret position or selection in the textbox. I haven't 
> yet tried this on OS 10. I haven't found anything in the spec that 
> says whether or not this should work. And, I don't yet know if this is a browser or screen reader issue, or both."
> 
> Are you talking about using aria-activedescendant to point to an edit field?
> 
> This won't work, because the browser focus in the DOM is on the 
> element that has literal focus, and only in the accessibility tree 
> does it show that the referenced element has focus, and nothing in the 
> accessibility tree is directly editable nor can it then synchronize with the DOM.
> 
> To do something like this, it would probably require complete API 
> revamping, and I wouldn't recommend this as a general practice.
> 
> 
> -----Original Message-----
> From: Matt King [mailto:a11ythinker@gmail.com]
> Sent: Tuesday, February 16, 2016 10:22 PM
> To: ARIA Working Group <public-aria@w3.org>
> Subject: ACTION-1490 Resetting the combobox discussion -- part 1 -- 
> textbox/popup relationship
> 
> The various paths the action 1490 threads have taken have been 
> enlightening, and have made a variety of useful points.
> 
> Given the complexities, I would like to try breaking the big picture 
> down into smaller chunks to see if it will help simplify the process 
> of finding consensus without diverging into other topics that may be 
> very important but unessential to achieving the objectives of action 1490.
> 
> To start with, let's set aside all discussion of trees, grids, 
> dialogs, modality, and the meaning of autocomplete to focus on just 
> one element of action 1490 -- the textbox/popup relationship.
> 
> The action 1490 goal of modifying recommended practice for coding the 
> textbox/popup relationship pattern is simple: make it reasonable to 
> expect that screen reader users will be able to perceive both parts of 
> an expanded combobox, the textbox and the popup,  in reading mode. If 
> you have questions related to understanding the importance of this 
> goal, please start a separate thread on that topic so this thread  can 
> focus on the merits of technical solution options.
> 
> To simplify discussion, let's assume that the combobox is a textbox 
> and a listbox.
> 
> The issue with the ARIA 1.0 combobox pattern that includes aria-owns 
> on the textbox referring to the listbox is that the listbox appears to 
> be a child of the textbox. That essentially makes the listbox part of 
> the contents of the textbox; it is "owned" content, which in both DOM 
> and AX tree terms means it is "contained" content. Screen readers do 
> not, and could not without making unusual and special exceptions,  
> render the listbox outside of the textbox in a manner similar to what appears on the screen.
> 
> My initial proposal was to simply change the relationship between the 
> textbox and listbox from aria-owns to aria-controls. That opened a new 
> can of worms yielding several tangential concerns related to both 
> aria-controls and aria-activedescendant. It also didn't necessarily 
> lead to the desired simplification in implementation for screen readers.
> 
> So, I would like the group to consider a modification to my initial 
> proposal that I believe makes the related aria-controls and 
> aria-activedescendant concerns orthogonal to combobox.
> 
> This alternative proposal for ARIA 1.1 comboboxes is a small variation 
> on one of the patterns hinted at but not fully explained in the 1.0 
> spec. It is for the combobox to be a container element as follows.
> 
> <!-- collapsed state where focus is in the textbox --> <div tabindex="0" 
>  role="combobox"
>  aria-expanded="false"
>  Aria-activedescendant="tb">
>  <span id="tb" tabindex="-1" role="textbox" contenteditable>Type a 
> value</span>  <span aria-owns="lb"></span> </div> <ul id="lb" 
> role="listbox" style="display:none">
>  <!-- I am collapsed right now so I am not visible and do not have 
> content
> -->
> </ul>
> 
> <!-- expanded state where user typed something in the textbox and then 
> moved focus to the first option in the listbox --> <div tabindex="0"
>  role="combobox"
>  aria-expanded="true"
>  Aria-activedescendant="opt1">
>  <span id="tb" tabindex="-1" role="textbox" contenteditable>something 
> the user typed</span>  <span aria-owns="lb"></span> </div> <ul id="lb" 
> role="listbox">  <li id="opt1" tabindex="-1" role="option">Option 1 in 
> the listbox</li>  <li id="opt2" tabindex="-1" role="option">Option 2 
> in the listbox</li>  <li id="opt3" tabindex="-1" role="option">Option 
> 3 in the listbox</li> </ul>
> 
> This pattern:
> 1. Enables the screen reader rendering objective of action 1490.
> 2. Maintains the combobox as the owner of the listbox so the context 
> of the listbox is clear and easily determined by screen readers.
> 3. Eliminates concerns related to aria-controls and 
> aria-activedescendant that have been raised in response to the initial proposal.
> 
> Obviously, the use of aria-owns to enable the listbox to be in a 
> separate part of the DOM is optional. Instead, the listbox element 
> could also be included within the combobox div.
> 
> When experimenting with this approach, I observed one problem that I 
> hope could be easily resolved. When the target of 
> aria-activedescendant is a textbox in Firefox or IE, JAWS and NVDA do 
> not track the caret position or selection in the textbox. I haven't 
> yet tried this on OS 10. I haven't found anything in the spec that 
> says whether or not this should work. And, I don't yet know if this is a browser or screen reader issue, or both.
> 
> Does this alternative proposal help? Or, does it create new issues? 
> 
> Again, if you wish to start a conversation related to better 
> understanding the rationale for the stated goal, please spawn a separate thread.
> 
> Matt King
> 
> 
> 
>

Received on Thursday, 18 February 2016 09:22:09 UTC