WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

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

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

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

Best, Lynn

On 26/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
> Lynn, related to the "empty list" alert, what about alerts for other
> changes to the list? For instance, would it be best practice to have
> ARIA alerts triggered whenever something was added or removed from the
> list as well? These probably shouldn't be visible alerts (though I'm
> open to arguments as to why they should be), but, for users who are
> blind, they may serve as useful confirmation that their action was
> successful. I could also see, though, how this might be viewed as
> unnecessarily verbose.
>
> What do you folks think about the use of ARIA alerts in instances like
> these?
>
> Best,
> Rob
>
> On Wed, Mar 25, 2015 at 4:13 PM, Lynn Holdsworth
> < <EMAIL REMOVED> > wrote:
>> Hi all,
>>
>> I'm watching this thread with interest.
>>
>> I would argue that this is an accessibility rather than a usability
>> issue, since the loss of focus is likely to cause blind users not to
>> be sure where they are in the page, and keyboard users to take
>> significantly longer to achieve their goal.
>>
>> Invaluable though the guidelines are, I think that concentrating
>> solely on these puts developers and designers at a dangerous remove
>> from what accessibility aims to achieve: i.e. making it possible for
>> the huge number of people who would otherwise be disadvantaged to buy,
>> sell, read, contribute to, learn from, or use the products or services
>> being offered by the website or app they're creating.
>>
>> The Google Drive approach seems to work quite well. I've seen a model
>> where the container is injected with hidden text saying "Empty list".
>> I personally find this little message very useful.
>>
>> Best, Lynn
>>
>> On 25/03/2015, Robert Fentress < <EMAIL REMOVED> > wrote:
>>> Whitney and Cliff, thanks for your takes on the issue.
>>>
>>> While it is true that usability is what we should focus on, I have had
>>> the reaction of "Well, that's just a usability problem," and, because
>>> it isn't specifically addressed by a success criterion, it is not
>>> given priority as something that needs to be fixed.
>>>
>>> I've looked at a couple of other examples to help in analyzing the
>>> issue, and I'll share what I've found in case it is of value to
>>> others.
>>>
>>> In the Windows File Explorer in Detail View, if you have a list of
>>> files, and you delete one, focus shifts to the next file in the list.
>>> If you delete the last file in the list, but there are still files
>>> left, focus shifts to the new last item in the list. If there is only
>>> one file left and you delete that, focus shifts to the first column
>>> header in the file list pane.
>>>
>>> In Google Drive, the pattern is the same, except when the last item is
>>> deleted, focus shifts to the file list pane as a whole, since the
>>> column headings disappear when the last file is removed.
>>>
>>> At the moment, I think I like the pattern Google Drive uses here.
>>>
>>> On Wed, Mar 25, 2015 at 9:18 AM, Cliff Tyllick < <EMAIL REMOVED> > wrote:
>>>> Well said, Whitney!
>>>>
>>>> And that's the kind of solution we can inspire when we frame the issue
>>>> as
>>>> a barrier to usability rather than the failure of a checkpoint or
>>>> success
>>>> criterion.
>>>>
>>>> We will have to qualify the conditions under which the barrier
>>>> exists—for
>>>> example, when reading the page through a certain technology; or, as in
>>>> this case, when human—but in doing so we establish conditions that must
>>>> be
>>>> met if the project is to succeed.
>>>>
>>>> Read through Whitney's answer again and I think you'll see how focusing
>>>> on
>>>> what success would look like, not on the rule that we failed, led
>>>> directly
>>>> to specific qualities the product must have if it is to pass QA.
>>>>
>>>> Cliff Tyllick
>>>>
>>>> Sent from my iPhone
>>>> Although its spellcheck often saves me, all goofs in sent messages are
>>>> its
>>>> fault.
>>>>
>>>>> On Mar 25, 2015, at 7:18 AM, Whitney Quesenbery < <EMAIL REMOVED> >
>>>>> wrote:
>>>>>
>>>>> Where should the focus go: In the least disruptive place for the user:
>>>>>
>>>>> - Causes the least redisplay of the page or movement within it
>>>>> - Leaves them in familiar place, so they can maintain orientation
>>>>> - Does not disrupt the task flow.
>>>>>
>>>>> Typically, this should be either the item above or below the one just
>>>>> deleted.
>>>>>
>>>>> There are patterns for this sort of list management, even without a
>>>>> visible
>>>>> "x" button to delete the item. I've seen it done both ways, and I've
>>>>> seen
>>>>> programs that are smart enough to move through a list as items are
>>>>> being
>>>>> deleted adjusting to whether the user is moving up or down in the list.
>>>>>
>>>>> The usability problem is that if the list is being read top to bottom,
>>>>> the
>>>>> familiar location is the item above, but this causes extra navigation.
>>>>>
>>>>> Example. Consider this list:
>>>>>
>>>>> Item One
>>>>> Item Two
>>>>> Item Three to be deleted
>>>>> Item Four
>>>>>
>>>>> If the user is tabbing (or using ArrowDown) through the list and
>>>>> deletes
>>>>> Item Three, then Item Four is the next logical point for the focus to
>>>>> land,
>>>>> following the navigation direction. If they are using Shift-Tab or
>>>>> ArrowUp
>>>>> the reverse is true.
>>>>>
>>>>> A visual reader is not thrown back to the top of the page, and neither
>>>>> should the non-visual interaction.
>>>>>
>>>>> The usability of the visual experience depends on how smoothly the
>>>>> program
>>>>> manages the visual transition. In the example above, Item Four should
>>>>> be
>>>>> able to slide up into position without disturbing the visual display
>>>>> above
>>>>> the deleted item. The same should be true for a non-visual user.
>>>>>
>>>>>
>>>>>> On Tue, Mar 24, 2015 at 2:30 PM Cliff Tyllick < <EMAIL REMOVED> >
>>>>>> wrote:
>>>>>>
>>>>>> Rob, I'm going to go out on a limb here and say that the problem is
>>>>>> that
>>>>>> loss of focus is not addressed by the guidelines.
>>>>>>
>>>>>> Focus order is (SC 2.4.3). Focus visibility is (SC 2.4.7). But not the
>>>>>> simple case of, "Oops, nothing to focus on, so let's take it again
>>>>>> from
>>>>>> the
>>>>>> top!"
>>>>>>
>>>>>> I guess we could stretch SC 2.4.8, Location, to cover loss of focus.
>>>>>> If
>>>>>> you can't find the focus, you can't tell where you are in the page.
>>>>>> But
>>>>>> that's Level AAA, and this seems like a Level A problem to me.
>>>>>>
>>>>>> Worse yet, no matter what success criterion I select for failing this
>>>>>> Web
>>>>>> content, it won't be a clear fit. And that means I could expect
>>>>>> pushback
>>>>>> from whoever I must tell, "Keep working. This isn't good enough."
>>>>>>
>>>>>> The problem is that we're trying to turn accessibility into a
>>>>>> one-size-fits-all checklist. That's a problem because a checklist
>>>>>> can't
>>>>>> easily accommodate loose ends, and accessibility has many. And it's
>>>>>> also
>>>>>> a
>>>>>> problem because the items we're using for checkpoints—the success
>>>>>> criteria—are meant to document ways to succeed, not to pinpoint every
>>>>>> possible way to fail.
>>>>>>
>>>>>> So what can we measure against? Instead of details, why not focus on
>>>>>> the
>>>>>> big picture? Use performance objectives:
>>>>>> ' A person who is blind must be able to perceive, operate, and
>>>>>> understand
>>>>>> this Web page and its contents.
>>>>>> ' A person who has low moderate vision must be able to perceive,
>>>>>> operate,
>>>>>> and understand this Web page and its contents.
>>>>>> ' A person who is deaf must be able to perceive, operate, and
>>>>>> understand
>>>>>> this Web page and its contents.
>>>>>> ' And so on.
>>>>>>
>>>>>> The Guidelines and Success Criteria could then be used as intended—as
>>>>>> information to help project teams figure out likely solutions, not as
>>>>>> absolute measures of sufficient accessibility.
>>>>>>
>>>>>> The ultimate measure of accessibility, then, would be a usability test
>>>>>> by
>>>>>> people for whom the feature being tested might be a barrier.
>>>>>>
>>>>>> Whether I could find a Success Criterion we could use to fail an
>>>>>> inaccessible feature would be irrelevant. I would just need to note
>>>>>> that
>>>>>> our tester found it inaccessible and point the project team to
>>>>>> information
>>>>>> that might help them solve the problem.
>>>>>>
>>>>>> Because the big picture isn't that you should be able to complete some
>>>>>> kind of paperwork to document that your site is accessible. The big
>>>>>> picture
>>>>>> is that your customers should find your content fully usable,
>>>>>> regardless
>>>>>> of
>>>>>> their ability—so usable that they never realize that you had to remove
>>>>>> a
>>>>>> barrier that would have hindered them.
>>>>>>
>>>>>> Cliff Tyllick
>>>>>>
>>>>>> Sent from my iPhone
>>>>>> Although its spellcheck often saves me, all goofs in sent messages are
>>>>>> its
>>>>>> fault.
>>>>>>
>>>>>>> On Mar 23, 2015, at 11:28 AM, Robert Fentress via WebAIM-Forum <
>>>>>> <EMAIL REMOVED> > wrote:
>>>>>>>
>>>>>>> Thanks, Sarah. Your analysis is helpful.
>>>>>>>
>>>>>>> I agree that it is a usability issue, though, of course, it has
>>>>>> particular
>>>>>>> implications for accessibility. For instance, as you suggest, if an
>>>>>>> interaction causes focus to be lost entirely or causes it to go to
>>>>>>> the
>>>>>> top
>>>>>>> of the page, requiring the user to navigate back to a widget from the
>>>>>> start
>>>>>>> of the page, I would think this would be very problematic. My first
>>>>>>> thought was that this would cause a page to violate "WCAG 3.2.2 On
>>>>>> Input" (
>>>>>>> http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change),
>>>>>>> since this would count as an unexpected change of context (
>>>>>>> http://www.w3.org/TR/WCAG20/#context-changedef). However, the
>>>>>>> Understanding SC 3.2.2 working group note (
>>>>>>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-
>>>>>> unpredictable-change.html)
>>>>>>> indicates that activating a button is specifically excluded from the
>>>>>>> list
>>>>>>> of things counting as "Changing the setting of any user interface
>>>>>>> component." Would a page that did this technically violate any WCAG
>>>>>>> 2.0
>>>>>>> standard that you are aware of? Perhaps SC 3.2.5 would be relevant (
>>>>>>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-
>>>>>> extreme-changes-context.html)?
>>>>>>> What do you think?
>>>>>>>
>>>>>>> I ask because I am performing an internal review of a third-party web
>>>>>>> application for accessibility and in several instances focus is lost
>>>>>>> in
>>>>>>> this way. In my report, I would rather have some specific success
>>>>>>> criterion to point to, so it is not just my opinion about a usability
>>>>>>> issue.
>>>>>>>
>>>>>>> Also, I would like to be able to recommend what the best practice
>>>>>>> would
>>>>>> be
>>>>>>> in these sorts of situations. Right now, I'm thinking the best
>>>>>>> algorithm
>>>>>>> for deletions would be set focus to the grouped item immediately
>>>>>> following
>>>>>>> the item deleted (after a confirmation dialog, which I left out to
>>>>>> simplify
>>>>>>> the example), unless there are no more items in the list, in which
>>>>>>> case,
>>>>>>> focus should be set on the add button. We don't have the resources
>>>>>>> to
>>>>>>> do
>>>>>>> formal usability testing, so I kind of have to run the scenario in my
>>>>>>> own
>>>>>>> head. Here is my thinking:
>>>>>>>
>>>>>>> After deleting an item, what is the user most likely to want to do?
>>>>>>> It
>>>>>>> might be most reasonable to assume that they want to do something
>>>>>>> with
>>>>>> the
>>>>>>> next item in the list. What could they do? Well, in the example
>>>>>>> given,
>>>>>>> they could read the link text, follow the link text to view or edit
>>>>>>> the
>>>>>>> details of the item (unspecified, but assumed), or delete the item.
>>>>>>> So,
>>>>>>> focusing on the item as a whole, rather than on any component within
>>>>>>> it
>>>>>>> might be the best balance of directed guidance and flexibility. The
>>>>>>> user
>>>>>>> might also want to add an item, of course, but moving the focus there
>>>>>> would
>>>>>>> seem to be more disruptive, and require more navigation to get to the
>>>>>> other
>>>>>>> things the user might want to do. Focus could also be moved to the
>>>>>>> main
>>>>>>> container for the items, $("#items"), but, again this seems to be
>>>>>>> disruptive, in that it moves the user further away from where they
>>>>>>> were
>>>>>> at
>>>>>>> the initiation of the delete action.
>>>>>>>
>>>>>>> Best,
>>>>>>> Rob
>>>>>>>
>>>>>>> On Wed, Mar 18, 2015 at 4:56 PM, Bourne, Sarah (ITD) <
>>>>>>> <EMAIL REMOVED> > wrote:
>>>>>>>
>>>>>>>> Rob,
>>>>>>>>
>>>>>>>> Where the focus should go is more a usability issue than an
>>>>>> accessibility
>>>>>>>> requirement per se, and may requiring some testing by users to see
>>>>>>>> if
>>>>>>>> you've got it right. As a general rule, you want to put focus back
>>>>>>>> to
>>>>>>>> where the user was in the flow of the page. If it goes to the top
>>>>>>>> of
>>>>>> the
>>>>>>>> page, for instance, a keyboard-only user would have to tab all the
>>>>>>>> way
>>>>>> back
>>>>>>>> to "items" to continue item management.
>>>>>>>>
>>>>>>>> Since you can't put them back on the delete button once an item is
>>>>>>>> deleted, perhaps it could be replaced with a confirmation statement
>>>>>> (maybe
>>>>>>>> with an un-do action even) that the item was deleted. Lacking that,
>>>>>>>> I
>>>>>> would
>>>>>>>> think it should go to the next element - the next item link if there
>>>>>>>> is
>>>>>>>> one, or to the add item button. But user testing might show that
>>>>>>>> taking
>>>>>>>> them to the top of the list when at the end is more useful.
>>>>>>>>
>>>>>>>> I can't speak to exactly which ARIA attributes you should use, but
>>>>>>>> I
>>>>>>>> agree with Birkir that using list elements for the items would
>>>>>>>> improve
>>>>>>>> usability, and you would need something so the list and count is
>>>>>>>> updated
>>>>>>>> when items have been added or deleted.
>>>>>>>>
>>>>>>>> sb
>>>>>>>> Sarah E. Bourne
>>>>>>>> Director of IT Accessibility, MassIT
>>>>>>>> Commonwealth of Massachusetts
>>>>>>>> 1 Ashburton Pl. rm 1601 Boston MA 02108
>>>>>>>> 617-626-4502
>>>>>>>> <EMAIL REMOVED>
>>>>>>>> http://www.mass.gov/MassIT
>>>>>>>>
>>>>>>>>
>>>>>>>> -----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
> > > >