WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Avila
Date: Mar 26, 2015 11:22AM

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