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

Joanmarie Diggs wrote:
"If there's no expectation that the step will be presented unless navigated to, that indeed makes my life much easier. Though I think it potentially makes the value of aria-current less powerful. In my experience the current step in a process (filling out a form, tracking a
package) are things you won't encounter unless you start from the top of the page and work your way systematically down to the stuff you want to interact with."

I think this is ok from a UX point of view. The chances are that you'll navigate to the container in question in the normal course of things anyway, and aria-current will just tell you which of the things in that group is the current one.

"In my example, when the step changes, focus is not set to the container; focus is automatically set to the first input field (Address) of the new step (Step 2. Billing Information). Sighted users see what step they're in by glancing above the form fields (probably, anyway. It might be in a
sidebar.) For a user who is blind to accomplish the same thing, that user has to leave the focused form field and go looking for that progress indicator non-visually and then return to that form field to fill it out. Wouldn't it be nice(r) if the screen reader could do the glancing up for the end user so that user can remain in the focused field and immediately fill it out because his/her screen reader automatically announced "Step 2. Billing information"?"

It would, but by the sounds of things that's adding a degree of complexity we could probably do without. Out of curiosity, would it be difficult for a screen reader to treat aria-current in the way it does a landmark role (for example)? I'm thinking about the ability to move to a landmark with a shortcut and/or call up a dialogue listing all the landmarks on the page?

Léonie.
 
 
-- 
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup

Received on Tuesday, 11 November 2014 09:44:20 UTC