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

Aria-current is an accessible alternative to what is frequently presented through CSS styling alone, in a way that is entirely inaccessible to assistive technologies.
I don't think it needs to perform magic (although nobody would object to it).
I think if we attached too much functionality and capacity to what started out as a simple attribute, we might start getting muddled in the implementation details.
I think being able to use this attribute to indicate currently active element in a set of elements, and leave the implementation and features of that up to assistive technologies, that should be sufficient.
After all, in most cases moving to the next steps in a user flow usually requires loading a new page, in which case an accessible page title will back up the change in the aria-current attribute.

-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Monday, November 10, 2014 7:21 PM
To: Bryan Garaventa; LWatson@PacielloGroup.com; 'W3C WAI Protocols & Formats'
Subject: Re: Should user agents be expected to expose the presence of an aria-current descendant?

Hi Bryan.

On 11/10/2014 06:10 PM, Bryan Garaventa wrote:

[...]

> and there is no need to convey this unless the element is encountered during navigation by the user.

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. Which brings me to:

> So in your example, when the step changes and focus is set to the 
> container,

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

--joanie

Received on Tuesday, 11 November 2014 03:27:21 UTC