E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Reinhard Stebner
Date: Thu, Jan 23 2020 11:57AM
Subject: vertical tabs and programmatic focus
No previous message | Next message →

I am currently reviewing a page that has a vertical tab control in the
left and side of the page and the tab panel in the right side. the
left rail has additional links under the tabs that are not part of the
tab interface. How should focus be placed back on the tabs once focus
is on the tab panel seeing that there is additional links in the left
rail. I'm talking about when shift tabbing back to the tabs. thanks
for your help.

From: glen walker
Date: Thu, Jan 23 2020 1:19PM
Subject: Re: vertical tabs and programmatic focus
← Previous message | Next message →

Not sure I'm understanding completely but a few basic points on a tab
control:

* The tab list is typically one focus/tab stop. You tab (key) to the tab
list and then arrow through all the tabs.
* When arrowing between tabs, you can choose whether the tab panel is
automatically loaded or if the user has to select the tab first (space or
enter key)
* If the tab panel is automatically loaded, I would not automatically move
the focus into the tab panel contents. That would be an annoyance if I was
trying to arrow through the tab list to get to my desired tab
* If the user has to select the tab in order for the tab panel to be
loaded, I still would not move the focus automatically into the tab panel
contents but that's a decision up to you
* The tab panel contents should be the next tab stop after the tab list
(DOM order). That way I can arrow through the tab list, select the tab (if
not automatically loaded), then tab (key) into the tab panel contents

Now, all that being said, in your situation, it sounds like you have some
links under the tab list. Since the tab panel contents should be the next
tab stop after the tab list, your extra links would come in the tab/focus
order after the tab panel contents.


On Thu, Jan 23, 2020 at 1:57 PM Reinhard Stebner < = EMAIL ADDRESS REMOVED = >
wrote:

> I am currently reviewing a page that has a vertical tab control in the
> left and side of the page and the tab panel in the right side. the
> left rail has additional links under the tabs that are not part of the
> tab interface. How should focus be placed back on the tabs once focus
> is on the tab panel seeing that there is additional links in the left
> rail. I'm talking about when shift tabbing back to the tabs. thanks
> for your help.
> > > > >

From: Murphy, Sean
Date: Thu, Jan 23 2020 4:06PM
Subject: Re: vertical tabs and programmatic focus
← Previous message | Next message →

Glen and All,

From memory the ARIA specs do not recommend automatic focus change when changing tab items within a tab list. What Glen outlined is the approach I would recommend. If you use automatic focus, you get the old issue with drop downs (combo boxes) where the person cannot easily go to the 4th tab item in the tab list.

Sean

From: Birkir R. Gunnarsson
Date: Thu, Jan 23 2020 7:18PM
Subject: Re: vertical tabs and programmatic focus
← Previous message | Next message →

The ARIA Authoring Practices recommends that tabs be automatically
activated unless the tabpanel content takes a long time to load:
https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
It also does not require that tabpanel content follows tablist
immediately in the DOM order, though it is the best and most obvious
relationship.
It uses aria-controls on the tab and aria-labelledby on the tabpanel
to connect the two programmatically (though admittedly screen readers
don't do much with aria-controls).
I would recommend implementing vertical tabs as per the APG
recommendation. If you place a list of links between the tabs and the
tabpanel you may want to implement an additional shortcut keys such as
page up/page down to move from the active tab to its tabpanel and back
(this was a recommendation in the APG version 1.0 section for tabs),
though if you do you should implement a mechanism to notify keyboard
only and screen reader users of this shortcut.
I would also add a visually hidden sentence that describes the
rlationship between the tabs and the tabpanel, e.g. something like
"the tabpanel for the active tab is located at x, you can get there by y".
If the tabpanel content starts with a heading you can say something
like "by navigating to the next h3 heading".

Again, this isn't ideal, it would be better to not place content
between the tablist and the tabpanel, but sometimes designs require
that we work with less-than-ideal and it can be done in this case.


On 1/23/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
> Glen and All,
>
> From memory the ARIA specs do not recommend automatic focus change when
> changing tab items within a tab list. What Glen outlined is the approach I
> would recommend. If you use automatic focus, you get the old issue with drop
> downs (combo boxes) where the person cannot easily go to the 4th tab item in
> the tab list.
>
> Sean
>
>

From: Reinhard Stebner
Date: Thu, Jan 23 2020 8:18PM
Subject: Re: vertical tabs and programmatic focus
← Previous message | Next message →

Thank you, this answered my question quite nicely thank you once again for a very clear answer. The client, in this case, cannot rearrange content because of the way how the page is arranged the tabs are on the left side above content while the tab panel content is on the right. Thank you once again very much for your assistance.

Sent from my iPhone

> On Jan 23, 2020, at 9:19 PM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> The ARIA Authoring Practices recommends that tabs be automatically
> activated unless the tabpanel content takes a long time to load:
> https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
> It also does not require that tabpanel content follows tablist
> immediately in the DOM order, though it is the best and most obvious
> relationship.
> It uses aria-controls on the tab and aria-labelledby on the tabpanel
> to connect the two programmatically (though admittedly screen readers
> don't do much with aria-controls).
> I would recommend implementing vertical tabs as per the APG
> recommendation. If you place a list of links between the tabs and the
> tabpanel you may want to implement an additional shortcut keys such as
> page up/page down to move from the active tab to its tabpanel and back
> (this was a recommendation in the APG version 1.0 section for tabs),
> though if you do you should implement a mechanism to notify keyboard
> only and screen reader users of this shortcut.
> I would also add a visually hidden sentence that describes the
> rlationship between the tabs and the tabpanel, e.g. something like
> "the tabpanel for the active tab is located at x, you can get there by y".
> If the tabpanel content starts with a heading you can say something
> like "by navigating to the next h3 heading".
>
> Again, this isn't ideal, it would be better to not place content
> between the tablist and the tabpanel, but sometimes designs require
> that we work with less-than-ideal and it can be done in this case.
>
>
>> On 1/23/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
>> Glen and All,
>>
>> From memory the ARIA specs do not recommend automatic focus change when
>> changing tab items within a tab list. What Glen outlined is the approach I
>> would recommend. If you use automatic focus, you get the old issue with drop
>> downs (combo boxes) where the person cannot easily go to the 4th tab item in
>> the tab list.
>>
>> Sean
>>
>>

From: Birkir R. Gunnarsson
Date: Thu, Jan 23 2020 8:37PM
Subject: Re: vertical tabs and programmatic focus
← Previous message | No next message

You could rearrange content for screen readers only using the
aria-owns attribute.
(define a div element, use aria-owns with the id o attributes you want
it to own in the order you want them to be displayed by a screen
reader).

<div aria-owns="tlist" tpanel"></div>

<ul role="tablist" id="tlist">
</ul>

any other content

<div role="tabpanel" id="tpanel">]
tab panel stuff
</div>

This is fairly well supported,, a screen reader would show the tabs
and the tabpanel first, then the links.
The problem in this case is that now you are creating a huge
discrepancy between the focus order and the screen reader content
order, so just because you can do it doesn't mean you should. ;)
And yes, aria-controls sucks *grin*. Love that article.


On 1/23/20, Reinhard Stebner < = EMAIL ADDRESS REMOVED = > wrote:
> Thank you, this answered my question quite nicely thank you once again for a
> very clear answer. The client, in this case, cannot rearrange content
> because of the way how the page is arranged the tabs are on the left side
> above content while the tab panel content is on the right. Thank you once
> again very much for your assistance.
>
> Sent from my iPhone
>
>> On Jan 23, 2020, at 9:19 PM, Birkir R. Gunnarsson
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> The ARIA Authoring Practices recommends that tabs be automatically
>> activated unless the tabpanel content takes a long time to load:
>> https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
>> It also does not require that tabpanel content follows tablist
>> immediately in the DOM order, though it is the best and most obvious
>> relationship.
>> It uses aria-controls on the tab and aria-labelledby on the tabpanel
>> to connect the two programmatically (though admittedly screen readers
>> don't do much with aria-controls).
>> I would recommend implementing vertical tabs as per the APG
>> recommendation. If you place a list of links between the tabs and the
>> tabpanel you may want to implement an additional shortcut keys such as
>> page up/page down to move from the active tab to its tabpanel and back
>> (this was a recommendation in the APG version 1.0 section for tabs),
>> though if you do you should implement a mechanism to notify keyboard
>> only and screen reader users of this shortcut.
>> I would also add a visually hidden sentence that describes the
>> rlationship between the tabs and the tabpanel, e.g. something like
>> "the tabpanel for the active tab is located at x, you can get there by y".
>> If the tabpanel content starts with a heading you can say something
>> like "by navigating to the next h3 heading".
>>
>> Again, this isn't ideal, it would be better to not place content
>> between the tablist and the tabpanel, but sometimes designs require
>> that we work with less-than-ideal and it can be done in this case.
>>
>>
>>> On 1/23/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
>>> Glen and All,
>>>
>>> From memory the ARIA specs do not recommend automatic focus change when
>>> changing tab items within a tab list. What Glen outlined is the approach
>>> I
>>> would recommend. If you use automatic focus, you get the old issue with
>>> drop
>>> downs (combo boxes) where the person cannot easily go to the 4th tab item
>>> in
>>> the tab list.
>>>
>>> Sean
>>>
>>>