- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Mon, 10 Nov 2014 19:21:15 -0500
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, "LWatson@PacielloGroup.com" <LWatson@PacielloGroup.com>, 'W3C WAI Protocols & Formats' <public-pfwg@w3.org>
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 00:21:50 UTC