E-mail List Archives

Search E-mail List Archives for

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

From: Laurence Lewis
Date: Wed, Mar 30 2022 11:52PM
Subject: Tab controls and WCAG 1.4.10 Reflow
No previous message | Next message →

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

From: Steve Green
Date: Thu, Mar 31 2022 12:00AM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

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

From: Niranjan Vala
Date: Thu, Mar 31 2022 1:36AM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

I also think that horizontal tabs should be made responsive for all screen
sizes so it meets with the Reflow WCAG success criterion. For smaller
screen sizes, it should be vertically stacked and for bigger screens, It
can be aligned horizontally. In fact that is what I have seen on many
popular websites that uses tabs. There could be another approach in which
tabs with only icons with proper hidden but accessible labels can be used
so they can be aligned horizontally even on smaller screen sizes.

On Thu, 31 Mar 2022 at 11:31, Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

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

From: Steve Green
Date: Thu, Mar 31 2022 1:49AM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

Development is the easy part - there are several ways this could be implemented such as to be fully WCAG conformant. The difficulty we have as testers is persuading the developers and other stakeholders that it is non-conformant and needs to be changed.

Unsurprisingly, they don't want to spend time and money changing anything, so they challenge us to show that it really is non-conformant. And that's perfectly reasonable - we should be able to justify our opinions. However, ambiguous specifications like WCAG mean it's possible for opposing views to appear equally plausible.

Steve

From: Geethavani.Shamanna
Date: Thu, Mar 31 2022 5:33AM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Thu, Mar 31 2022 5:44AM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

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

From: Geethavani.Shamanna
Date: Thu, Mar 31 2022 6:32AM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

Thank you Birkir, this is really useful. I have so much to learn...

Geetha

From: Abi James
Date: Thu, Mar 31 2022 3:29PM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

One of the downsides of making the tab panel focusable is that when focusable elements in that tab have focus then the focus indicator on the panel is also shown (at least of chrome). This can be confusing and distracting for users, particularly it can appear like the panel focus indicator is coming on briefly when buttons are pressed.

The approach we reached was to only make the tab panel focusable when it didn't contain focusable elements. If the tab contains a form (or other interactive element) then, as the tab panel is labelled by its heading, the region was announced when a screen reader users tabbed directly to to the interactive element in the tab panel. We also consider surpassing the focus indicator on the tab panel which would have been simpler to maintain but felt like too much of a compromise. There was no perfect approach.

Abi James

On 31 Mar 2022, at 13:33, Geethavani.Shamanna < = EMAIL ADDRESS REMOVED = > wrote:

CAUTION: This e-mail originated outside the University of Southampton.

Thank you Birkir, this is really useful. I have so much to learn...

Geetha

From: Laurence Lewis
Date: Thu, Mar 31 2022 4:09PM
Subject: Re: Tab controls and WCAG 1.4.10 Reflow
← Previous message | Next message →

“The difficulty we have as testers is persuading the developers and other
stakeholders that it is non-conformant and needs to be changed.”


I am in complete agreement.


I support making the Tabpanel focusable, I think the benefits far outweigh
any negative impact on users.


I will stick with my initial view that the tabs being truncated or
invisible us not compliant with 1.4.10 Reflow.


I think it also a fail for WCAG 2.2 - 3.2.7 Visible Controls, when
released, but I need to study the SC to fully understand the requirements.

From: Kevin Prince
Date: Mon, Apr 11 2022 5:39PM
Subject: Tab controls and WCAG 1.4.10 Reflow
← Previous message | No next message

We had exactly this - it only made sense without a focusable tab panel if the first element in the tab was focusable - and had a mix of none and last item in a tab. That meant a bunch of text was not being presented that was needed for context even if there were a tabindexed element.

Kevin prince
Kevin Prince
Product Accessibility & Usability Consultant