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 8:50AM

Hi Rob,
I worked on a high-profile contract last year (sadly under NDA), where
we discovered that iOS devices don't seem to speak ARIA messages when
the containing element is hidden.

Best, Lynn

On 26/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
> It's funny, Lynn: There is another recent post on the list ("Hidden
> Items read out by Voiceover and Talkback") that seems to be saying the
> opposite--namely, that VO on iOS and Talkback on Android are reading
> stuff that should not be read. I haven't played around with it enough
> to say what the conditions are that make the difference, but now I'm
> curious. I'll have to do some experimentation. :-)
>
> On Thu, Mar 26, 2015 at 9:00 AM, Lynn Holdsworth
> < <EMAIL REMOVED> > wrote:
>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>