E-mail List Archives
Thread: Focus should always be set somewhere, right?
Number of posts in this thread: 9 (In chronological order)
From: Robert Fentress
Date: Sat, Jan 30 2016 3:08PM
Subject: Focus should always be set somewhere, right?
No previous message | Next message →
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?
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.
Thanks.
From: Patrick H. Lauke
Date: Sat, Jan 30 2016 3:51PM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
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
From: Robert Fentress
Date: Sat, Jan 30 2016 4:55PM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
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 ADDRESS 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
From: Sean Murphy
Date: Sun, Jan 31 2016 4:59PM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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
> > > >
From: Robert Fentress
Date: Mon, Feb 01 2016 9:37AM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> > > > > > > > >
> > > > >
From: Bourne, Sarah (ITD)
Date: Mon, Feb 01 2016 11:54AM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
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 ADDRESS REMOVED =
http://www.mass.gov/MassIT
From: Aaron Cannon
Date: Mon, Feb 01 2016 12:04PM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED =
> http://www.mass.gov/MassIT
>
>
From: Robert Fentress
Date: Mon, Feb 01 2016 1:09PM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | Next message →
Aaron, your argument that the user is likely to remember the previous item
makes sense. However, on Windows 8 at least, if you are in "Details" view
in File Explorer, deleting an item causes the next item in the list to
receive focus, not the previous. I'd tend towards following the
interaction pattern that is closest to the one the user would experience at
the system level (crossing my fingers that this is the same on Mac and
popular Linux desktops).
But that is only one example of where the best place to set focus is not
totally clear. For instance, suppose you have a discussion forum and you
are on the index page where all of the different topics are listed. These
topics are grouped as follows: "Pinned Discussions", "Discussions". Beside
each topic name in "Discussions" is a button that says "Pin". Clicking the
"Pin" button causes the page to dynamically change, such that the topic is
moved to the "Pinned Discussions" group. Where should focus go in that
instance? Should it stay on the "Pin" button (which now says "Unpin"), or
should it go to the next or previous topic in the "Discussions" list?
Should events like these be accompanied by a polite live region
announcement, or would that be too verbose?
Also, sometimes, what might be considered most usable for one set of users
might make it less accessible for another. For instance, suppose you have
a button that says "New Widget" which causes a form to appear on another
region on the page. Keyboarders would likely greatly appreciate having
focus moved to the first field in that form. However, screen reader users
or those using screen magnification might find this disorienting.
Right now, it all seems very ad hoc. Anybody know of any standards beyond
the patterns described in the ARIA Authoring Practices document (
https://www.w3.org/TR/wai-aria-practices-1.1/), which is still in draft, I
think, and not prescriptive? Any books, articles, or papers that explore
this issue of focus management in depth, if not specifically for web
applications, then for user interfaces in general? Sarah, user testing is
great, if you can afford it, but it seems like more detailed guidance would
help developers who can't.
Or are we approaching things in the wrong way to try to closely hew to the
paradigm of the desktop? The web frees us from those constraints in a way,
for good or ill. There may be new paradigms that are more usable that what
is currently on tap that are just waiting to be discovered. We all have to
adapt to new ways of doing things as technology enables new possibilities,
but how do you make sure everybody is able to come along for the ride.
Chicken? Egg?
Best,
Rob
On Mon, Feb 1, 2016 at 2:04 PM, Aaron Cannon < = EMAIL ADDRESS REMOVED =
> wrote:
> 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 ADDRESS 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 ADDRESS REMOVED =
> > http://www.mass.gov/MassIT
> >
> >
From: Patrick H. Lauke
Date: Mon, Feb 01 2016 1:44PM
Subject: Re: Focus should always be set somewhere, right?
← Previous message | No next message
On 01/02/2016 20:09, Robert Fentress wrote:
> Aaron, your argument that the user is likely to remember the previous item
> makes sense. However, on Windows 8 at least, if you are in "Details" view
> in File Explorer, deleting an item causes the next item in the list to
> receive focus, not the previous.
This pattern makes sense in these situations, I'd say - it would allow
quick "triage" of lists of items.
> But that is only one example of where the best place to set focus is not
> totally clear.
Indeed I think this is all very dependent on the specific case being
reviewed, and starts crossing over into usability.
> For instance, suppose you have a discussion forum and you
> are on the index page where all of the different topics are listed. These
> topics are grouped as follows: "Pinned Discussions", "Discussions". Beside
> each topic name in "Discussions" is a button that says "Pin". Clicking the
> "Pin" button causes the page to dynamically change, such that the topic is
> moved to the "Pinned Discussions" group. Where should focus go in that
> instance? Should it stay on the "Pin" button (which now says "Unpin"), or
> should it go to the next or previous topic in the "Discussions" list?
You may even want to move focus back right to the start of the list of
topics, though personally I'd probably tend to think focus should stay
on the control (now changed to "Unpin").
> Should events like these be accompanied by a polite live region
> announcement, or would that be too verbose?
In this case, yes - some confirmation message that the topic has now
been pinned and moved to the top of the topics list.
> Right now, it all seems very ad hoc. Anybody know of any standards beyond
> the patterns described in the ARIA Authoring Practices document (
> https://www.w3.org/TR/wai-aria-practices-1.1/), which is still in draft, I
> think, and not prescriptive?
As it's - in my mind at least - so dependent on each specific case and
what the current goal of the user is, I'd be wary of a single standard
trying to authoritively address all scenarios, beyond using vague "make
sure focus moves to the most sensible spot..." advice.
> Or are we approaching things in the wrong way to try to closely hew to the
> paradigm of the desktop? The web frees us from those constraints in a way,
> for good or ill. There may be new paradigms that are more usable that what
> is currently on tap that are just waiting to be discovered. We all have to
> adapt to new ways of doing things as technology enables new possibilities,
> but how do you make sure everybody is able to come along for the ride.
> Chicken? Egg?
Some desktop patterns may be clunky, but they'll be what most users are
probably familiar with / had to get used to. Not saying they should be
followed without question, but they can certainly provide some data
points when you're trying to find the solution that's right for your
very individual situation.
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