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 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:39:42 UTC