RE: Objectives of action 1490

"1. Allow combobox to popup grid, tree, and dialog in addition to listbox."

I understand Grid, Tree, and Listbox, since these rely on simple arrow key navigation which can be controled using both techniques of retaining focus on the role=combobox element or by moving focus into this control manually.

However, can you explain how this is supposed to work for Dialog if literal focus remains on the role=combobox element?

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

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 Wednesday, 17 February 2016 18:55:18 UTC