WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus on adding/removing items

for

From: Whitney Quesenbery
Date: Mar 25, 2015 6:18AM


Where should the focus go: In the least disruptive place for the user:

- Causes the least redisplay of the page or movement within it
- Leaves them in familiar place, so they can maintain orientation
- Does not disrupt the task flow.

Typically, this should be either the item above or below the one just
deleted.

There are patterns for this sort of list management, even without a visible
"x" button to delete the item. I've seen it done both ways, and I've seen
programs that are smart enough to move through a list as items are being
deleted adjusting to whether the user is moving up or down in the list.

The usability problem is that if the list is being read top to bottom, the
familiar location is the item above, but this causes extra navigation.

Example. Consider this list:

Item One
Item Two
Item Three to be deleted
Item Four

If the user is tabbing (or using ArrowDown) through the list and deletes
Item Three, then Item Four is the next logical point for the focus to land,
following the navigation direction. If they are using Shift-Tab or ArrowUp
the reverse is true.

A visual reader is not thrown back to the top of the page, and neither
should the non-visual interaction.

The usability of the visual experience depends on how smoothly the program
manages the visual transition. In the example above, Item Four should be
able to slide up into position without disturbing the visual display above
the deleted item. The same should be true for a non-visual user.


On Tue, Mar 24, 2015 at 2:30 PM Cliff Tyllick < <EMAIL REMOVED> > wrote:

> Rob, I'm going to go out on a limb here and say that the problem is that
> loss of focus is not addressed by the guidelines.
>
> Focus order is (SC 2.4.3). Focus visibility is (SC 2.4.7). But not the
> simple case of, "Oops, nothing to focus on, so let's take it again from the
> top!"
>
> I guess we could stretch SC 2.4.8, Location, to cover loss of focus. If
> you can't find the focus, you can't tell where you are in the page. But
> that's Level AAA, and this seems like a Level A problem to me.
>
> Worse yet, no matter what success criterion I select for failing this Web
> content, it won't be a clear fit. And that means I could expect pushback
> from whoever I must tell, "Keep working. This isn't good enough."
>
> The problem is that we're trying to turn accessibility into a
> one-size-fits-all checklist. That's a problem because a checklist can't
> easily accommodate loose ends, and accessibility has many. And it's also a
> problem because the items we're using for checkpoints—the success
> criteria—are meant to document ways to succeed, not to pinpoint every
> possible way to fail.
>
> So what can we measure against? Instead of details, why not focus on the
> big picture? Use performance objectives:
> ' A person who is blind must be able to perceive, operate, and understand
> this Web page and its contents.
> ' A person who has low moderate vision must be able to perceive, operate,
> and understand this Web page and its contents.
> ' A person who is deaf must be able to perceive, operate, and understand
> this Web page and its contents.
> ' And so on.
>
> The Guidelines and Success Criteria could then be used as intended—as
> information to help project teams figure out likely solutions, not as
> absolute measures of sufficient accessibility.
>
> The ultimate measure of accessibility, then, would be a usability test by
> people for whom the feature being tested might be a barrier.
>
> Whether I could find a Success Criterion we could use to fail an
> inaccessible feature would be irrelevant. I would just need to note that
> our tester found it inaccessible and point the project team to information
> that might help them solve the problem.
>
> Because the big picture isn't that you should be able to complete some
> kind of paperwork to document that your site is accessible. The big picture
> is that your customers should find your content fully usable, regardless of
> their ability—so usable that they never realize that you had to remove a
> barrier that would have hindered them.
>
> Cliff Tyllick
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its
> fault.
>
> > On Mar 23, 2015, at 11:28 AM, Robert Fentress via WebAIM-Forum <
> <EMAIL REMOVED> > wrote:
> >
> > 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
> >>
> >>
> >> -----Original Message-----
> >> From: <EMAIL REMOVED> [mailto:
> >> <EMAIL REMOVED> ] On Behalf Of Robert Fentress
> >> Sent: Wednesday, March 18, 2015 11:00 AM
> >> To: WebAIM Discussion List
> >> Subject: Re: [WebAIM] Focus on adding/removing items
> >>
> >> Another option might be to have a separate element that had
> role="alert",
> >> which was updated every time something was added or removed from the
> item
> >> list. For instance, if you remove an item, you could have the alert
> read
> >> "Item deleted," or, if added "item added."
> >>
> >>> On Wed, Mar 18, 2015 at 10:46 AM, Robert Fentress < <EMAIL REMOVED> >
> wrote:
> >>>
> >>> Thanks for letting me know. Here is a link to the picture:
> >>>
> >>> https://drive.google.com/file/d/0B8U0tKKO3WMWVGptUDhfMnhKSk0/view?usp> >>> sharing
> >>>
> >>> On Tue, Mar 17, 2015 at 10:14 AM, Bourne, Sarah (ITD) <
> >>> <EMAIL REMOVED> > wrote:
> >>>
> >>>> Rob,
> >>>>
> >>>> Attached images don't make it through on this list service. Is there
> >>>> someplace you can post the image so you can give a URL instead?
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: <EMAIL REMOVED> [mailto:
> >>>> <EMAIL REMOVED> ] On Behalf Of Robert Fentress
> >>>> Sent: Tuesday, March 17, 2015 9:04 AM
> >>>> To: WebAIM Discussion List
> >>>> Subject: Re: [WebAIM] Focus on adding/removing items
> >>>>
> >>>> Birkir,
> >>>>
> >>>> Thanks for your response.
> >>>>
> >>>> Since the delete button is within the item being removed, I couldn't
> >>>> keep it on that delete button. Do you mean I should move it to the
> >>>> delete button in the other item?
> >>>>
> >>>> Also, what about live regions? Would this be an appropriate use case
> >>>> for those and, if so, what attribute values should I apply for
> >>>> aria-live, aria-atomic, and aria-relevant?
> >>>>
> >>>> Is there a set of standards or principles that you are going by in
> >>>> your recommendations or are they just based on your sense of things
> >>>> based on your experience? Hope that didn't sound rude; I just want
> >>>> to know, because then I could reference that for guidance later.
> >>>>
> >>>> Best,
> >>>> Rob
> >>>>
> >>>>> On Tue, Mar 17, 2015 at 8:37 AM, Robert Fentress < <EMAIL REMOVED> >
> wrote:
> >>>>>
> >>>>> Just noticed the background of the wireframe I attached was
> >> transparent.
> >>>>> Here is one where I've filled that in. Sorry.
> >>>>>
> >>>>> On Mon, Mar 16, 2015 at 4:33 PM, Birkir R. Gunnarsson <
> >>>>> <EMAIL REMOVED> > wrote:
> >>>>>
> >>>>>> My take on this:
> >>>>>> - If adding an item, move focus to the recently added item once
> >>>> complete.
> >>>>>> - If deleting one of multiple items, user should be notified to
> >>>>>> this, ideally by an accessible modal alert dialog, or at least
> >>>>>> using a live region with role="alert"
> >>>>>> I would suggest keeping focus on the delete button.
> >>>>>> - If deleting the only item on the page, alert user in the same
> >>>>>> way but put the user focus at the top of the page.
> >>>>>> If possible, keep items in a list markup so that users can quickly
> >>>>>> find out how many items are on the page (screen readers will
> >>>>>> notify user of the number of items in an ol or ul list).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On 3/16/15, Robert Fentress < <EMAIL REMOVED> > wrote:
> >>>>>>> Hello, all.
> >>>>>>>
> >>>>>>> Following up on my previous email regarding focus in rich
> >>>>>>> internet applications, I thought I'd provide an explicit
> >>>>>>> example. I'm attaching
> >>>>>> a
> >>>>>>> wireframe image to help make things clearer to the sighted. It
> >>>>>>> shows
> >>>>>> the
> >>>>>>> following:
> >>>>>>>
> >>>>>>> - A "Skip to content" link with id="skip" at the top of the page
> >>>>>>> - A large rectangle with id="items", which encompasses the
> >>>> following
> >>>>>>> items:
> >>>>>>> - Two rectangles, one following the other vertically, both with
> >>>>>>> class="item", one with id="item 1" and the other with
> >>>> id="item2".
> >>>>>>> Inside
> >>>>>>> each element with class="item" are the following:
> >>>>>>> - A link with class="itemlink"
> >>>>>>> - An icon button with class="delete"
> >>>>>>> - The last thing in the "items" element is a button, whose
> >>>>>>> value
> >>>>>> is
> >>>>>>> "Add Item" with id="add"
> >>>>>>>
> >>>>>>> The delete button causes an item to be removed from the list of
> >>>>>>> items,
> >>>>>> and
> >>>>>>> the "Add Item" button causes an item to be added to the bottom
> >>>>>>> of the
> >>>>>> list
> >>>>>>> of items.
> >>>>>>>
> >>>>>>> Here are my questions, using jQuery selectors to indicate
> >>>>>>> element
> >>>>>>> referenced:
> >>>>>>>
> >>>>>>> Deleting
> >>>>>>>
> >>>>>>> 1. With focus on $("#item1 .delete"), a click event causes
> >>>>>> $("#item1")
> >>>>>>> to be removed from the page dynamically. Where should focus
> >>>>>>> be
> >>>>>> placed?
> >>>>>>> Options:
> >>>>>>> 1. Perform no explicit focus-setting action and allow browser
> >>>>>>> to
> >>>> set
> >>>>>>> focus or not
> >>>>>>> 2. $("#items")
> >>>>>>> 3. $("#item2")
> >>>>>>> 4. $("#item2 .itemlink")
> >>>>>>> 5. $("#skip")
> >>>>>>> 2. With only $("#item2") remaining and focus on $("#item2
> >>>>>>> .delete"),
> >>>>>> a
> >>>>>>> click event causes $("#item1") to be removed from the page
> >>>>>> dynamically.
> >>>>>>> Where should focus be placed? Options:
> >>>>>>> 1. Perform no explicit focus-setting action and allow
> >>>>>>> browser to
> >>>>>> set
> >>>>>>> focus or not
> >>>>>>> 2. $("#items")
> >>>>>>> 3. $("#add")
> >>>>>>> 4. $("#skip")
> >>>>>>> 3. Reset scenario, so that $("#item1") and $("#item2") are in
> >>>>>>> the
> >>>>>> list.
> >>>>>>> With focus on $("#item2 .delete"), a click event causes
> >>>>>>> $("#item1")
> >>>>>> to
> >>>>>>> be
> >>>>>>> removed from the page dynamically. Where should focus be
> >> placed?
> >>>>>>> Options:
> >>>>>>> 1. Perform no explicit focus-setting action and allow
> >>>>>>> browser to
> >>>>>> set
> >>>>>>> focus or not
> >>>>>>> 2. $("#items")
> >>>>>>> 3. $("#item1")
> >>>>>>> 4. $("#item1 .itemlink")
> >>>>>>> 5. $("#add")
> >>>>>>> 6. $("#skip")
> >>>>>>>
> >>>>>>> Adding
> >>>>>>>
> >>>>>>> 1. Reset scenario, so that only $("#item1") and $("#item2")
> >>>>>>> are in
> >>>>>> the
> >>>>>>> list. With focus on $("#add"), a click event causes another
> >> item,
> >>>>>>> $("#item3") to be added to the end of the list dynamically.
> >>>>>>> In
> >>>> this
> >>>>>>> scenario, we are assuming there are no intermediary dialogs or
> >>>>>>> pages. Where should focus be placed? Options:
> >>>>>>> 1. Perform no explicit focus-setting action and allow browser
> >>>>>>> to
> >>>> set
> >>>>>>> focus or not
> >>>>>>> 2. $("#items")
> >>>>>>> 3. $("#item3")
> >>>>>>> 4. $("#item3 .itemlink")
> >>>>>>> 5. $("#add")
> >>>>>>> 6. $("#skip")
> >>>>>>>
> >>>>>>> Should $("#items") be a live region? If so, to what should its
> >>>>>> parameters
> >>>>>>> be set? If one felt live regions was appropriate here, I'd
> >>>>>>> guess the
> >>>>>>> following:
> >>>>>>>
> >>>>>>> - aria-live="polite"
> >>>>>>> - aria-atomic="false" (implied)
> >>>>>>>
> >>>>>>> Does that seem reasonable?
> >>>>>>>
> >>>>>>> Are there other attributes or techniques that would seem
> >>>>>>> particularly relevant to these use cases that should be considered?
> >>>>>>>
> >>>>>>> Thanks, in advance, for your assistance.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Rob
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Robert Fentress
> >>>>>>> Senior Accessibility Solutions Designer
> >>>>>>> 540.231.1255
> >>>>>>>
> >>>>>>> Technology-enhanced Learning & Online Strategies Assistive
> >>>>>>> Technologies
> >>>>>>> 1180 Torgersen Hall
> >>>>>>> 620 Drillfield Drive (0434)
> >>>>>>> Blacksburg, Virginia 24061
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Work hard. Have fun. Make history.
> >>>>>> > >>>>>> > >>>>>> list messages to <EMAIL REMOVED>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Robert Fentress
> >>>>> Senior Accessibility Solutions Designer
> >>>>> 540.231.1255
> >>>>>
> >>>>> Technology-enhanced Learning & Online Strategies Assistive
> >>>>> Technologies
> >>>>> 1180 Torgersen Hall
> >>>>> 620 Drillfield Drive (0434)
> >>>>> Blacksburg, Virginia 24061
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Robert Fentress
> >>>> Senior Accessibility Solutions Designer
> >>>> 540.231.1255
> >>>>
> >>>> Technology-enhanced Learning & Online Strategies Assistive
> >>>> Technologies
> >>>> 1180 Torgersen Hall
> >>>> 620 Drillfield Drive (0434)
> >>>> Blacksburg, Virginia 24061
> >>>> > >>>> > >>>> list messages to <EMAIL REMOVED>
> >>>> > >>>> > >>>> list messages to <EMAIL REMOVED>
> >>>
> >>>
> >>>
> >>> --
> >>> Robert Fentress
> >>> Senior Accessibility Solutions Designer
> >>> 540.231.1255
> >>>
> >>> Technology-enhanced Learning & Online Strategies Assistive
> >>> Technologies
> >>> 1180 Torgersen Hall
> >>> 620 Drillfield Drive (0434)
> >>> Blacksburg, Virginia 24061
> >>
> >>
> >>
> >> --
> >> Robert Fentress
> >> Senior Accessibility Solutions Designer
> >> 540.231.1255
> >>
> >> Technology-enhanced Learning & Online Strategies Assistive Technologies
> >> 1180 Torgersen Hall
> >> 620 Drillfield Drive (0434)
> >> Blacksburg, Virginia 24061
> >> > >> > >> messages to <EMAIL REMOVED>
> >> > >> > >> > >
> >
> >
> > --
> > Robert Fentress
> > Senior Accessibility Solutions Designer
> > 540.231.1255
> >
> > Technology-enhanced Learning & Online Strategies
> > Assistive Technologies
> > 1180 Torgersen Hall
> > 620 Drillfield Drive (0434)
> > Blacksburg, Virginia 24061
> > > > > > > > > >