WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: vertical tabs and programmatic focus

for

From: Birkir R. Gunnarsson
Date: Jan 23, 2020 8:37PM

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