WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus should always be set somewhere, right?

for

From: Aaron Cannon
Date: Feb 1, 2016 12:04PM

I think being put on the previous item makes more sense, since it is
more likely, IMHO, that the user would remember the previous item,
rather than remembering the count of items. They could then
(hopefully) see from the context that the item had been deleted.
Also, if the list is huge, I can imagine a KB user getting quite
annoyed by being sent back to the start of the list.

The only instance I think it makes sense to send the user to the next
item is if it was the first item which was deleted.

Aaron

On 2/1/16, Bourne, Sarah (ITD) < <EMAIL REMOVED> > wrote:
> In the use case you described, a keyboard-only user would probably want to
> be put on the next item. But it might be better for screen reader users to
> be put at the beginning of the list, where they would be told "list of [x-1]
> items" as an affirmation that the item was deleted, or maybe on the previous
> list item. I can't imagine either being pleased with being put back at the
> top of the page. This is where some user testing would be valuable, or at
> least an analysis of what kinds of tasks are being worked on and what would
> be a logical next step in a workflow.
>
> 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: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Robert Fentress
> Sent: Monday, February 01, 2016 11:37 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Focus should always be set somewhere, right?
>
> The issue is not dialogs, where what you say is correct, but with
> interactions where, for instance, there is a delete button at the end of a
> list item, and clicking it causes the list item and the delete button itself
> to disappear. There are other examples, but this is one I see frequently.
> On Jan 31, 2016 7:00 PM, "Sean Murphy" < <EMAIL REMOVED> > wrote:
>
>> My view is that the focus should be placed back on the last link you
>> activated to trigger the control. For example: If a pop-up occurs,
>> that provides you with the required controls. Such as playing a video,
>> editing a post, etc. Once the pop-up disappears, the focus is placed
>> back on the element to trigger the item. A pop-up could be a new
>> window or within the page. At least the user gets a consistent
>> behaviour. Placing the focus at the top of the page or the next item
>> in the element tab order isn't useful as this might not be the flow as
>> the user expects due to the method in which the assistive technology
>> handles the page.
>>
>> Sean
>> > On 31 Jan 2016, at 10:55 am, Robert Fentress < <EMAIL REMOVED> > wrote:
>> >
>> > Interesting about the VO heuristic for focus. Thanks.
>> >
>> > As regards where the cursor goes, I'm talking about something
>> > different than focus. For instance, in JAWS in the example of a
>> > control
>> disappearing
>> > that had had focus, I usually say focus becomes indeterminate.
>> > Pressing the tab key at that point (I think) moves focus (and the
>> > cursor) to the first focusable element on the page. However, if,
>> > instead, you press the down arrow at that point, it moves the
>> > virtual cursor somewhere seemingly random, not the top of the page.
>> > The focus remains indeterminate, unless you're in Autoforms Mode
>> > (and maybe Semi-Autoforms Mode) and the cursor happens to end up on
>> > a field. I think I've got the terminology right there, but to be frank
>> > I get lost in all that verbiage sometimes.
>> >
>> > On Sat, Jan 30, 2016 at 5:51 PM, Patrick H. Lauke <
>> <EMAIL REMOVED> >
>> > wrote:
>> >
>> >> On 30/01/2016 22:08, Robert Fentress wrote:
>> >>
>> >>> I just wanted to confirm that focus should always be set somewhere.
>> For
>> >>> instance, in rich internet applications you may interact with a
>> >>> control and that may cause the control to disappear. In those
>> >>> instances, focus
>> should
>> >>> always be explicitly set somewhere after that item is removed from
>> >>> the DOM, correct?
>> >>>
>> >>
>> >> Yes. One interesting thing I noticed (but haven't got around to
>> >> writing
>> up
>> >> anywhere) is that VO (at least on iOS) seems to have built-in
>> heuristics to
>> >> hunt for focus when it's lost - for instance, say you're currently on
>> the
>> >> close button of an HTML dialog, and that once closed the focus isn't
>> >> correctly set back somewhere sensible. VO will usually try to find the
>> >> focusable element that's nearest to the last known position in the
>> viewport
>> >> where it had focus, so it will generally set focus (unless done
>> explicitly)
>> >> to whatever was approximately under the close button in the main page.
>> >>
>> >> On a related note, are there rules for where the virtual cursor (or
>> >>> equivalent) in screen readers goes when such items are removed from
>> >>> the
>> >>> DOM? It seems pretty random in my experience, but perhaps there is a
>> >>> pattern I'm missing.
>> >>>
>> >>
>> >> Usually on desktop, the focus is lost completely - as if you entered
>> >> the
>> >> page again for the first time. On subsequent TAB you'd be focused on
>> >> the
>> >> first focusable element of the page. Maybe the randomness you
>> experience is
>> >> due to the heuristic above?
>> >>
>> >> P
>> >> --
>> >> Patrick H. Lauke
>> >>
>> >> www.splintered.co.uk | https://github.com/patrickhlauke
>> >> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> >> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> >> >> >> >> >> >>
>> >
>> >
>> >
>> > --
>> > 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
>> > >> > >> > >> > >>
>> >> >> >> >>
> > > > > > > > >