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

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

That would definitely work, but seems a bit complex to me. I don't think 
the developer should have to get so fancy given that all the needed info 
could be easily extracted and used by a screen reader that has learned how 
to use ARIA effectively. There is a lot of room, a lot of room, for 
improvement in how intelligently screen readers exploit ARIA.

Assuming only the following:

1. Step 2 is in the main content
2. Main content is labeled as step 2
3. Focus moved from step 1 to the input in step 2 either via a page load 
or dynamic update to main content in response to a user action.

The screen reader should have enough smarts to let the user know where the 
focus is and what has changed. It is up to the page author to stay out of 
the way and not throw in a bunch of extraneous events or other information 
that will stomp all over smart interpretation of the UI by the screen 
reader.

Note, for this use case, there is no dependency on aria-current.

Speaking of the "where am I glance" by a sighted user, none of the screen 
readers today have a good "where am I" function. Even the ancient Screen 
Reader 2 for OS/2, the first GUI screen reader, had a better "where am I" 
feature than anything out there now. It takes multiple and sometimes 
esoteric commands to learn much about where you are in most screen 
readers. There at least a half dozen commands in each screen reader that 
provide some form of "where am I" information, and it takes quite an 
astute user to put it all together.

Just in this example, in nearly every screen reader, it takes one command 
to learn the window title and application that has focus, another for the 
main content or page title (which should match the window title in a 
browser but may be different), another set of commands to decipher the 
current place with in the landmark region hierarchy, potentially another 
for the step in the wizard, and another for the label and contents of the 
input. And, if there were an ARIA description, or if labelledby is used, 
and if the user wishes to parse that information, even more gynmastics are 
required . The problem gets much worse if the user's focus is buried in a 
tree or complex grid.

This is all done with an easy glance by a sighted person. ARIA markup and 
practices make a very rich, efficient, and easily understood screen reader 
"where am I" function very feasible. There should be an easy way in all 
screen readers for the user to make an intelligent glance that is 
context-based (ie it takes into consideration the application, role, 
state, relevant properties, and the current state of the UI). The screen 
reader should assemble it in an easily understood and easily reviewed 
manner. ... At least that would be one of my priorities if I were 
designing improvements for current screen readers.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To:     Joanmarie Diggs <jdiggs@igalia.com>, "LWatson@PacielloGroup.com" 
<LWatson@PacielloGroup.com>, "'W3C WAI Protocols & Formats'" 
<public-pfwg@w3.org>, 
Date:   11/11/2014 11:17 AM
Subject:        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