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

Granted, but it's rarely that simple.

Joanie's example of the Amazon checkout process is a good one for this, which includes the step information buried within about a hundred header navigation links, and there is no declarative programmatic means for an AT to automatically parse and pick out the relevant text within all of that chaff.

Also, when a full page refresh occurs, the whole page is typically parsed by the AT, not just the new content.

Alternately, when dynamic changes occur, such as within a dynamically displayed wizard, the step information is just part of the textual information, and the labelling mechanism whether this is included within a heading or region name, is not reliably conveyed automatically, and may not even be present within the same top level container element as the rest of the wizard content.

It would be nice if ATs were smart enough to do all of these things automatically, but until we have AI built into ATs, I think we are going to have a long wait.


From: Matthew King [mailto:mattking@us.ibm.com]
Sent: Tuesday, November 11, 2014 4:40 PM
To: Bryan Garaventa
Cc: Joanmarie Diggs; LWatson@PacielloGroup.com; 'W3C WAI Protocols & Formats'
Subject: 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<mailto:mattking@us.ibm.com>



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