[BITV] 9.4.1.2/3.10 - The "Details" section contains a tab list that has not been implemented correctly. (2)

[AndyScherzinger]

• fix(a11y): Remove nav and radios in sidebar tabs nextcloud-libraries/nextcloud-vue#4456
• Bump @nextcloud/vue to v8 beta 5 + add some visible labels #40084
• Clarify whether navigation quirks fix(a11y): Remove nav and radios in sidebar tabs nextcloud-libraries/nextcloud-vue#4456 (review) are acceptable with @michaelnissenbaum
• enh(NcAppSidebarTabs): Make tab navigation accessible nextcloud-libraries/nextcloud-vue#4663
• v8.0.0-beta.9 nextcloud-libraries/nextcloud-vue#4680
• chore: Bump @nextcloud/vue to v8-beta.9 #41070

It is recommended to set the role="tablist" on the ul element and remove the nav element.

<nav data-v-76ae79ca="" role="tablist" class="app-sidebar-tabs__nav">

Details

https://report.bitvtest.de/default-en/d63601ac-cb34-4645-8256-66bec78964a0.html#checkpoint-bfbf07e5c3-v3-n10

• 9.4.1.2/10.10 - https://report.bitvtest.de/default-en/d63601ac-cb34-4645-8256-66bec78964a0.html#checkpoint-bfbf07e5c3-v10-n10

[Pytal]

The current implementation

uses a nav wrapper with role="tablist" around span elements with role="tab"

Will changing nav → ul and span → li while keeping the roles meet a11y requirements @michaelnissenbaum?

[michaelnissenbaum]

I don't see an advantage in using an unordered list here. A proper implementation should look like the example at https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-automatic/. I've examined the current implementation at https://try.nextcloud.com/ltd/a11y/index.php/apps/files/?dir=/&fileid=677 using VoiceOver, and it seems to work correctly. However, I don't understand why there's a radio button inside the element with role="tab". In theory, this could lead to issues. As I mentioned before, you can find a correctly functioning example at the URL above.

[Pytal]

Understood 👍

Would making the input type="button" be sufficient or is a button element necessary to meet a11y requirements @michaelnissenbaum?

[michaelnissenbaum]

From my perspective, it's irrelevant in this case, as shown in the example the native role is overridden by the role="tab".

<button id="tab-1"
            type="button"
            role="tab"
            aria-selected="true"
            aria-controls="tabpanel-1">
      <span class="focus">
        Maria Ahlefeldt
      </span>
    </button>

[Pytal]

Is the tablist implementation on https://try.nextcloud.com/ltd/a11y/ accessible @michaelnissenbaum ?

[michaelnissenbaum]

From my perspective, the implementation of the tab bar is still not 100% accessible. The use of button elements (type="button") nested within "span" elements with the role "tab" results in being able to access the individual tabs one by one using the TAB key. Depending on the screen reader, they may not be identified as tabs but rather as buttons. Additionally, navigation through the tabs should only be possible using arrow keys. Even when using Chromium-based browsers, both the "tab" and "group" roles are announced in the reading mode. Here's another example for reference: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tab_Role.