Should user agents be expected to expose the presence of an aria-current descendant?

Hey all.

During today's ARIA call we were discussing aria-current. The group
consensus includes the fact that aria-current can be applied to any
container. That's fine with me. And presumably the current item does not
have to be an immediate descendant of that container. Also fine with me.
My concern, however, is how an AT can identify what the current item in
a given container is in order to present that item to the user.

Consider a form with multiple steps. A content creator might associate
the current step (reflected by an image) with the form. That form will
not get focus; the child widgets in that form will. So a plausible chain
of events includes:

1. User presses the "Next" button
2. Focus moves to a text widget labeled "Address:"
3. The "Step 2: Billing Information" image has aria-current="true"

The screen reader is expected to say something like "Step 2: Billing
Information. Address: Entry."

It seems to me that in order to accomplish this the screen reader is
going to have to ascend the accessible tree -- possibly all the way to
the webview given that aria-current can describe any container. Then
having done so, the screen reader is going to have to tree dive looking
for the thing which has aria-current="true". The sad thing is that
there's probably no element with aria-current="true", so all of this
work is being done "just in case."

Having said that, what if a web dev did make use of aria-current -- and
not just once on the page, but multiple times? Once for the form (Step
2: Billing Information) and once for the site navigation (Exchanges and
Returns). Presenting both currents is not great, but it's not horrible
either. However assuming that the first located element with
aria-current="true" is *the* aria-current to present to the user would
be a mistake. An AT must be thorough.

What would make the life of an AT a lot simpler would be to ascend the
hierarchy looking for the ancestor which claims to have a "current"
descendant. If the AT ascends all the way to the webview without finding
anything claiming to have a "current" descendant, the AT can stop. No
need to tree dive "just in case." On the other hand, if an ancestor does
claim to have a "current" descendant, at least the scope of the
subsequent tree dive is limited: Odds are that ancestor is not the
webview, but some intermediate child element like the form. I'd also bet
that this intermediate child element is in a different branch of the
accessible tree than other elements which might also have a less
relevant "current" descendant (e.g. the site navigation bar). So the
first "current" found by the AT is probably the right "current." I'd
even wager that this intermediate child element doesn't have a huge
number of descendants. A minimal tree dive, while not ideal, is not
horrible.

So the question is how to expose the presence of a "current" descendant
on an accessible element -- if at all. During the call, three
possibilities were mentioned:

1. Make this something the author does. This was rejected by the group.
2. Make this something user agents do.
3. Make this something ATs do.

I'd really like it to not be option 3 for the reasons I described above:
A lot of work for very little benefit. I also acknowledge the reality
that option 1 is asking a lot for the authors. So what about option 2?

During the call, James Craig had a neat suggestion:

  use UA fast search to match
  currentElement.getElementsBySelector([aria-current="true"])

I initially thought James was pointing out that user agents should be
able to do this work quickly and efficiently **on behalf of the ATs**
using selectors. In other words, option 2 is totally doable and without
a lot of extra work being required by implementors. The subsequent
discussion, however, makes me think that James was instead pointing out
that User Agents have a mechanism in place through which an AT could
solve this problem for themselves (i.e. option 3).

James: Please clarify the bits I got wrong.

All: Thoughts?

Thanks in advance!
--joanie

https://www.w3.org/WAI/PF/Group/track/actions/1525

Received on Monday, 10 November 2014 21:36:56 UTC