WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Alerts for edits and deletions (wasFocus on adding/removing items)

for

From: Lynn Holdsworth
Date: Mar 26, 2015 7:00AM

Rob, I think if an item were added to the list it would probably be
enough to move the focus to the newly-added item. For deletions I
personally would find it useful to hear a short message saying "item
deleted".

The problem with hiding messages like this off-screen is that iOS
devices tend not to read invisible text.

Best, Lynn

On 26/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
> Lynn, related to the "empty list" alert, what about alerts for other
> changes to the list? For instance, would it be best practice to have
> ARIA alerts triggered whenever something was added or removed from the
> list as well? These probably shouldn't be visible alerts (though I'm
> open to arguments as to why they should be), but, for users who are
> blind, they may serve as useful confirmation that their action was
> successful. I could also see, though, how this might be viewed as
> unnecessarily verbose.
>
> What do you folks think about the use of ARIA alerts in instances like
> these?
>
> Best,
> Rob
>
> On Wed, Mar 25, 2015 at 4:13 PM, Lynn Holdsworth
> < <EMAIL REMOVED> > wrote:
>> Hi all,
>>
>> I'm watching this thread with interest.
>>
>> I would argue that this is an accessibility rather than a usability
>> issue, since the loss of focus is likely to cause blind users not to
>> be sure where they are in the page, and keyboard users to take
>> significantly longer to achieve their goal.
>>
>> Invaluable though the guidelines are, I think that concentrating
>> solely on these puts developers and designers at a dangerous remove
>> from what accessibility aims to achieve: i.e. making it possible for
>> the huge number of people who would otherwise be disadvantaged to buy,
>> sell, read, contribute to, learn from, or use the products or services
>> being offered by the website or app they're creating.
>>
>> The Google Drive approach seems to work quite well. I've seen a model
>> where the container is injected with hidden text saying "Empty list".
>> I personally find this little message very useful.
>>
>> Best, Lynn
>>
>> On 25/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
>>> Whitney and Cliff, thanks for your takes on the issue.
>>>
>>> While it is true that usability is what we should focus on, I have had
>>> the reaction of "Well, that's just a usability problem," and, because
>>> it isn't specifically addressed by a success criterion, it is not
>>> given priority as something that needs to be fixed.
>>>
>>> I've looked at a couple of other examples to help in analyzing the
>>> issue, and I'll share what I've found in case it is of value to
>>> others.
>>>
>>> In the Windows File Explorer in Detail View, if you have a list of
>>> files, and you delete one, focus shifts to the next file in the list.
>>> If you delete the last file in the list, but there are still files
>>> left, focus shifts to the new last item in the list. If there is only
>>> one file left and you delete that, focus shifts to the first column
>>> header in the file list pane.
>>>
>>> In Google Drive, the pattern is the same, except when the last item is
>>> deleted, focus shifts to the file list pane as a whole, since the
>>> column headings disappear when the last file is removed.
>>>
>>> At the moment, I think I like the pattern Google Drive uses here.
>>>
>>> On Wed, Mar 25, 2015 at 9:18 AM, Cliff Tyllick < <EMAIL REMOVED> > wrote:
>>>> Well said, Whitney!
>>>>
>>>> And that's the kind of solution we can inspire when we frame the issue
>>>> as
>>>> a barrier to usability rather than the failure of a checkpoint or
>>>> success
>>>> criterion.
>>>>
>>>> We will have to qualify the conditions under which the barrier
>>>> exists—for
>>>> example, when reading the page through a certain technology; or, as in
>>>> this case, when human—but in doing so we establish conditions that must
>>>> be
>>>> met if the project is to succeed.
>>>>
>>>> Read through Whitney's answer again and I think you'll see how focusing
>>>> on
>>>> what success would look like, not on the rule that we failed, led
>>>> directly
>>>> to specific qualities the product must have if it is to pass QA.
>>>>
>>>> Cliff Tyllick
>>>>
>>>> Sent from my iPhone
>>>> Although its spellcheck often saves me, all goofs in sent messages are
>>>> its
>>>> fault.
>>>>
>>>>> On Mar 25, 2015, at 7:18 AM, Whitney Quesenbery < <EMAIL REMOVED> >
>>>>> wrote:
>>>>>
>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>