WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: Mar 26, 2015 8:17PM

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


--
Work hard. Have fun. Make history.