E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 24 (In chronological order)

From: Robert Fentress
Date: Mon, Mar 16 2015 1:20PM
Subject: Focus on adding/removing items
No previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Mon, Mar 16 2015 2:33PM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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.

From: Robert Fentress
Date: Tue, Mar 17 2015 6:37AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.
> > > >



--
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

From: Robert Fentress
Date: Tue, Mar 17 2015 7:03AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
>> >> >> >>
>
>
>
> --
> 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

From: Bourne, Sarah (ITD)
Date: Tue, Mar 17 2015 8:14AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS REMOVED =
http://www.mass.gov/MassIT

From: Robert Fentress
Date: Wed, Mar 18 2015 8:46AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> http://www.mass.gov/MassIT
>
>
>

From: Robert Fentress
Date: Wed, Mar 18 2015 9:00AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>> http://www.mass.gov/MassIT
>>
>>
>>

From: Bourne, Sarah (ITD)
Date: Wed, Mar 18 2015 2:56PM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS REMOVED =
http://www.mass.gov/MassIT

From: Robert Fentress
Date: Mon, Mar 23 2015 10:28AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> http://www.mass.gov/MassIT
>
>
>

From: Cliff Tyllick
Date: Tue, Mar 24 2015 12:30PM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>> http://www.mass.gov/MassIT
>>
>>
>>

From: Whitney Quesenbery
Date: Wed, Mar 25 2015 6:18AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> >> http://www.mass.gov/MassIT
> >>
> >>
> >>

From: Cliff Tyllick
Date: Wed, Mar 25 2015 7:18AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>> http://www.mass.gov/MassIT
>>>>
>>>>
>>>>

From: Robert Fentress
Date: Wed, Mar 25 2015 8:06AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>> http://www.mass.gov/MassIT
>>>>>
>>>>>
>>>>>

From: Lynn Holdsworth
Date: Wed, Mar 25 2015 2:13PM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>>> http://www.mass.gov/MassIT
>>>>>>
>>>>>>
>>>>>>

From: Cliff Tyllick
Date: Wed, Mar 25 2015 2:22PM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

Rob, by approaching it from the standpoint of performance objectives—a concept mentioned in Section 508, by the way—you could attack that usability issue head-on.

In other words, the standard becomes "accessible to and usable by" people with disabilities.

"It's unusable to everyone else, too," isn't safe harbor, especially for an educational institution. What matters is to make the interface usable for people with disabilities.

If they want to leave it unusable for everyone else, I guess that option is available. But it must be usable by people with disabilities, regardless of how many checkpoints it passes.

I've probably said all that before. If you absolutely must point to a failed SC, I would choose SC 2.4.3, Focus Order, which finishes with, "focusable components receive focus in an order that preserves meaning and operability." (Level A)

I would argue that when the focus is lost you also lose operability. They agree that this is a usability problem, so surely they must recognize that operability has been disrupted. For it to pass 2.4.3, that can't happen.



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 9:06 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:

>>

From: Robert Fentress
Date: Wed, Mar 25 2015 3:19PM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

Excellent, Cliff. I agree that 2.4.3 provides a good "official"
justification. Thanks for pointing that out.
On Mar 25, 2015 4:22 PM, "Cliff Tyllick" < = EMAIL ADDRESS REMOVED = > wrote:

> Rob, by approaching it from the standpoint of performance objectives—a
> concept mentioned in Section 508, by the way—you could attack that
> usability issue head-on.
>
> In other words, the standard becomes "accessible to and usable by" people
> with disabilities.
>
> "It's unusable to everyone else, too," isn't safe harbor, especially for
> an educational institution. What matters is to make the interface usable
> for people with disabilities.
>
> If they want to leave it unusable for everyone else, I guess that option
> is available. But it must be usable by people with disabilities, regardless
> of how many checkpoints it passes.
>
> I've probably said all that before. If you absolutely must point to a
> failed SC, I would choose SC 2.4.3, Focus Order, which finishes with,
> "focusable components receive focus in an order that preserves meaning and
> operability." (Level A)
>
> I would argue that when the focus is lost you also lose operability. They
> agree that this is a usability problem, so surely they must recognize that
> operability has been disrupted. For it to pass 2.4.3, that can't happen.
>
>
>
> 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 9:06 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>
> >>
> > > >

From: Robert Fentress
Date: Thu, Mar 26 2015 6:11AM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>>>> http://www.mass.gov/MassIT
>>>>>>>
>>>>>>>
>>>>>>>

From: Lynn Holdsworth
Date: Thu, Mar 26 2015 7:00AM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>>>>> http://www.mass.gov/MassIT
>>>>>>>>
>>>>>>>>
>>>>>>>>

From: Robert Fentress
Date: Thu, Mar 26 2015 7:33AM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>>>>>> http://www.mass.gov/MassIT
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

From: Lynn Holdsworth
Date: Thu, Mar 26 2015 8:50AM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>>>>>>>>> http://www.mass.gov/MassIT
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

From: Jonathan Avila
Date: Thu, Mar 26 2015 11:22AM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | Next message →

> iOS devices don't seem to speak ARIA messages when the containing element is hidden.

I just created a quick test for input and links with aria-labelledby and aria-describedby content that is not displayed via display:none and both were announced by VoiceOver on iOS when swiping to the control.

The ARIA spec allows for these properties to reference content that can be hidden although I don't think it's a good idea. For example, while this information is announced on tab by Windows screen readers it isn't seen in the virtual cursor or browse mode cursor.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Lynn Holdsworth
Date: Thu, Mar 26 2015 11:37AM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | Next message →

Apologies Jonathan, I should have been clearer. I mean that we had
problems getting VoiceOver on iOS to read out messages that were
contained in ARIA alerts, status messages or live regions when we used
the Snook method to hide content off-screen.

More info on the Snook method here:
http://snook.ca/archives/html_and_css/hiding-content-for-accessibility

Best, Lynn

On 26/03/2015, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> iOS devices don't seem to speak ARIA messages when the containing element
>> is hidden.
>
> I just created a quick test for input and links with aria-labelledby and
> aria-describedby content that is not displayed via display:none and both
> were announced by VoiceOver on iOS when swiping to the control.
>
> The ARIA spec allows for these properties to reference content that can be
> hidden although I don't think it's a good idea. For example, while this
> information is announced on tab by Windows screen readers it isn't seen in
> the virtual cursor or browse mode cursor.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Whitney Quesenbery
Date: Thu, Mar 26 2015 11:47AM
Subject: Re: Focus on adding/removing items
← Previous message | Next message →

All arguments for looking at usability and accessibility together.

The problem with relying entirely on checkpoints is that there are too many
cases where the failure doesn't cause as much problem as it might, and
other cases where meeting the checkpoint doesn't solve the usability
problem.

Nothing like seeing people flounder around to make the case. It's been true
in usability, and it's true in accessibility.

My experience has been that understanding what the problem means in action
is a lot more compelling than any list of industry or internal guidelines.
Working through the issues so that the whole team understands the usability
barriers and how to think about them in a new way is so much more powerful
than being the checklist police.




On Wed, Mar 25, 2015 at 5:19 PM Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:

> Excellent, Cliff. I agree that 2.4.3 provides a good "official"
> justification. Thanks for pointing that out.
> On Mar 25, 2015 4:22 PM, "Cliff Tyllick" < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Rob, by approaching it from the standpoint of performance objectives—a
> > concept mentioned in Section 508, by the way—you could attack that
> > usability issue head-on.
> >
> > In other words, the standard becomes "accessible to and usable by" people
> > with disabilities.
> >
> > "It's unusable to everyone else, too," isn't safe harbor, especially for
> > an educational institution. What matters is to make the interface usable
> > for people with disabilities.
> >
> > If they want to leave it unusable for everyone else, I guess that option
> > is available. But it must be usable by people with disabilities,
> regardless
> > of how many checkpoints it passes.
> >
> > I've probably said all that before. If you absolutely must point to a
> > failed SC, I would choose SC 2.4.3, Focus Order, which finishes with,
> > "focusable components receive focus in an order that preserves meaning
> and
> > operability." (Level A)
> >
> > I would argue that when the focus is lost you also lose operability. They
> > agree that this is a usability problem, so surely they must recognize
> that
> > operability has been disrupted. For it to pass 2.4.3, that can't happen.
> >
> >
> >
> > 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 9:06 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > >>
> > > > > > > >
> > > >

From: Birkir R. Gunnarsson
Date: Thu, Mar 26 2015 8:17PM
Subject: Re: Alerts for edits and deletions (wasFocus on adding/removing items)
← Previous message | No next message

Weird, I am pretty sure the cfollowing will work:
CSS:

.clipped {
clip: rect(1px, 1px, 1px, 1px);
position: absolute;
overflow: hidden;
width: 0;
}

...
<div class="clipped" aria-live="assertive" aria-atomic="true">Alert
message goes here</div>

Make sure message only gets injected by JavaScript that removes the item.
- If the entire page has to reload, the aria-live announcement gets lost.
- If you simply change CSS properties, say from display: none to using
the clipped class, no content is updated so there is no announcement.
Cheers
-B


On 3/26/15, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Apologies Jonathan, I should have been clearer. I mean that we had
> problems getting VoiceOver on iOS to read out messages that were
> contained in ARIA alerts, status messages or live regions when we used
> the Snook method to hide content off-screen.
>
> More info on the Snook method here:
> http://snook.ca/archives/html_and_css/hiding-content-for-accessibility
>
> Best, Lynn
>
> On 26/03/2015, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> iOS devices don't seem to speak ARIA messages when the containing
>>> element
>>> is hidden.
>>
>> I just created a quick test for input and links with aria-labelledby and
>> aria-describedby content that is not displayed via display:none and both
>> were announced by VoiceOver on iOS when swiping to the control.
>>
>> The ARIA spec allows for these properties to reference content that can be
>> hidden although I don't think it's a good idea. For example, while this
>> information is announced on tab by Windows screen readers it isn't seen in
>> the virtual cursor or browse mode cursor.
>>
>> Jonathan
>>
>> --
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> = EMAIL ADDRESS REMOVED =
>> Phone 703.637.8957
>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>
>>
>>