E-mail List Archives
Thread: Focus reset
Number of posts in this thread: 12 (In chronological order)
From: Sumit Patel
Date: Sun, Apr 16 2023 10:38PM
Subject: Focus reset
No previous message | Next message →
Hai all,
I have come across a page where we have a group of buttons in the left
side and related contents will be updating in the right side based on
our selection in the left side. As we land on the page, no button is
selected. so, right side, we don't have any contents.
In the dom order, first focus goes to the left side contents then to
the right . so, it is fine .
I would like to know which way would be the right one to communicate
to the screen reader user that contents updated in the right side
after selecting any of the buttons
I could think of 3 ways.
1. Setting the focus to the start of the updated contents after
selecting any of the buttons
But, I don't think this is the right way . Because, sighted
keyboard-only user won't be interested with this approach as they have
to do multiple shift+ tab always if they want to select other buttons
and see related contents.
2. Giving an offscreen instruction at the top of the group of buttons
and associating it with the group using aria-describedby . for
example: selection of any of these buttons add contents below
This works and does not create any trrouble for anyone. but, is it the
better way . not sure
Is it enough for a screen reader users ?
3. Providing an alert message as soon a the contents appears
I think this is the better one. I assume this gives clear information
to screen reader users .
but, what would be the right alert message ? we have a section heading
like "product features".
Is it sufficient if we make this heading get announced ? or do we need
to give any offscreen alert message like "contents are updated "
Please suggest me what would be the right solution
Thanks in advance,
Sumit .
From: bhargavvaghasiya24@gmail.com
Date: Sun, Apr 16 2023 11:20PM
Subject: Re: Focus reset
← Previous message | Next message →
Hi Sumit,
Personally I feel the third approach is good one. Also states can be provided to the button whether it is selected or not.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Monday, 17 April, 2023 10:08 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Focus reset
Hai all,
I have come across a page where we have a group of buttons in the left side and related contents will be updating in the right side based on our selection in the left side. As we land on the page, no button is selected. so, right side, we don't have any contents.
In the dom order, first focus goes to the left side contents then to the right . so, it is fine .
I would like to know which way would be the right one to communicate to the screen reader user that contents updated in the right side after selecting any of the buttons
I could think of 3 ways.
1. Setting the focus to the start of the updated contents after selecting any of the buttons
But, I don't think this is the right way . Because, sighted keyboard-only user won't be interested with this approach as they have to do multiple shift+ tab always if they want to select other buttons and see related contents.
2. Giving an offscreen instruction at the top of the group of buttons and associating it with the group using aria-describedby . for
example: selection of any of these buttons add contents below
This works and does not create any trrouble for anyone. but, is it the better way . not sure Is it enough for a screen reader users ?
3. Providing an alert message as soon a the contents appears I think this is the better one. I assume this gives clear information to screen reader users .
but, what would be the right alert message ? we have a section heading like "product features".
Is it sufficient if we make this heading get announced ? or do we need to give any offscreen alert message like "contents are updated "
Please suggest me what would be the right solution
Thanks in advance,
Sumit .
From: Miriam Fukushima
Date: Mon, Apr 17 2023 1:02AM
Subject: Re: Focus reset
← Previous message | Next message →
Hi everyone,
out of interest, would it be possible to make a tablist out of it?
Although then at the start the first button with its corresponding
content would be visible.
Regards Miriam
On 17/04/2023 07:20, = EMAIL ADDRESS REMOVED = wrote:
> Hi Sumit,
>
>
>
> Personally I feel the third approach is good one. Also states can be provided to the button whether it is selected or not.
>
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
> Sent: Monday, 17 April, 2023 10:08 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Focus reset
>
>
>
> Hai all,
>
>
>
> I have come across a page where we have a group of buttons in the left side and related contents will be updating in the right side based on our selection in the left side. As we land on the page, no button is selected. so, right side, we don't have any contents.
>
> In the dom order, first focus goes to the left side contents then to the right . so, it is fine .
>
> I would like to know which way would be the right one to communicate to the screen reader user that contents updated in the right side after selecting any of the buttons
>
>
>
> I could think of 3 ways.
>
>
>
> 1. Setting the focus to the start of the updated contents after selecting any of the buttons
>
>
>
> But, I don't think this is the right way . Because, sighted keyboard-only user won't be interested with this approach as they have to do multiple shift+ tab always if they want to select other buttons and see related contents.
>
>
>
> 2. Giving an offscreen instruction at the top of the group of buttons and associating it with the group using aria-describedby . for
>
> example: selection of any of these buttons add contents below
>
>
>
> This works and does not create any trrouble for anyone. but, is it the better way . not sure Is it enough for a screen reader users ?
>
>
>
> 3. Providing an alert message as soon a the contents appears I think this is the better one. I assume this gives clear information to screen reader users .
>
> but, what would be the right alert message ? we have a section heading like "product features".
>
> Is it sufficient if we make this heading get announced ? or do we need to give any offscreen alert message like "contents are updated "
>
>
>
> Please suggest me what would be the right solution
>
>
>
>
>
> Thanks in advance,
>
> Sumit .
>
> >
> >
> >
> > > >
From: Mark Magennis
Date: Mon, Apr 17 2023 2:11AM
Subject: Re: Focus reset
← Previous message | Next message →
Option 1 would be appropriate if you can pretty much guarantee that the user will want to start interacting with the content on the right after it appears and won't want to select any other button. And in that case they should be links, not buttons.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Monday 17 April 2023 05:38
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] [WebAIM] Focus reset
Hai all,
I have come across a page where we have a group of buttons in the left side and related contents will be updating in the right side based on our selection in the left side. As we land on the page, no button is selected. so, right side, we don't have any contents.
In the dom order, first focus goes to the left side contents then to the right . so, it is fine .
I would like to know which way would be the right one to communicate to the screen reader user that contents updated in the right side after selecting any of the buttons
I could think of 3 ways.
1. Setting the focus to the start of the updated contents after selecting any of the buttons
But, I don't think this is the right way . Because, sighted keyboard-only user won't be interested with this approach as they have to do multiple shift+ tab always if they want to select other buttons and see related contents.
2. Giving an offscreen instruction at the top of the group of buttons and associating it with the group using aria-describedby . for
example: selection of any of these buttons add contents below
This works and does not create any trrouble for anyone. but, is it the better way . not sure Is it enough for a screen reader users ?
3. Providing an alert message as soon a the contents appears I think this is the better one. I assume this gives clear information to screen reader users .
but, what would be the right alert message ? we have a section heading like "product features".
Is it sufficient if we make this heading get announced ? or do we need to give any offscreen alert message like "contents are updated "
Please suggest me what would be the right solution
Thanks in advance,
Sumit .
From: glen walker
Date: Mon, Apr 17 2023 9:18AM
Subject: Re: Focus reset
← Previous message | Next message →
As Miriam said, this sounds like the tablist pattern,
https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
When you have role="tablist" on the container and role="tab" on the
buttons, that's a clue to the screen reader user that selecting the button
will update the page (it usually unhides the container with
role="tabpanel").
If your page does not follow the tablist pattern, then is there enough
context on the page to indicate that selecting a button will reveal new
content? For example, the button label might make it obvious if it was
something like "reveal address information". Or the heading for the group
of buttons might have the context.
I rarely move the keyboard focus so your option 1 would be my last choice.
As a keyboard user myself, I don't like it when the page thinks it knows
better than I do where my focus should go. I want to be in control.
If you can't use the tablist pattern and the context of your headings and
button labels don't make it obvious that new content will appear, then
either/both of option 2 and 3 is the next best choice. I prefer 2 over 3
because as a new user to your page, I might want to know that selecting a
button will reveal content but if I visit your page frequently, I don't
want to be constantly told that new content appeared (option 3) everytime I
select a button.
From: Mark Magennis
Date: Mon, Apr 17 2023 10:24AM
Subject: Re: Focus reset
← Previous message | Next message →
One of the problems users have with tablists is that to be coherent to sighted keyboard users they have to look like tabs. If they look like a series of buttons or links users will expect them to behave that way and will not expect to have to use the arrow keys to select a different tab . When tabbing between them doesn't work they may become confused or think they are unavailable or not working.
Back in the old days tabs used to look like paper filing cabinet tabs so that was fine. The keyboard interaction was guessable. But I think we're talking here about a vertical list of options and vertical tablists are rare. And I'll bet your UX designers have no intention of making them look anything like tabs.
So I wouldn't use a tablist here.
Mark
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday 17 April 2023 16:18
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] Re: [WebAIM] Focus reset
As Miriam said, this sounds like the tablist pattern, https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
When you have role="tablist" on the container and role="tab" on the buttons, that's a clue to the screen reader user that selecting the button will update the page (it usually unhides the container with role="tabpanel").
If your page does not follow the tablist pattern, then is there enough context on the page to indicate that selecting a button will reveal new content? For example, the button label might make it obvious if it was something like "reveal address information". Or the heading for the group of buttons might have the context.
I rarely move the keyboard focus so your option 1 would be my last choice.
As a keyboard user myself, I don't like it when the page thinks it knows better than I do where my focus should go. I want to be in control.
If you can't use the tablist pattern and the context of your headings and button labels don't make it obvious that new content will appear, then either/both of option 2 and 3 is the next best choice. I prefer 2 over 3 because as a new user to your page, I might want to know that selecting a button will reveal content but if I visit your page frequently, I don't want to be constantly told that new content appeared (option 3) everytime I select a button.
From: glen walker
Date: Mon, Apr 17 2023 10:43AM
Subject: Re: Focus reset
← Previous message | Next message →
Hard to say. We don't have a lot of details about the visuals or layout
other than the left/right description. But behaviorally, it sounded like a
tab pattern.
A similar type of pattern with left selection and right panels is often
seen in "settings" type interfaces, such as the NVDA or JAWS settings
dialog. NVDA uses a list in the left navigation and JAWS uses a tree, but
both allow you to select an element on the left side and the right side
updates, but you're not told that something updated on the right and the
keyboard focus is not moved.
On Mon, Apr 17, 2023 at 10:25â¯AM Mark Magennis < = EMAIL ADDRESS REMOVED = >
wrote:
> One of the problems users have with tablists is that to be coherent to
> sighted keyboard users they have to look like tabs. If they look like a
> series of buttons or links users will expect them to behave that way and
> will not expect to have to use the arrow keys to select a different tab .
> When tabbing between them doesn't work they may become confused or think
> they are unavailable or not working.
>
> Back in the old days tabs used to look like paper filing cabinet tabs so
> that was fine. The keyboard interaction was guessable. But I think we're
> talking here about a vertical list of options and vertical tablists are
> rare. And I'll bet your UX designers have no intention of making them look
> anything like tabs.
>
> So I wouldn't use a tablist here.
>
> Mark
>
>
From: Sumit Patel
Date: Mon, Apr 17 2023 10:34PM
Subject: Re: Focus reset
← Previous message | Next message →
Thanks all for your responses. These buttons do not look like tabs.
Initially even I thought the same giving "tab" role and associated
properties . so, screen reader user will understand contents would
have updated below after selection. They will have understanding about
the keyboard navigation when they hear "tab" role that they need to
use arrow keys if they want to move to other tabs. but, as mark said,
sighted keyboard-only user won't have any idea about this as this does
not look like a tab. They will be thinking that the other buttons are
not keybord focusable.
On 17/04/2023, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Hard to say. We don't have a lot of details about the visuals or layout
> other than the left/right description. But behaviorally, it sounded like a
> tab pattern.
>
> A similar type of pattern with left selection and right panels is often
> seen in "settings" type interfaces, such as the NVDA or JAWS settings
> dialog. NVDA uses a list in the left navigation and JAWS uses a tree, but
> both allow you to select an element on the left side and the right side
> updates, but you're not told that something updated on the right and the
> keyboard focus is not moved.
>
> On Mon, Apr 17, 2023 at 10:25â¯AM Mark Magennis < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> One of the problems users have with tablists is that to be coherent to
>> sighted keyboard users they have to look like tabs. If they look like a
>> series of buttons or links users will expect them to behave that way and
>> will not expect to have to use the arrow keys to select a different tab .
>> When tabbing between them doesn't work they may become confused or think
>> they are unavailable or not working.
>>
>> Back in the old days tabs used to look like paper filing cabinet tabs so
>> that was fine. The keyboard interaction was guessable. But I think we're
>> talking here about a vertical list of options and vertical tablists are
>> rare. And I'll bet your UX designers have no intention of making them look
>> anything like tabs.
>>
>> So I wouldn't use a tablist here.
>>
>> Mark
>>
>>
> > > > >
From: glen walker
Date: Tue, Apr 18 2023 9:50AM
Subject: Re: Focus reset
← Previous message | Next message →
The authoring practice patterns are best practices but you don't
necessarily have to follow them exactly. I rarely say that because I think
if we all design/code using similar patterns, that makes it easier for the
user to recognize those patterns on different websites and they'll
inherently know how to interact with them. In your case, you could have
the buttons be a vertical tab list, I see those occasionally, but you don't
have to style them to look like tabs on a folder. They could just be a
stack of vertical buttons.
And you could implement both arrow key navigation and tab key navigation.
Yes, the default tab design pattern uses arrow keys to navigate between the
buttons so that the tab container is one tab stop, but if your user testing
shows people are more likely to TAB to the different buttons, there's
nothing that says you can't do both. That would veer away from the keyboard
interaction pattern a bit but the end goal is to make it easy for the user
to understand.
On Mon, Apr 17, 2023 at 10:34â¯PM Sumit Patel < = EMAIL ADDRESS REMOVED = >
wrote:
> Thanks all for your responses. These buttons do not look like tabs.
> Initially even I thought the same giving "tab" role and associated
> properties . so, screen reader user will understand contents would
> have updated below after selection. They will have understanding about
> the keyboard navigation when they hear "tab" role that they need to
> use arrow keys if they want to move to other tabs. but, as mark said,
> sighted keyboard-only user won't have any idea about this as this does
> not look like a tab. They will be thinking that the other buttons are
> not keybord focusable.
>
>
From: Sumit Patel
Date: Wed, Apr 19 2023 12:38AM
Subject: Re: Focus reset
← Previous message | Next message →
Ok, I appreciate your response.
I have seen testers report this as either a violation or best
practice. I meant the scenario where all the tabs are keyboard
focusable in a group and they recommend only the selected tab should
receive tab focus and able to move around using arrow keys.
whether is it something really to be reported or not?
This is in case these tabs really look like tabs.
On 18/04/2023, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> The authoring practice patterns are best practices but you don't
> necessarily have to follow them exactly. I rarely say that because I think
> if we all design/code using similar patterns, that makes it easier for the
> user to recognize those patterns on different websites and they'll
> inherently know how to interact with them. In your case, you could have
> the buttons be a vertical tab list, I see those occasionally, but you don't
> have to style them to look like tabs on a folder. They could just be a
> stack of vertical buttons.
>
> And you could implement both arrow key navigation and tab key navigation.
> Yes, the default tab design pattern uses arrow keys to navigate between the
> buttons so that the tab container is one tab stop, but if your user testing
> shows people are more likely to TAB to the different buttons, there's
> nothing that says you can't do both. That would veer away from the keyboard
> interaction pattern a bit but the end goal is to make it easy for the user
> to understand.
>
> On Mon, Apr 17, 2023 at 10:34â¯PM Sumit Patel < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Thanks all for your responses. These buttons do not look like tabs.
>> Initially even I thought the same giving "tab" role and associated
>> properties . so, screen reader user will understand contents would
>> have updated below after selection. They will have understanding about
>> the keyboard navigation when they hear "tab" role that they need to
>> use arrow keys if they want to move to other tabs. but, as mark said,
>> sighted keyboard-only user won't have any idea about this as this does
>> not look like a tab. They will be thinking that the other buttons are
>> not keybord focusable.
>>
>>
> > > > >
From: Glen Walker
Date: Wed, Apr 19 2023 1:41AM
Subject: Re: Focus reset
← Previous message | Next message →
Whether you use the arrow keys to navigate or the tab key to navigate is not a WCAG issue.
Sent from my iPhone
> On Apr 19, 2023, at 12:38 AM, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>
> Ok, I appreciate your response.
>
> I have seen testers report this as either a violation or best
> practice. I meant the scenario where all the tabs are keyboard
> focusable in a group and they recommend only the selected tab should
> receive tab focus and able to move around using arrow keys.
>
> whether is it something really to be reported or not?
> This is in case these tabs really look like tabs.
>
>
>
>> On 18/04/2023, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>> The authoring practice patterns are best practices but you don't
>> necessarily have to follow them exactly. I rarely say that because I think
>> if we all design/code using similar patterns, that makes it easier for the
>> user to recognize those patterns on different websites and they'll
>> inherently know how to interact with them. In your case, you could have
>> the buttons be a vertical tab list, I see those occasionally, but you don't
>> have to style them to look like tabs on a folder. They could just be a
>> stack of vertical buttons.
>>
>> And you could implement both arrow key navigation and tab key navigation.
>> Yes, the default tab design pattern uses arrow keys to navigate between the
>> buttons so that the tab container is one tab stop, but if your user testing
>> shows people are more likely to TAB to the different buttons, there's
>> nothing that says you can't do both. That would veer away from the keyboard
>> interaction pattern a bit but the end goal is to make it easy for the user
>> to understand.
>>
>> On Mon, Apr 17, 2023 at 10:34â¯PM Sumit Patel < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Thanks all for your responses. These buttons do not look like tabs.
>>> Initially even I thought the same giving "tab" role and associated
>>> properties . so, screen reader user will understand contents would
>>> have updated below after selection. They will have understanding about
>>> the keyboard navigation when they hear "tab" role that they need to
>>> use arrow keys if they want to move to other tabs. but, as mark said,
>>> sighted keyboard-only user won't have any idea about this as this does
>>> not look like a tab. They will be thinking that the other buttons are
>>> not keybord focusable.
>>>
>>>
>> >> >> >> >>
> > > >
From: Mark Magennis
Date: Wed, Apr 19 2023 2:17AM
Subject: Re: Focus reset
← Previous message | No next message
I think the reason most tab bar patterns allow only arrow key selection of tabs and not tabbing between tabs is that this follows a general pattern for UI widgets that you tab into and out of the widget and use arrow keys to navigate within it. This pattern is explained in the ARIA Authoring Practices document 'Developing a Keyboard Interface' (https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/) under 'Fundamental Keyboard Navigation Conventions'.
The benefit of this 'tab in, tab out' pattern for keyboard users is that if you don't want to interact with a widget you can get past it very quickly without having to tab through everything inside it. However, for most tab bars this doesn't really save you much effort because they generally contain only a few tabs. But for controls like a file hierarchy tree view or an interactive grid it can be essential.
Another thing about tab bars is that most often the tabs are scripted to activate automatically on focus. That is, when you go to a tab its tab panel appears without you having to activate it by pressing Enter. Unless the tab panel contents may take a long time to load (which generates issues explained in the ARIA Practices Tabs pattern) this is the best experience for users. But if you have implemented tabbing between tabs as well as arrowing this means that you can't get past the tab bar without displaying every tab panel in turn, potentially changing the page content multiple times without any need. This may not be a huge problem but I imagine it could be annoying or disconcerting.
Someone wrote a very interesting article a few years ago based on the results of user testing tab bars and I would recommend you find it if you can and read through it and the subsequent discussion it generated. Their conclusion was that tab bars are an abomination that many users struggle with and we need to rethink them. Their proposals for making them more usable included allowing users to tab between tabs as favoured by Glen. I seem to remember though that they were severely criticised by some prominent members of the accessibility developers community, mostly on the grounds that they were violating established conventions. My memory is a bit hazy so I could be wrong and I need to dig it out and re-read it myself now because I made a mental note at the time to rethink my own opinions on tab bars but never got around to it. I do remember having a lot of sympathy for their position because my background is in usability and user testing and I've found that, aside from fundamental things like buttons and fields with no names, most of the biggest problems users with disabilities and users of assistive technologies face are not WCAG failures. They are to do with understandability, discoverability, complexity, efficiency and the like and are often general usability issues that more acutely affect that user group. A lot of things that work in theory turn out not to work well in practice so I tend to value the findings of user testing very highly.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Wednesday 19 April 2023 07:39
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Focus reset
Ok, I appreciate your response.
I have seen testers report this as either a violation or best practice. I meant the scenario where all the tabs are keyboard focusable in a group and they recommend only the selected tab should receive tab focus and able to move around using arrow keys.
whether is it something really to be reported or not?
This is in case these tabs really look like tabs.
On 18/04/2023, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> The authoring practice patterns are best practices but you don't
> necessarily have to follow them exactly. I rarely say that because I
> think if we all design/code using similar patterns, that makes it
> easier for the user to recognize those patterns on different websites
> and they'll inherently know how to interact with them. In your case,
> you could have the buttons be a vertical tab list, I see those
> occasionally, but you don't have to style them to look like tabs on a
> folder. They could just be a stack of vertical buttons.
>
> And you could implement both arrow key navigation and tab key navigation.
> Yes, the default tab design pattern uses arrow keys to navigate
> between the buttons so that the tab container is one tab stop, but if
> your user testing shows people are more likely to TAB to the different
> buttons, there's nothing that says you can't do both. That would veer
> away from the keyboard interaction pattern a bit but the end goal is
> to make it easy for the user to understand.
>
> On Mon, Apr 17, 2023 at 10:34â¯PM Sumit Patel
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Thanks all for your responses. These buttons do not look like tabs.
>> Initially even I thought the same giving "tab" role and associated
>> properties . so, screen reader user will understand contents would
>> have updated below after selection. They will have understanding
>> about the keyboard navigation when they hear "tab" role that they
>> need to use arrow keys if they want to move to other tabs. but, as
>> mark said, sighted keyboard-only user won't have any idea about this
>> as this does not look like a tab. They will be thinking that the
>> other buttons are not keybord focusable.
>>
>>
> > > archives at http://webaim.org/discussion/archives
> >