Andy, I'm not too keen on this. Pretty much everywhere I've seen "skip to content" implemented, it doesn't appear over the top of existing content. I've seen some places do it by having strategically positioned whitespace, others by dynamically scrolling the whole page down or sideways to make space for new accessible menu items like this. Here's an example of the functionality on the Access to Work site from .gov.uk - i.e. aimed at disabled users. (tabs are highlighting in yellow)

I don't think the behaviour here is quite right yet.

When I tested this, while the "skip to content" link did move the page (✅ ) if I then tab again, I'm back at the top at the next item after skip to content. So basically having had the skip, I can't continue from that point ( ❌ ). After skipping the next tab item should be the next one after the start of hte main content, not taking me back to the top of the page.

I've tested this on Chrome with a press site and journal site - finding the same behaviour on both.

Which theme did you test this with?

Which theme did you test this with?

OLH.

I've just tried Clean and Material - and those are both fine. So I think just an OLH issue?

Which theme did you test this with?

OLH.

I've just tried Clean and Material - and those are both fine. So I think just an OLH issue?

Yeah I just tested it there too. I think its intercepting the click so the anchor link isn't set and the focus doesn't move.

I'll leave it with you then - I think that's the only problem remaining - from what I can see the rest of the requirements are there:

✅ link is the first focusable control on the Web page.
✅ description of the link communicates that it links to the main content.
✅ (the link is either always visible - No) or visible when it has keyboard focus (Yes).
✅ activating the link moves the focus to the main content.
( ❌ OLH, ✅ Clean & Material) after activating the link, the keyboard focus has moved to the main content.

from WCAG G1

@StephDriver I've updated OLH's JS to stop it intercepting the anchor hash being added to the URL bar. All looks okay now. To test this locally you will need to run the build_assets command.

I have been testing it with random pages, and this time that ended up being a homepage, where it skipped to a search bar rather than the start of the main content. But it works fine on an article page, and on the list of articles too. I wonder whether at this point it would be best to implement this solution, since it seems fine for 99% of the site, and then raise a new issue for reviewing its functionality on the landing page?

I am suggesting that because I think the problem is actually with the landing page structure not this issue. The landing page's main content starts with a search bar, before having a heading. Rather than change this new functionality to look for the heading which isn't where it should be on that page, I'd rather improve the structure of the landing page.