Add action hook after theme skip links

[alexstine]

Not sure if this is the right place. My feature request is to add a default hook in themes that is after skip links. I was recently working on a code project where I had a widget loaded in wp_footer but had no idea how to dynamically add a trigger link in the header for screen readers. If I used jQuery to add it before the first link, it could come before skip links and this is bad UX. If I added it after the first link, there could be multiple skip links creating a mess or maybe the theme doesn't have skip links, it could insert after a logo. There are also themes with top navigation, etc. that makes this rather difficult to figure out how to dynamically insert a trigger link.

If theme guidelines were updated to require a hook after skip links, I could simply add my trigger link like this.

<?php
add_action( 'theme_after_skip_links', function() {
echo '<a href="#" class="my-trigger screen-reader-text">Trigger Link</a>';
}); ?>

In the header.php file, it might look something like this.

<?php
// header.php code
echo '<a href="#main" class="screen-reader-text skip-link">Skip to main content</a>';
do_action( 'theme_after_skip_links' );
?>

Hopefully others will agree that there are situations this could be really useful to plugin and even child theme developers.

Thanks.

[joyously]

Have you seen ​https://developer.wordpress.org/?s=wp_body_open ?

[alexstine]

Yes, my idea is similar to that.

The problem with using that hook is it would still insert before skip links, not after. If there are skip links, you do not and should not insert anything before them as skip links should always be first on the page.

Maybe I am misunderstanding? Seems like two different use cases.

[afercia]

Previously in #36644 a filter was proposed for the admin skip links. The ticket was closed for concerns about potential abuse.

An action hook for the front end skip links sounds more sensible and safer to me, especially if WordPress could also provide a standardized way to print out the main "skip to content" link.

[poena]

I would very much like to see a standardized way to print out a skip to content link.

[joedolson]

Agreed; I think standardizing this would be great, and would make something like this proposal possible. Right now, since there's no standardized way to add a skip link, there's really no way we can solve this problem. It'll need to be a multi-step process:

1) Add a method to standardize the addition of skip links & add hook.
2) Make that method the required way to themes to implement skip links.

Technically, this ticket will be resolved from a technological perspective following stage 1; but from a practical standpoint, I think it will take some time before it's usable in the wild, since it will depend on theme implementation.

[joyously]

I just want to bring up the case where there is nothing to skip, as far as the theme knows. But plugins could add something at any of the early action hooks and the theme wouldn't know that.
For instance, my theme has an option to not output the header on any page. So in that case, no skip link is output because there is nothing to skip. But a plugin could be used to do Mega Menu or something to replace the header and so a skip link would be needed, but the theme isn't involved at that point.
So if it was standardized to output skip links at wp_body_open, you would still need coordination to know whether to output it and what target to skip to.

[joedolson]

It would be a standardized method to add them; it would still be in the control of the theme author, but - as you say - it would then be possible to easily check whether or not there was a skip link outputted, and add one back in if it was needed, contextually.

I don't think we're recommending a mandatory, automated skip link; it's only necessary if there's something to skip. But having it be standardized would make it much easier to handle.

[hellofromTonya]

5.6 Beta 1 is less than 2 weeks away. @sarahricker is this one on your radar to land in 5.6? If yes, what's the next step for it to move forward and into 5.6?

[audrasjb]

As per today accessibility scrub, this feature request should ideally be committed early in the release cycle, so let’s move this ticket to Future release to see if it can land in the next release :)