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
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>>> glen
>>> walker
>>> Sent: Friday, 24 January 2020 7:19 AM
>>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>>> Subject: Re: [WebAIM] vertical tabs and programmatic focus
>>>
>>> [External Email] This email was sent from outside the organisation – be
>>> cautious, particularly with links and attachments.
>>>
>>> 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 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.
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>> >>> >>> at
>>> http://webaim.org/discussion/archives
>>> >>> >>> >>> >>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> > > > > >


--
Work hard. Have fun. Make history.