Make admin menu skip links accessible to developers

[littler.chicken]

Currently, the WP admin skip links are hard coded in menu-header.php and cannot be modified or added on to. Use case here might be a plugin with a tabbed settings page; it might be nice to have the "Skip to main content" bypass the tabs, since right now keyboard users still have to tab through that entire menu, but allow the developer to add a "Skip to plugin settings menu" or something similar on their settings page, so that both the settings form and the tabs are available, but separate.

Modifying the output here to use a function with an array and filter can be done easily, without changing the current output, and future skip links can be simply added to the array.

A related change should be adding the existing section ID (set in add_settings_section, so anyone using the Settings API will have already done this) to the section title output in do_settings_section, to set up the appropriate anchor. Developers who want to add a skip link to a section on their settings page then just need to add the section ID and text to the skip links array, using the filter.

[SergeyBiryukov]

Hi @littler.chicken, thanks for the ticket and patch! Seems like a good enhancement.

The only thing missing is the documentation for the new filter, see ​Hooks (Actions and Filters) section in the documentation standards.

[littler.chicken]

updated patch with docs

[littler.chicken]

Thank you so much, and appreciate the link! Patch has been updated, I think, or new patch submitted.

[afercia]

Interesting idea and worth considering. Not sure adding the ID on the heading in do_settings_sections would help with "tabs" in plugin settings pages since these tabs are usually printed out by other means.
By the way, the main issue I see here is that many browsers still don't give focus to elements targeted with an anchor link if these elements are not focusable. That's the reason why the main content div has a tabindex="0" attribute.
On the other hand, I'm not sure making some elements focusable, for example a heading, would be a good thing. I'd recommend to discuss a bit this in the next accessibility team meeting.

Couple things about the patch so far:

• the admin toolbar ID is wp-toolbar not wpbody-toolbar
• the settings section h2 heading text shouldn't use esc_attr()

[littler.chicken]

Thanks for looking it over, Andrea; I appreciate it.

Interesting idea and worth considering. Not sure adding the ID on the heading in do_settings_sections would help with "tabs" in plugin settings pages since these tabs are usually printed out by other means.

My thought with adding the ID is that because it's something developers are already implementing (if they're using the Settings API), it's an easy add. Not everyone will want to modify the skip links, but this is an easy anchor if they do. My example with the tabbed settings page is that the main anchor lands users above the tabs. With a tabbed settings page, the filter gives developers a way to allow users to either land above the tabs, or to bypass them and go directly to the settings form instead of having to go through each tab. At the moment, though, there aren't anchors available in the form, so a developer would have to add a hidden anchor after their tabs, to get a target for the skip link. With a section header starting the top of the form, that seems like an easy place to land that.

By the way, the main issue I see here is that many browsers still don't give focus to elements targeted with an anchor link if these elements are not focusable. That's the reason why the main content div has a tabindex="0" attribute.
On the other hand, I'm not sure making some elements focusable, for example a heading, would be a good thing. I'd recommend to discuss a bit this in the next accessibility team meeting.

Thanks, discussion sounds fine.

Couple things about the patch so far:

• the admin toolbar ID is wp-toolbar not wpbody-toolbar
• the settings section h2 heading text shouldn't use esc_attr()

Thanks for catching both of those! Sorry about that.

I had also raised the question of whether the skip links should be set up as a <ul>, but I think that might be difficult to make consistent with the front end, in situations where the WP toolbar skip link is combining with whatever the theme outputs--they are just <a>, no list setup there. So I would expect we don't want to try that in the admin.

[chriscct7]

@afercia Can you can review this ticket and see if it will make this release or should be punted on the Friday scrub for the 4.6 release?

[afercia]

@chriscct7 we've discussed this in a recent accessibility weekly meeting and haven't reached a consensus. I'd say feel free to punt.

[chriscct7]

Punting per #10

[GrahamArmfield]

Replying to afercia:

By the way, the main issue I see here is that many browsers still don't give focus to elements targeted with an anchor link if these elements are not focusable. That's the reason why the main content div has a tabindex="0" attribute.

If I've understood the situation correctly then tabindex="-1" would be better. This allows focus to be given to an element (including in Chrome and Safari) but prevents it from being included in the normal tab order. As far as I know this is supported by all modern browsers.

[afercia]

Discussed during today's accessibility meeting and agreed to close this ticket. There's no consensus, no activity and some concerns about potential abuse from plugins has been expressed (see the linked Slack conversations above).
Discussion can continue on closed tickets, and tickets can always be reopened with new argumentations.