WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Tab controls and WCAG 1.4.10 Reflow

for

From: Birkir R. Gunnarsson
Date: Mar 31, 2022 5:44AM


It's a question of whether you make the tabpenl elements focusable
(adding tabindex="0") or not.
If you do, NVDA will snap out of application mode and start reading
the contents of the tabpanel when you focus it. It's also better for
sighed keyboard users, who can scroll the tabpanel if it is focusable.
It does add an extra tab stop (the tabpanel element has no function)
which might cause some confusion for some users.
If, however, the tabpanel element dois not focusable, your fcus will
land on the next focusable element after the tab, which might be part
of the ttabpanel content or it might be later on the page (if the
tabpanel has no focusable elements). In that case, your only solution
is to manually switch out of application mode to explore the tabpanel.
I remember discussing this when I was on the ARIA Authoring Practices
taskforce, but it was a long time ago and I don't remember whether we
came to a hard conclusion on the subject.
On the balance of things, I'd recommend making the tabpanel focusable,
but it is not an absolute requirement.

On 3/31/22, Geethavani.Shamanna < <EMAIL REMOVED> > wrote:
> I have a related question regarding tab panels.
>
> I am currently testing a page where there are four tabs. When in the Focus
> mode of NVDA, on selecting a tab and pressing the Tab key, the contents of
> the tab panel are not read out. NVDA merely says 'Property page'. However,
> on selecting a tab in the Browse/Document mode, on pressing the Tab key,
> NVDA reads out the contents of the tab panel. Should this not work in the
> Focus mode as well?
>
> In the following example, the tab panel contents are not read out in the
> Focus mode:
> https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-2/tabs.html
>
> Many thanks.
> Geetha
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Steve
> Green
> Sent: 31 March 2022 07:01
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Tab controls and WCAG 1.4.10 Reflow
>
> CAUTION: This mail comes from outside the University. Please consider this
> before opening attachments, clicking links, or acting on the content.
>
> This exact issue came up last week in an IAAP discussion, and our team
> discussed it internally for more than an hour. It seems simple at first, but
> it raises the question of what "scrolling" means, among other things. The
> WCAG authors must have assumed it's obvious, because they do not provide a
> definition.
>
> Opinion was split, both in IAAP and in our team. My view is that a Tab
> component does not require two-dimensional layout, and that the tabs can
> perfectly well wrap onto two or more lines. Indeed, I failed one of our
> clients' sites on this exact issue.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Laurence Lewis
> Sent: 31 March 2022 06:53
> To: <EMAIL REMOVED>
> Subject: [WebAIM] Tab controls and WCAG 1.4.10 Reflow
>
> Hello
>
> I have a situation where a Tab component design had multiple tabs
> horizontally. If the screen is resized, or zoomed, some of the tabs are
> hidden from view in the sized container div. In some cases the tab name can
> be truncated with half the tab in view.
>
> The tabs can be scrolled in the container which opens other problems,
> however for WCAG 2.2 I think this will be a Visible Controls fail. but, is
> this a Reflow fail? I believe it may be because a Tab component does nor
> require a two-dimensional layout to be meaningful and thus the Tabs can be
> stacked in view.
>
> I would like to hear the opinion of other A11y people on potential
> accessibility issues.
>
>
> All the best
> Laurence
> Digital Accessibility Senior Specialist Telstra
> > > http://webaim.org/discussion/archives
> > > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.