WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus on adding/removing items

for

From: Robert Fentress
Date: Mar 23, 2015 10:28AM

Thanks, Sarah. Your analysis is helpful.

I agree that it is a usability issue, though, of course, it has particular
implications for accessibility. For instance, as you suggest, if an
interaction causes focus to be lost entirely or causes it to go to the top
of the page, requiring the user to navigate back to a widget from the start
of the page, I would think this would be very problematic. My first
thought was that this would cause a page to violate "WCAG 3.2.2 On Input" (
http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change),
since this would count as an unexpected change of context (
http://www.w3.org/TR/WCAG20/#context-changedef). However, the
Understanding SC 3.2.2 working group note (
http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html)
indicates that activating a button is specifically excluded from the list
of things counting as "Changing the setting of any user interface
component." Would a page that did this technically violate any WCAG 2.0
standard that you are aware of? Perhaps SC 3.2.5 would be relevant (
http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html)?
What do you think?

I ask because I am performing an internal review of a third-party web
application for accessibility and in several instances focus is lost in
this way. In my report, I would rather have some specific success
criterion to point to, so it is not just my opinion about a usability
issue.

Also, I would like to be able to recommend what the best practice would be
in these sorts of situations. Right now, I'm thinking the best algorithm
for deletions would be set focus to the grouped item immediately following
the item deleted (after a confirmation dialog, which I left out to simplify
the example), unless there are no more items in the list, in which case,
focus should be set on the add button. We don't have the resources to do
formal usability testing, so I kind of have to run the scenario in my own
head. Here is my thinking:

After deleting an item, what is the user most likely to want to do? It
might be most reasonable to assume that they want to do something with the
next item in the list. What could they do? Well, in the example given,
they could read the link text, follow the link text to view or edit the
details of the item (unspecified, but assumed), or delete the item. So,
focusing on the item as a whole, rather than on any component within it
might be the best balance of directed guidance and flexibility. The user
might also want to add an item, of course, but moving the focus there would
seem to be more disruptive, and require more navigation to get to the other
things the user might want to do. Focus could also be moved to the main
container for the items, $("#items"), but, again this seems to be
disruptive, in that it moves the user further away from where they were at
the initiation of the delete action.

Best,
Rob

On Wed, Mar 18, 2015 at 4:56 PM, Bourne, Sarah (ITD) <
<EMAIL REMOVED> > wrote:

> Rob,
>
> Where the focus should go is more a usability issue than an accessibility
> requirement per se, and may requiring some testing by users to see if
> you've got it right. As a general rule, you want to put focus back to
> where the user was in the flow of the page. If it goes to the top of the
> page, for instance, a keyboard-only user would have to tab all the way back
> to "items" to continue item management.
>
> Since you can't put them back on the delete button once an item is
> deleted, perhaps it could be replaced with a confirmation statement (maybe
> with an un-do action even) that the item was deleted. Lacking that, I would
> think it should go to the next element - the next item link if there is
> one, or to the add item button. But user testing might show that taking
> them to the top of the list when at the end is more useful.
>
> I can't speak to exactly which ARIA attributes you should use, but I
> agree with Birkir that using list elements for the items would improve
> usability, and you would need something so the list and count is updated
> when items have been added or deleted.
>
> sb
> Sarah E. Bourne
> Director of IT Accessibility, MassIT
> Commonwealth of Massachusetts
> 1 Ashburton Pl. rm 1601 Boston MA 02108
> 617-626-4502
> <EMAIL REMOVED>
> http://www.mass.gov/MassIT
>
>
>