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 06:22:52 UTC