E-mail List Archives

Search E-mail List Archives for

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

From: Erick Wilder
Date: Tue, Aug 01 2023 1:35AM
Subject: Custom tabs with a single tab panel: does it pose accessibility issues?
No previous message | Next message →

Hello everyone,

I’ve come across many implementations of a custom tab and tab panels. Most
of them uses a combination of multiple elements in the DOM, each tab
assigning a aria-controls attribute to a different ID of an element with
role=tabpanel

With frameworks and libraries like React it is often the case that elements
are not simply removed from the accessibility tree (e.g using display:
none, or aria-hidden attribute) but elements are removed from the DOM

I have come across this implementation of a tab and tab panel that uses a
single tab panel, and conditionally removes and assigns the aria-controls
attribute to the currently selected tab (e.g. aria-selected=true).

I wonder if this may pose accessibility issues because the contents of the
element with role=tabpanel and the aria-controls attribut of the tabs
change programmatically. Is my concern valid? Is it better to stick to
multiple tab panels, each with its unique id and use CSS to remove the
inactive ones from the accessibility tree?

Thanks and have a great week.
--
Enviado do Gmail para celular

From: Steve Green
Date: Tue, Aug 01 2023 4:05AM
Subject: Re: Custom tabs with a single tab panel: does it poseaccessibility issues?
← Previous message | Next message →

I have seen this coding method too, and it's horrible, stupid and unnecessary. I have no idea why they do stuff like this, other than to show off.

That said, it is probably WCAG conformant. It might fail SC 4.1.1 because there are tabs that don't have a corresponding tabpanel, but of course 4.1.1 will disappear from WCAG 2.2.

Adding and removing content from the DOM like this can cause corruption of a screen reader's virtual object model, and I have seen that many times. It usually manifests itself as a loss of focus position. However, although this is obviously an accessibility issue it's not a WCAG non-conformance. The behaviour may not even be consistent between machines or screen reader versions.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Erick Wilder
Sent: Tuesday, August 1, 2023 8:36 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Custom tabs with a single tab panel: does it pose accessibility issues?

Hello everyone,

I’ve come across many implementations of a custom tab and tab panels. Most of them uses a combination of multiple elements in the DOM, each tab assigning a aria-controls attribute to a different ID of an element with role=tabpanel

With frameworks and libraries like React it is often the case that elements are not simply removed from the accessibility tree (e.g using display:
none, or aria-hidden attribute) but elements are removed from the DOM

I have come across this implementation of a tab and tab panel that uses a single tab panel, and conditionally removes and assigns the aria-controls attribute to the currently selected tab (e.g. aria-selected=true).

I wonder if this may pose accessibility issues because the contents of the element with role=tabpanel and the aria-controls attribut of the tabs change programmatically. Is my concern valid? Is it better to stick to multiple tab panels, each with its unique id and use CSS to remove the inactive ones from the accessibility tree?

Thanks and have a great week.
--
Enviado do Gmail para celular

From: tim.harshbarger@deque.com
Date: Tue, Aug 01 2023 9:37AM
Subject: Re: Custom tabs with a single tab panel: does it poseaccessibility issues?
← Previous message | Next message →

It should be OK to do that.

There may be a difference in the implementation.

In a situation where all the tab panels exist in the DOM, you can set the aria-controls attribute to point to the relevant tab panel for each tab.

In a situation where the tab panels only exist in the DOM when a tab is selected, you will want to add an aria-controls attribute only to the currently selected tab.

Thanks,
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Erick Wilder
Sent: Tuesday, August 1, 2023 2:36 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Custom tabs with a single tab panel: does it pose accessibility issues?

Hello everyone,

I’ve come across many implementations of a custom tab and tab panels. Most of them uses a combination of multiple elements in the DOM, each tab assigning a aria-controls attribute to a different ID of an element with role=tabpanel

With frameworks and libraries like React it is often the case that elements are not simply removed from the accessibility tree (e.g using display:
none, or aria-hidden attribute) but elements are removed from the DOM

I have come across this implementation of a tab and tab panel that uses a single tab panel, and conditionally removes and assigns the aria-controls attribute to the currently selected tab (e.g. aria-selected=true).

I wonder if this may pose accessibility issues because the contents of the element with role=tabpanel and the aria-controls attribut of the tabs change programmatically. Is my concern valid? Is it better to stick to multiple tab panels, each with its unique id and use CSS to remove the inactive ones from the accessibility tree?

Thanks and have a great week.
--
Enviado do Gmail para celular

From: glen walker
Date: Tue, Aug 01 2023 5:15PM
Subject: Re: Custom tabs with a single tab panel: does it pose accessibility issues?
← Previous message | No next message

The tablist, tab, and tabpanel roles don't say you can't do that, but
whether it's a good idea will take a bit of testing on various platforms
(mac, pc, mobile), with various browsers (edge, safari, firefox, chrome),
and various screen readers (nvda, jaws, voiceover, talkback, narrator).

From a software engineering perspective, I can understand the theory behind
doing that. In general, reusing an object is more efficient (memory-wise)
than having a bunch of objects where the unused ones are hidden. The hidden
ones still take up memory.

However, changing aria-controls might have unexpected results.
Aria-controls is a property (https://www.w3.org/TR/wai-aria/#dfn-property)
and not a state (https://www.w3.org/TR/wai-aria/#dfn-state) so is not
expected to change, but there's nothing in the spec that says it can't
change. See also https://www.w3.org/TR/wai-aria/#statevsprop

Fortunately (for your case), aria-controls doesn't do a whole lot. I think
JAWS might announce a special key sequence to get to the controlled object
but there's no shortcut key to get back to the controller. I think other
screen readers ignore it so setting and changing aria-controls might not do
anything.

This article is 7 years old but still might be appropriate -
https://heydonworks.com/article/aria-controls-is-poop/