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

Joanmarie Diggs wrote:
"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."

If I understand correctly, aria-current would be applied to the current item, not nescessarily to its container. For example the link that represents the current page within a navigation block, or the image that represents the current chunk of a flowchart.

"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."

If the steps of the form were presented as a progress indicator, it would be appropriate to use aria-current to indicate which step was currently displayed. I don't believe it would be appropriate to use aria-current to indicate the current step, without the context being available.

Léonie.

-- 
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup

-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: 10 November 2014 21:36
To: W3C WAI Protocols & Formats
Subject: 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:54:14 UTC