Avoid using visual tabs when it's irrelevant: menu screen, about.php and in edit-site screen (multisite)

[audrasjb]

Related: #40678

In several part of WordPress admin, visual tabs are used for simple links.
The issue appears in:

• Menu screen
• About.php screen
• Edit site screen (in multisites)

The issue with "fake tabs" is multiple:

• A real tab system is supposed toggle the visibility of content that is already in the page.
• The markup is not relevant (see example bellow)

Example of fake tabs used in Menu screen:

<h2 class="nav-tab-wrapper wp-clearfix">
	<a href="/wp-admin/nav-menus.php" class="nav-tab nav-tab-active">Edit Menus</a>
	<a href="/wp-admin/nav-menus.php?action=locations" class="nav-tab">Manage Locations</a>
</h2>

This ticket is a part of a bigger one: #40678. During the last accessibility team meeting, we suggested to separate the different tasks of 40678 in separate tickets to make it easier to commit.

Please note this ticket concerns also the design of these "tabs".
We'll need some design feedback because if they’re not tabs, they probably should not look like tabs.

[audrasjb]

First idea: keep the current design but use a valid markup (this example is only applied to menu screen)

[afercia]

Moving to future release, pending design feedback.

[audrasjb]

Visual tabs in about.php screen

[audrasjb]

Visual tabs in nav-menus.php screen

[johnjamesjacoby]

While this bit of WordPress admin UI is not exposed via a functional API, dozens of plugins (and themes) have copied the approach and styling, including BuddyPress, bbPress, WooCommerce, Easy Digital Downloads, WP User Profiles, and others.

---

Because tabs do not exist as HTML elements (tab was an HTML3 element tho!) my recommended improvement here is to use a nav instead of an h2, and update the related CSS specifiers to support both old and new elements.

[audrasjb]

Replying to johnjamesjacoby:

Because tabs do not exist as HTML elements (tab was an HTML3 element tho!) my recommended improvement here is to use a nav instead of an h2, and update the related CSS specifiers to support both old and new elements.

100% Ok. Let's create a patch for that. Self-assigning the ticket.

[audrasjb]

Multisite navigation: no visual change

[audrasjb]

Menus navigation: no visual change

[audrasjb]

Credits navigation: no visual change

[audrasjb]

Replace H2 with NAV elements. No CSS change needed.

[audrasjb]

Hi,

The good news is that we don't have any CSS change to make :)

I attached 3 screenshots to show there is no visual change.

In my opinion, 43398.2.diff is good to go.

[afercia]

Noticed a couple things:

1
The Credits, Freedoms, and Privacy pages need to be changed as well.

2
When there are multiple <nav> elements in a page (and there are already the toolbar and the admin menu), the navigation landmark need to be disambiguated otherwise assistive technologies users won't have a clue what a specific navigation is about (see attached screenshot below). All the new <nav> elements need an aria-label attribute with a meaningful name. Please avoid the word "navigation" as that's already automatically announced by screen readers as the element's role.

[afercia]

While this bit of WordPress admin UI is not exposed via a functional API, dozens of plugins (and themes) have copied the approach and styling

Yep and, unfortunately, they're used for both real tabs that toggle the visibility of in-page content and for links that trigger navigation to a new page. Those are two completely different interactions and they shouldn't look the same. It would be great to start considering some new design (in a separate ticket).

[afercia]

I'm going to refresh the patch.

[afercia]

43398.3.diff​

• addresses also the Credits, Freedoms, and Privacy pages
• adjusts the headings level in the Credits page accordingly
• adds an aria-label to the navs

Worth reminding <nav> elements are also landmarks. References:

ARIA 1.1 Landmark Roles
​https://www.w3.org/TR/wai-aria-1.1/#landmark_roles

HTML5 sectioning elements that define ARIA Landmarks: W3C example
​https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html

Accessible Landmarks
​https://www.scottohara.me/blog/2018/03/03/landmarks.html

Short note on JAWS support
​https://developer.paciellogroup.com/blog/2018/07/shortish-note-on-jaws-support-for-regions/

[afercia]

Adding the keyword needs-dev-note to encourage developers to use a nav element for similar navigation menus. Instead, real ARIA tabs that toggle the visibility of in-page content, should be implemented as an ​ARIA Tabbed Interface.

[afercia]

In 44905:

Accessibility: Improve the semantics of "tabs" that are not real ARIA tabs.

Some "visual tabs" in the WordPress admin used links wrapped in a h2 heading. While these tabs look like ARIA tabs, they're just navigation menus and should be marked-up as such to be correctly exposed to assistive technologies.

• changes the wrapping <h2> to a <nav> element: worth reminding <nav> elements also define ARIA landmarks
• adds an aria-label to the <nav> elements so they can be distinguished from other <nav> elements in the page
• adjusts the headings level in the Credits page

Props audrasjb, afercia.
Fixes #43398.

[SergeyBiryukov]

#40678 was marked as a duplicate.