WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Robert Fentress
Date: Mar 26, 2015 7:33AM

It's funny, Lynn: There is another recent post on the list ("Hidden
Items read out by Voiceover and Talkback") that seems to be saying the
opposite--namely, that VO on iOS and Talkback on Android are reading
stuff that should not be read. I haven't played around with it enough
to say what the conditions are that make the difference, but now I'm
curious. I'll have to do some experimentation. :-)

On Thu, Mar 26, 2015 at 9:00 AM, Lynn Holdsworth
< <EMAIL REMOVED> > wrote:
> Rob, I think if an item were added to the list it would probably be
> enough to move the focus to the newly-added item. For deletions I
> personally would find it useful to hear a short message saying "item
> deleted".
>
> The problem with hiding messages like this off-screen is that iOS
> devices tend not to read invisible text.
>
> Best, Lynn
>
> On 26/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
>> Lynn, related to the "empty list" alert, what about alerts for other
>> changes to the list? For instance, would it be best practice to have
>> ARIA alerts triggered whenever something was added or removed from the
>> list as well? These probably shouldn't be visible alerts (though I'm
>> open to arguments as to why they should be), but, for users who are
>> blind, they may serve as useful confirmation that their action was
>> successful. I could also see, though, how this might be viewed as
>> unnecessarily verbose.
>>
>> What do you folks think about the use of ARIA alerts in instances like
>> these?
>>
>> Best,
>> Rob
>>
>> On Wed, Mar 25, 2015 at 4:13 PM, Lynn Holdsworth
>> < <EMAIL REMOVED> > wrote:
>>> Hi all,
>>>
>>> I'm watching this thread with interest.
>>>
>>> I would argue that this is an accessibility rather than a usability
>>> issue, since the loss of focus is likely to cause blind users not to
>>> be sure where they are in the page, and keyboard users to take
>>> significantly longer to achieve their goal.
>>>
>>> Invaluable though the guidelines are, I think that concentrating
>>> solely on these puts developers and designers at a dangerous remove
>>> from what accessibility aims to achieve: i.e. making it possible for
>>> the huge number of people who would otherwise be disadvantaged to buy,
>>> sell, read, contribute to, learn from, or use the products or services
>>> being offered by the website or app they're creating.
>>>
>>> The Google Drive approach seems to work quite well. I've seen a model
>>> where the container is injected with hidden text saying "Empty list".
>>> I personally find this little message very useful.
>>>
>>> Best, Lynn
>>>
>>> On 25/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
>>>> Whitney and Cliff, thanks for your takes on the issue.
>>>>
>>>> While it is true that usability is what we should focus on, I have had
>>>> the reaction of "Well, that's just a usability problem," and, because
>>>> it isn't specifically addressed by a success criterion, it is not
>>>> given priority as something that needs to be fixed.
>>>>
>>>> I've looked at a couple of other examples to help in analyzing the
>>>> issue, and I'll share what I've found in case it is of value to
>>>> others.
>>>>
>>>> In the Windows File Explorer in Detail View, if you have a list of
>>>> files, and you delete one, focus shifts to the next file in the list.
>>>> If you delete the last file in the list, but there are still files
>>>> left, focus shifts to the new last item in the list. If there is only
>>>> one file left and you delete that, focus shifts to the first column
>>>> header in the file list pane.
>>>>
>>>> In Google Drive, the pattern is the same, except when the last item is
>>>> deleted, focus shifts to the file list pane as a whole, since the
>>>> column headings disappear when the last file is removed.
>>>>
>>>> At the moment, I think I like the pattern Google Drive uses here.
>>>>
>>>> On Wed, Mar 25, 2015 at 9:18 AM, Cliff Tyllick < <EMAIL REMOVED> > wrote:
>>>>> Well said, Whitney!
>>>>>
>>>>> And that's the kind of solution we can inspire when we frame the issue
>>>>> as
>>>>> a barrier to usability rather than the failure of a checkpoint or
>>>>> success
>>>>> criterion.
>>>>>
>>>>> We will have to qualify the conditions under which the barrier
>>>>> exists—for
>>>>> example, when reading the page through a certain technology; or, as in
>>>>> this case, when human—but in doing so we establish conditions that must
>>>>> be
>>>>> met if the project is to succeed.
>>>>>
>>>>> Read through Whitney's answer again and I think you'll see how focusing
>>>>> on
>>>>> what success would look like, not on the rule that we failed, led
>>>>> directly
>>>>> to specific qualities the product must have if it is to pass QA.
>>>>>
>>>>> Cliff Tyllick
>>>>>
>>>>> Sent from my iPhone
>>>>> Although its spellcheck often saves me, all goofs in sent messages are
>>>>> its
>>>>> fault.
>>>>>
>>>>>> On Mar 25, 2015, at 7:18 AM, Whitney Quesenbery < <EMAIL REMOVED> >
>>>>>> wrote:
>>>>>>
>>>>>> Where should the focus go: In the least disruptive place for the user:
>>>>>>
>>>>>> - Causes the least redisplay of the page or movement within it
>>>>>> - Leaves them in familiar place, so they can maintain orientation
>>>>>> - Does not disrupt the task flow.
>>>>>>
>>>>>> Typically, this should be either the item above or below the one just
>>>>>> deleted.
>>>>>>
>>>>>> There are patterns for this sort of list management, even without a
>>>>>> visible
>>>>>> "x" button to delete the item. I've seen it done both ways, and I've
>>>>>> seen
>>>>>> programs that are smart enough to move through a list as items are
>>>>>> being
>>>>>> deleted adjusting to whether the user is moving up or down in the list.
>>>>>>
>>>>>> The usability problem is that if the list is being read top to bottom,
>>>>>> the
>>>>>> familiar location is the item above, but this causes extra navigation.
>>>>>>
>>>>>> Example. Consider this list:
>>>>>>
>>>>>> Item One
>>>>>> Item Two
>>>>>> Item Three to be deleted
>>>>>> Item Four
>>>>>>
>>>>>> If the user is tabbing (or using ArrowDown) through the list and
>>>>>> deletes
>>>>>> Item Three, then Item Four is the next logical point for the focus to
>>>>>> land,
>>>>>> following the navigation direction. If they are using Shift-Tab or
>>>>>> ArrowUp
>>>>>> the reverse is true.
>>>>>>
>>>>>> A visual reader is not thrown back to the top of the page, and neither
>>>>>> should the non-visual interaction.
>>>>>>
>>>>>> The usability of the visual experience depends on how smoothly the
>>>>>> program
>>>>>> manages the visual transition. In the example above, Item Four should
>>>>>> be
>>>>>> able to slide up into position without disturbing the visual display
>>>>>> above
>>>>>> the deleted item. The same should be true for a non-visual user.
>>>>>>
>>>>>>
>>>>>>> On Tue, Mar 24, 2015 at 2:30 PM Cliff Tyllick < <EMAIL REMOVED> >
>>>>>>> wrote:
>>>>>>>
>>>>>>> Rob, I'm going to go out on a limb here and say that the problem is
>>>>>>> that
>>>>>>> loss of focus is not addressed by the guidelines.
>>>>>>>
>>>>>>> Focus order is (SC 2.4.3). Focus visibility is (SC 2.4.7). But not the
>>>>>>> simple case of, "Oops, nothing to focus on, so let's take it again
>>>>>>> from
>>>>>>> the
>>>>>>> top!"
>>>>>>>
>>>>>>> I guess we could stretch SC 2.4.8, Location, to cover loss of focus.
>>>>>>> If
>>>>>>> you can't find the focus, you can't tell where you are in the page.
>>>>>>> But
>>>>>>> that's Level AAA, and this seems like a Level A problem to me.
>>>>>>>
>>>>>>> Worse yet, no matter what success criterion I select for failing this
>>>>>>> Web
>>>>>>> content, it won't be a clear fit. And that means I could expect
>>>>>>> pushback
>>>>>>> from whoever I must tell, "Keep working. This isn't good enough."
>>>>>>>
>>>>>>> The problem is that we're trying to turn accessibility into a
>>>>>>> one-size-fits-all checklist. That's a problem because a checklist
>>>>>>> can't
>>>>>>> easily accommodate loose ends, and accessibility has many. And it's
>>>>>>> also
>>>>>>> a
>>>>>>> problem because the items we're using for checkpoints—the success
>>>>>>> criteria—are meant to document ways to succeed, not to pinpoint every
>>>>>>> possible way to fail.
>>>>>>>
>>>>>>> So what can we measure against? Instead of details, why not focus on
>>>>>>> the
>>>>>>> big picture? Use performance objectives:
>>>>>>> ' A person who is blind must be able to perceive, operate, and
>>>>>>> understand
>>>>>>> this Web page and its contents.
>>>>>>> ' A person who has low moderate vision must be able to perceive,
>>>>>>> operate,
>>>>>>> and understand this Web page and its contents.
>>>>>>> ' A person who is deaf must be able to perceive, operate, and
>>>>>>> understand
>>>>>>> this Web page and its contents.
>>>>>>> ' And so on.
>>>>>>>
>>>>>>> The Guidelines and Success Criteria could then be used as intended—as
>>>>>>> information to help project teams figure out likely solutions, not as
>>>>>>> absolute measures of sufficient accessibility.
>>>>>>>
>>>>>>> The ultimate measure of accessibility, then, would be a usability test
>>>>>>> by
>>>>>>> people for whom the feature being tested might be a barrier.
>>>>>>>
>>>>>>> Whether I could find a Success Criterion we could use to fail an
>>>>>>> inaccessible feature would be irrelevant. I would just need to note
>>>>>>> that
>>>>>>> our tester found it inaccessible and point the project team to
>>>>>>> information
>>>>>>> that might help them solve the problem.
>>>>>>>
>>>>>>> Because the big picture isn't that you should be able to complete some
>>>>>>> kind of paperwork to document that your site is accessible. The big
>>>>>>> picture
>>>>>>> is that your customers should find your content fully usable,
>>>>>>> regardless
>>>>>>> of
>>>>>>> their ability—so usable that they never realize that you had to remove
>>>>>>> a
>>>>>>> barrier that would have hindered them.
>>>>>>>
>>>>>>> Cliff Tyllick
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>> Although its spellcheck often saves me, all goofs in sent messages are
>>>>>>> its
>>>>>>> fault.
>>>>>>>
>>>>>>>> On Mar 23, 2015, at 11:28 AM, Robert Fentress via WebAIM-Forum <
>>>>>>> <EMAIL REMOVED> > wrote:
>>>>>>>>
>>>>>>>> Thanks, Sarah. Your analysis is helpful.
>>>>>>>>
>>>>>>>> I agree that it is a usability issue, though, of course, it has
>>>>>>> particular
>>>>>>>> implications for accessibility. For instance, as you suggest, if an
>>>>>>>> interaction causes focus to be lost entirely or causes it to go to
>>>>>>>> the
>>>>>>> top
>>>>>>>> of the page, requiring the user to navigate back to a widget from the
>>>>>>> start
>>>>>>>> of the page, I would think this would be very problematic. My first
>>>>>>>> thought was that this would cause a page to violate "WCAG 3.2.2 On
>>>>>>> Input" (
>>>>>>>> http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change),
>>>>>>>> since this would count as an unexpected change of context (
>>>>>>>> http://www.w3.org/TR/WCAG20/#context-changedef). However, the
>>>>>>>> Understanding SC 3.2.2 working group note (
>>>>>>>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-
>>>>>>> unpredictable-change.html)
>>>>>>>> indicates that activating a button is specifically excluded from the
>>>>>>>> list
>>>>>>>> of things counting as "Changing the setting of any user interface
>>>>>>>> component." Would a page that did this technically violate any WCAG
>>>>>>>> 2.0
>>>>>>>> standard that you are aware of? Perhaps SC 3.2.5 would be relevant (
>>>>>>>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-
>>>>>>> extreme-changes-context.html)?
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> I ask because I am performing an internal review of a third-party web
>>>>>>>> application for accessibility and in several instances focus is lost
>>>>>>>> in
>>>>>>>> this way. In my report, I would rather have some specific success
>>>>>>>> criterion to point to, so it is not just my opinion about a usability
>>>>>>>> issue.
>>>>>>>>
>>>>>>>> Also, I would like to be able to recommend what the best practice
>>>>>>>> would
>>>>>>> be
>>>>>>>> in these sorts of situations. Right now, I'm thinking the best
>>>>>>>> algorithm
>>>>>>>> for deletions would be set focus to the grouped item immediately
>>>>>>> following
>>>>>>>> the item deleted (after a confirmation dialog, which I left out to
>>>>>>> simplify
>>>>>>>> the example), unless there are no more items in the list, in which
>>>>>>>> case,
>>>>>>>> focus should be set on the add button. We don't have the resources
>>>>>>>> to
>>>>>>>> do
>>>>>>>> formal usability testing, so I kind of have to run the scenario in my
>>>>>>>> own
>>>>>>>> head. Here is my thinking:
>>>>>>>>
>>>>>>>> After deleting an item, what is the user most likely to want to do?
>>>>>>>> It
>>>>>>>> might be most reasonable to assume that they want to do something
>>>>>>>> with
>>>>>>> the
>>>>>>>> next item in the list. What could they do? Well, in the example
>>>>>>>> given,
>>>>>>>> they could read the link text, follow the link text to view or edit
>>>>>>>> the
>>>>>>>> details of the item (unspecified, but assumed), or delete the item.
>>>>>>>> So,
>>>>>>>> focusing on the item as a whole, rather than on any component within
>>>>>>>> it
>>>>>>>> might be the best balance of directed guidance and flexibility. The
>>>>>>>> user
>>>>>>>> might also want to add an item, of course, but moving the focus there
>>>>>>> would
>>>>>>>> seem to be more disruptive, and require more navigation to get to the
>>>>>>> other
>>>>>>>> things the user might want to do. Focus could also be moved to the
>>>>>>>> main
>>>>>>>> container for the items, $("#items"), but, again this seems to be
>>>>>>>> disruptive, in that it moves the user further away from where they
>>>>>>>> were
>>>>>>> at
>>>>>>>> the initiation of the delete action.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Rob
>>>>>>>>
>>>>>>>> On Wed, Mar 18, 2015 at 4:56 PM, Bourne, Sarah (ITD) <
>>>>>>>> <EMAIL REMOVED> > wrote:
>>>>>>>>
>>>>>>>>> Rob,
>>>>>>>>>
>>>>>>>>> Where the focus should go is more a usability issue than an
>>>>>>> accessibility
>>>>>>>>> requirement per se, and may requiring some testing by users to see
>>>>>>>>> if
>>>>>>>>> you've got it right. As a general rule, you want to put focus back
>>>>>>>>> to
>>>>>>>>> where the user was in the flow of the page. If it goes to the top
>>>>>>>>> of
>>>>>>> the
>>>>>>>>> page, for instance, a keyboard-only user would have to tab all the
>>>>>>>>> way
>>>>>>> back
>>>>>>>>> to "items" to continue item management.
>>>>>>>>>
>>>>>>>>> Since you can't put them back on the delete button once an item is
>>>>>>>>> deleted, perhaps it could be replaced with a confirmation statement
>>>>>>> (maybe
>>>>>>>>> with an un-do action even) that the item was deleted. Lacking that,
>>>>>>>>> I
>>>>>>> would
>>>>>>>>> think it should go to the next element - the next item link if there
>>>>>>>>> is
>>>>>>>>> one, or to the add item button. But user testing might show that
>>>>>>>>> taking
>>>>>>>>> them to the top of the list when at the end is more useful.
>>>>>>>>>
>>>>>>>>> I can't speak to exactly which ARIA attributes you should use, but
>>>>>>>>> I
>>>>>>>>> agree with Birkir that using list elements for the items would
>>>>>>>>> improve
>>>>>>>>> usability, and you would need something so the list and count is
>>>>>>>>> updated
>>>>>>>>> when items have been added or deleted.
>>>>>>>>>
>>>>>>>>> sb
>>>>>>>>> Sarah E. Bourne
>>>>>>>>> Director of IT Accessibility, MassIT
>>>>>>>>> Commonwealth of Massachusetts
>>>>>>>>> 1 Ashburton Pl. rm 1601 Boston MA 02108
>>>>>>>>> 617-626-4502
>>>>>>>>> <EMAIL REMOVED>
>>>>>>>>> http://www.mass.gov/MassIT
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: <EMAIL REMOVED> [mailto:
>>>>>>>>> <EMAIL REMOVED> ] On Behalf Of Robert Fentress
>>>>>>>>> Sent: Wednesday, March 18, 2015 11:00 AM
>>>>>>>>> To: WebAIM Discussion List
>>>>>>>>> Subject: Re: [WebAIM] Focus on adding/removing items
>>>>>>>>>
>>>>>>>>> Another option might be to have a separate element that had
>>>>>>> role="alert",
>>>>>>>>> which was updated every time something was added or removed from the
>>>>>>> item
>>>>>>>>> list. For instance, if you remove an item, you could have the alert
>>>>>>> read
>>>>>>>>> "Item deleted," or, if added "item added."
>>>>>>>>>
>>>>>>>>>> On Wed, Mar 18, 2015 at 10:46 AM, Robert Fentress < <EMAIL REMOVED> >
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for letting me know. Here is a link to the picture:
>>>>>>>>>>
>>>>>>>>>> https://drive.google.com/file/d/0B8U0tKKO3WMWVGptUDhfMnhKSk0/view?usp>>>>>>>>>> sharing
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 17, 2015 at 10:14 AM, Bourne, Sarah (ITD) <
>>>>>>>>>> <EMAIL REMOVED> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Rob,
>>>>>>>>>>>
>>>>>>>>>>> Attached images don't make it through on this list service. Is
>>>>>>>>>>> there
>>>>>>>>>>> someplace you can post the image so you can give a URL instead?
>>>>>>>>>>>
>>>>>>>>>>> sb
>>>>>>>>>>> Sarah E. Bourne
>>>>>>>>>>> Director of IT Accessibility, MassIT
>>>>>>>>>>> Commonwealth of Massachusetts
>>>>>>>>>>> 1 Ashburton Pl. rm 1601 Boston MA 02108
>>>>>>>>>>> 617-626-4502
>>>>>>>>>>> <EMAIL REMOVED>
>>>>>>>>>>> http://www.mass.gov/MassIT
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: <EMAIL REMOVED> [mailto:
>>>>>>>>>>> <EMAIL REMOVED> ] On Behalf Of Robert Fentress
>>>>>>>>>>> Sent: Tuesday, March 17, 2015 9:04 AM
>>>>>>>>>>> To: WebAIM Discussion List
>>>>>>>>>>> Subject: Re: [WebAIM] Focus on adding/removing items
>>>>>>>>>>>
>>>>>>>>>>> Birkir,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your response.
>>>>>>>>>>>
>>>>>>>>>>> Since the delete button is within the item being removed, I
>>>>>>>>>>> couldn't
>>>>>>>>>>> keep it on that delete button. Do you mean I should move it to
>>>>>>>>>>> the
>>>>>>>>>>> delete button in the other item?
>>>>>>>>>>>
>>>>>>>>>>> Also, what about live regions? Would this be an appropriate use
>>>>>>>>>>> case
>>>>>>>>>>> for those and, if so, what attribute values should I apply for
>>>>>>>>>>> aria-live, aria-atomic, and aria-relevant?
>>>>>>>>>>>
>>>>>>>>>>> Is there a set of standards or principles that you are going by in
>>>>>>>>>>> your recommendations or are they just based on your sense of
>>>>>>>>>>> things
>>>>>>>>>>> based on your experience? Hope that didn't sound rude; I just
>>>>>>>>>>> want
>>>>>>>>>>> to know, because then I could reference that for guidance later.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Rob
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 17, 2015 at 8:37 AM, Robert Fentress < <EMAIL REMOVED> >
>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Just noticed the background of the wireframe I attached was
>>>>>>>>> transparent.
>>>>>>>>>>>> Here is one where I've filled that in. Sorry.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Mar 16, 2015 at 4:33 PM, Birkir R. Gunnarsson <
>>>>>>>>>>>> <EMAIL REMOVED> > wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> My take on this:
>>>>>>>>>>>>> - If adding an item, move focus to the recently added item once
>>>>>>>>>>> complete.
>>>>>>>>>>>>> - If deleting one of multiple items, user should be notified to
>>>>>>>>>>>>> this, ideally by an accessible modal alert dialog, or at least
>>>>>>>>>>>>> using a live region with role="alert"
>>>>>>>>>>>>> I would suggest keeping focus on the delete button.
>>>>>>>>>>>>> - If deleting the only item on the page, alert user in the same
>>>>>>>>>>>>> way but put the user focus at the top of the page.
>>>>>>>>>>>>> If possible, keep items in a list markup so that users can
>>>>>>>>>>>>> quickly
>>>>>>>>>>>>> find out how many items are on the page (screen readers will
>>>>>>>>>>>>> notify user of the number of items in an ol or ul list).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/16/15, Robert Fentress < <EMAIL REMOVED> > wrote:
>>>>>>>>>>>>>> Hello, all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Following up on my previous email regarding focus in rich
>>>>>>>>>>>>>> internet applications, I thought I'd provide an explicit
>>>>>>>>>>>>>> example. I'm attaching
>>>>>>>>>>>>> a
>>>>>>>>>>>>>> wireframe image to help make things clearer to the sighted. It
>>>>>>>>>>>>>> shows
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - A "Skip to content" link with id="skip" at the top of the
>>>>>>>>>>>>>> page
>>>>>>>>>>>>>> - A large rectangle with id="items", which encompasses the
>>>>>>>>>>> following
>>>>>>>>>>>>>> items:
>>>>>>>>>>>>>> - Two rectangles, one following the other vertically, both
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> class="item", one with id="item 1" and the other with
>>>>>>>>>>> id="item2".
>>>>>>>>>>>>>> Inside
>>>>>>>>>>>>>> each element with class="item" are the following:
>>>>>>>>>>>>>> - A link with class="itemlink"
>>>>>>>>>>>>>> - An icon button with class="delete"
>>>>>>>>>>>>>> - The last thing in the "items" element is a button, whose
>>>>>>>>>>>>>> value
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> "Add Item" with id="add"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The delete button causes an item to be removed from the list of
>>>>>>>>>>>>>> items,
>>>>>>>>>>>>> and
>>>>>>>>>>>>>> the "Add Item" button causes an item to be added to the bottom
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>> list
>>>>>>>>>>>>>> of items.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here are my questions, using jQuery selectors to indicate
>>>>>>>>>>>>>> element
>>>>>>>>>>>>>> referenced:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Deleting
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. With focus on $("#item1 .delete"), a click event causes
>>>>>>>>>>>>> $("#item1")
>>>>>>>>>>>>>> to be removed from the page dynamically. Where should focus
>>>>>>>>>>>>>> be
>>>>>>>>>>>>> placed?
>>>>>>>>>>>>>> Options:
>>>>>>>>>>>>>> 1. Perform no explicit focus-setting action and allow browser
>>>>>>>>>>>>>> to
>>>>>>>>>>> set
>>>>>>>>>>>>>> focus or not
>>>>>>>>>>>>>> 2. $("#items")
>>>>>>>>>>>>>> 3. $("#item2")
>>>>>>>>>>>>>> 4. $("#item2 .itemlink")
>>>>>>>>>>>>>> 5. $("#skip")
>>>>>>>>>>>>>> 2. With only $("#item2") remaining and focus on $("#item2
>>>>>>>>>>>>>> .delete"),
>>>>>>>>>>>>> a
>>>>>>>>>>>>>> click event causes $("#item1") to be removed from the page
>>>>>>>>>>>>> dynamically.
>>>>>>>>>>>>>> Where should focus be placed? Options:
>>>>>>>>>>>>>> 1. Perform no explicit focus-setting action and allow
>>>>>>>>>>>>>> browser to
>>>>>>>>>>>>> set
>>>>>>>>>>>>>> focus or not
>>>>>>>>>>>>>> 2. $("#items")
>>>>>>>>>>>>>> 3. $("#add")
>>>>>>>>>>>>>> 4. $("#skip")
>>>>>>>>>>>>>> 3. Reset scenario, so that $("#item1") and $("#item2") are in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>> list.
>>>>>>>>>>>>>> With focus on $("#item2 .delete"), a click event causes
>>>>>>>>>>>>>> $("#item1")
>>>>>>>>>>>>> to
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> removed from the page dynamically. Where should focus be
>>>>>>>>> placed?
>>>>>>>>>>>>>> Options:
>>>>>>>>>>>>>> 1. Perform no explicit focus-setting action and allow
>>>>>>>>>>>>>> browser to
>>>>>>>>>>>>> set
>>>>>>>>>>>>>> focus or not
>>>>>>>>>>>>>> 2. $("#items")
>>>>>>>>>>>>>> 3. $("#item1")
>>>>>>>>>>>>>> 4. $("#item1 .itemlink")
>>>>>>>>>>>>>> 5. $("#add")
>>>>>>>>>>>>>> 6. $("#skip")
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adding
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Reset scenario, so that only $("#item1") and $("#item2")
>>>>>>>>>>>>>> are in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> list. With focus on $("#add"), a click event causes another
>>>>>>>>> item,
>>>>>>>>>>>>>> $("#item3") to be added to the end of the list dynamically.
>>>>>>>>>>>>>> In
>>>>>>>>>>> this
>>>>>>>>>>>>>> scenario, we are assuming there are no intermediary dialogs or
>>>>>>>>>>>>>> pages. Where should focus be placed? Options:
>>>>>>>>>>>>>> 1. Perform no explicit focus-setting action and allow browser
>>>>>>>>>>>>>> to
>>>>>>>>>>> set
>>>>>>>>>>>>>> focus or not
>>>>>>>>>>>>>> 2. $("#items")
>>>>>>>>>>>>>> 3. $("#item3")
>>>>>>>>>>>>>> 4. $("#item3 .itemlink")
>>>>>>>>>>>>>> 5. $("#add")
>>>>>>>>>>>>>> 6. $("#skip")
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Should $("#items") be a live region? If so, to what should its
>>>>>>>>>>>>> parameters
>>>>>>>>>>>>>> be set? If one felt live regions was appropriate here, I'd
>>>>>>>>>>>>>> guess the
>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - aria-live="polite"
>>>>>>>>>>>>>> - aria-atomic="false" (implied)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does that seem reasonable?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are there other attributes or techniques that would seem
>>>>>>>>>>>>>> particularly relevant to these use cases that should be
>>>>>>>>>>>>>> considered?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, in advance, for your assistance.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Rob
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Robert Fentress
>>>>>>>>>>>>>> Senior Accessibility Solutions Designer
>>>>>>>>>>>>>> 540.231.1255
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Technology-enhanced Learning & Online Strategies Assistive
>>>>>>>>>>>>>> Technologies
>>>>>>>>>>>>>> 1180 Torgersen Hall
>>>>>>>>>>>>>> 620 Drillfield Drive (0434)
>>>>>>>>>>>>>> Blacksburg, Virginia 24061
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Work hard. Have fun. Make history.
>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Address
>>>>>>>>>>>>> list messages to <EMAIL REMOVED>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Robert Fentress
>>>>>>>>>>>> Senior Accessibility Solutions Designer
>>>>>>>>>>>> 540.231.1255
>>>>>>>>>>>>
>>>>>>>>>>>> Technology-enhanced Learning & Online Strategies Assistive
>>>>>>>>>>>> Technologies
>>>>>>>>>>>> 1180 Torgersen Hall
>>>>>>>>>>>> 620 Drillfield Drive (0434)
>>>>>>>>>>>> Blacksburg, Virginia 24061
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Fentress
>>>>>>>>>>> Senior Accessibility Solutions Designer
>>>>>>>>>>> 540.231.1255
>>>>>>>>>>>
>>>>>>>>>>> Technology-enhanced Learning & Online Strategies Assistive
>>>>>>>>>>> Technologies
>>>>>>>>>>> 1180 Torgersen Hall
>>>>>>>>>>> 620 Drillfield Drive (0434)
>>>>>>>>>>> Blacksburg, Virginia 24061
>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> list messages to <EMAIL REMOVED>
>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> list messages to <EMAIL REMOVED>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Robert Fentress
>>>>>>>>>> Senior Accessibility Solutions Designer
>>>>>>>>>> 540.231.1255
>>>>>>>>>>
>>>>>>>>>> Technology-enhanced Learning & Online Strategies Assistive
>>>>>>>>>> Technologies
>>>>>>>>>> 1180 Torgersen Hall
>>>>>>>>>> 620 Drillfield Drive (0434)
>>>>>>>>>> Blacksburg, Virginia 24061
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Robert Fentress
>>>>>>>>> Senior Accessibility Solutions Designer
>>>>>>>>> 540.231.1255
>>>>>>>>>
>>>>>>>>> Technology-enhanced Learning & Online Strategies Assistive
>>>>>>>>> Technologies
>>>>>>>>> 1180 Torgersen Hall
>>>>>>>>> 620 Drillfield Drive (0434)
>>>>>>>>> Blacksburg, Virginia 24061
>>>>>>>>> >>>>>>>>> >>>>>>>>> list
>>>>>>>>> messages to <EMAIL REMOVED>
>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Robert Fentress
>>>>>>>> Senior Accessibility Solutions Designer
>>>>>>>> 540.231.1255
>>>>>>>>
>>>>>>>> Technology-enhanced Learning & Online Strategies
>>>>>>>> Assistive Technologies
>>>>>>>> 1180 Torgersen Hall
>>>>>>>> 620 Drillfield Drive (0434)
>>>>>>>> Blacksburg, Virginia 24061
>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>
>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>
>>>>
>>>>
>>>> --
>>>> Robert Fentress
>>>> Senior Accessibility Solutions Designer
>>>> 540.231.1255
>>>>
>>>> Technology-enhanced Learning & Online Strategies
>>>> Assistive Technologies
>>>> 1180 Torgersen Hall
>>>> 620 Drillfield Drive (0434)
>>>> Blacksburg, Virginia 24061
>>>> >>>> >>>> >>>>
>>> >>> >>> >>
>>
>>
>> --
>> 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