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

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

No problem, this can easily be done by adding aria-describedby on the form field that focus is set to, so that the step is automatically announced at the same time as the form field label. Then, the developer can optionally remove the aria-describedby attribute or set it to null so that this only happens once when it receives focus.


-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Monday, November 10, 2014 4: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 19:17:07 UTC