Twenty Sixteen: Skip To Content Link Not Working on iPhone

[alexstine]

When using an IPhone5C with Voiceover, the Skip To Content link is not working. Once the link is clicked, it goes to "contentinfo"/"<footer>" instead of "content" as "#content" directs it to do. Seems to work fine visually, but with Voiceover it focuses on the first item of the footer navigation menu.

GitHub Issue: ​https://github.com/WordPress/twentysixteen/issues/488

Any possibility of getting this one fixed?

Thanks.

[afercia]

Sounds like an iPhone bug but since the code is presumably the same used in the upcoming Twenty Seventeen I'd say it's definitely something to check for 4.7. Then the Twenty Seventeen can make a decision and even close the ticket if they confirm it's a device bug and there's not so much that can be done.

[alexstine]

This seems to only be a problem in Twenty Sixteen, other skip to content links on other sites work fine on the IPhone.

Thanks.

[davidakennedy]

Hi @alexstine! Welcome! Thanks for the report.

I've tested the skip links on both the official demos for Twenty Sixteen and Twenty Seventeen. Those are:

​https://twentysixteendemo.wordpress.com/
​http://2017.wordpress.net/

Tested with Safari on an iPhone 5. I can't reproduce the bug you report. Is there anything special or different about the steps you're taking to reproduce the bug?

[alexstine]

Hello,

I tested on your links using Voiceover and it still does not work. It totally skips the content and seems to focus on the navigation menu launcher.

Thanks.

[davidakennedy]

@alexstine Thanks for testing again. Much appreciated!

I've tried again multiple times on each demo, and can't reproduce. I also asked @laurelfulford to test this, and she couldn't reproduce it either.

What version of iOS are you running? What browser? Anything different about that browser or your setup? Maybe something else is causing this?

[alexstine]

Using the latest version of IOS. No special browser, just default Safari browser. It works fine visually, but Voiceover gets targeted anywhere but the main content, 90% of the time it ends up in the footer menu.

Thanks.

[davidakennedy]

Since myself and @laurelfulford weren't able to reproduce this in either Twenty Sixteen or Twenty Seventeen in multiple attempts, I'm going to close it. But it can be reopened in the future if steps to accurately reproduce the issue more often are determined.

[alexstine]

Hello,

I just switched my live site over to the Twenty Seventeen theme and am still seeing this problem.
​https://goo.gl/49UjaL

Steps to replicate.

1. Start with any iPhone. I'm now using the iPhone 7.
2. Go to Settings --> General --> Accessibility --> Voiceover and enable it.
3. Open Safari.
4. Visit my domain or another site using the Twenty Seventeen theme.
5. When you find the Skip to content link, double tap to activate it. You will see Voiceover focus does not change to the main content. You simply stay right on the link.

This however works just fine with using a screen reader such as NV Access (NVDA) on Windows. It must be the way the code is with some of the default WP themes. For other websites, skip links work fine. I'm just not for sure why it does not work on WP themes. One thing is for sure, it is not an Apple bug in IOS if it works on other sites.

Thanks.

[afercia]

This should be tested again on a real iOS device. That said I think there's an issue on the site reported as example.

@alexstine hello there. As far as I see, the KSB site is using a child theme. The child theme is probably changing something in the header template because the skip link doesn't even get visually revealed when focused.

Sorry for the code examples, hope you can get it: on the KSB site I see the markup is:
<a class="screen-reader-text" href="#content">Skip to Content</a>

while it should be:
<a class="skip-link screen-reader-text" href="#content">Skip to content</a>

Basically, it misses an additional skip-link CSS class. Not sure that has anything to do with the issue you reported though, unfortunately I can't test on an iPhone.

[GrahamArmfield]

Hi all, I have tested the KSB Yearbook site mentioned above on an iPhone 5 running iOS10.3.3 and with Voiceover activated.

I get the same problem as outlined above. I hear the "skip to content" link, and double-tap to follow the link. Initially, the main content seems to get the Voiceover focus ring, but nothing is announced. When I swipe right to move to the next item, I find I am on the first link in the footer.

I note comment from @afercia about the skip link not becoming visible when it gets focus - and this is an issue for sighted keyboard users.

With this in mind I tried another page: ​https://openinclusion.com/visitor-information/

I helped put this site together and I know it has skip links that do become visible when they get focus. Additionally this long page also contains a table of contents at the top - a series of in-page links, each of which jumps down to a heading.

Interestingly, the skip link at the top shows exactly the same behaviour as the skip link on the KSB Yearbook site - ie initially the content area gets Voiceover focus, but swiping to the right takes you down into the footer area.

However, the in-page links work perfectly - focus is on the heading and Voiceover reads out the heading (and level).

Additionally on that site at mobile widths, there is a 'Top' link that floats near the bottom of the viewport. It points to #top - a <div> that contains the banner and navigation. Manually focusing on that with Voiceover and double tapping takes you back up near the top but Voiceover actually starts to read the first paragraph of the main content - ie after the navigation and top level heading. That's not right...

So far then, in-page links that point to headings work fine, but in-page links that point to <div>s do not give the desired behaviour.

It's also not about the lack of a tabindex="-1" on the target element, because the skip link points to the <main> element which does have a tabindex="-1". The headings do not have this and they work fine.

To me this seems like a 'feature' of iOS.

There's also this article: ​https://axesslab.com/skip-links/

[afercia]

To recap the information provided by the article @GrahamArmfield linked to:

there are bugs reported against both WebKit for iOS and Android:

• iOS bug report (on the WebKit bug tracker): ​https://bugs.webkit.org/show_bug.cgi?id=179011
• Android bug report (fixed then reverted): ​https://bugs.chromium.org/p/chromium/issues/detail?id=657157

The fact on some sites the skip link works might be related to the usage of the tabindex="-1" fix, as suggested in the axesslab.com article. However, seems things are a bit more complicated:

• Twenty Sixteen uses a few lines of JavaScript to add tabindex="-1" to the skip link target
• Twenty Seventeen and Nineteen use the same JavaScript but only for Internet Explorer, as the original WebKit bug was solved, at least on desktop

The fact this bug seems to happen on both Twenty Sixteen and Twenty Seventeen suggests it happens regardless of the tabindex="-1" fix. Worth also noting that using tabindex="-1" on a non-interactive element like a div has undesirable consequences for Internet Explorer and JAWS, see [44639].

Moving to Future Release, as seems this issue needs some research and investigation.

[afercia]

On a side note, despite the bug reported against Android, I've just tested on Android with Chrome 71 and TalkBack 7.2 and the skip link worked well for me on Twenty Sixteen, Seventeen, and Nineteen.

[ianbelanger]

Would love to get this issue re-tested on an iPhone. I would do it myself but I do not have an iPhone. Could someone please test this again so we can get this ticket resolved? Thanks.

[joedolson]

Putting this in the 6.3 milestone to check on. If it's still an issue, we need to resolve it; if not, let's get it closed!

[joedolson]

Did some testing with Twenty Sixteen and Twenty Seventeen on an iPad, and definitely had some strange results - though not the same as above.

Using VoiceOver, I could activate the Skip to Content link, and it would briefly send me to the top of the #content; then bounced me back to the site title. I was able to visually see the content gain the focus outline briefly, then bounced to the title. If I moved very quickly, I could move forward without being bounced back by swiping.

I was able to remove this behavior by dequeuing the skip link focus fix JS file, so I suspect this is an issue with the focus fix JS.

Removal of the skip link focus fix is addressed in #57031, and has previously been discussed in #54421. I was opposed to it for the reasons in #54421, but if it's creating accessibility problems, that changes the calculus considerably.

[joedolson]

Note: Twenty Sixteen's skip link focus fix is still running on webkit and opera; that should change to match later themes, where it only registers for IE.

• Removes scripts from the wp_print_footer_scripts action in Twenty Nineteen, Twenty Twenty and Twenty Twenty-One.
• Switches enqueue functions to register to deactivate the scripts in Twenty Fifteen, Twenty Sixteen and Twenty Seventeen.
• Rearranges Twenty Seventeen's scripts to connect twentyseventeenScreenReaderText with the global script instead of the unused skip link fix.
• Updates scripts in Twenty Fifteen and Twenty Sixteen with code from Twenty Seventeen _to run on Internet Explorer only_ (avoiding a problem with WebKit on iPhone). Twenty Sixteen needed to keep an adjustment that offsets the toolbar and border.
• Removes the script from JS files in Twenty Thirteen and Twenty Fourteen and edits their modified dates.

Trac 54421

@sabernhardt

The modified dates are set to 20230627 (for now) in the four oldest themes, which should change if the PR is committed before the day of Beta 1.

Do you mean whenever it's committed prior to Beta 1, the date of the commit should be used?

Yes, using the date of the commit would be good. Probably most of the external resources use that as the version, though it is not consistent throughout the themes (some styles and scripts use the planned release date).

[westonruter]

@joedolson could you review ​the PR as fixing this?

[joedolson]

I was unable to confirm that this PR fixes this issue. In *this* round of tests, I can verify that the skip link focus fix was gone, but this did not have any impact on the focus issues with iOS.

Further research shows that this can be fixed by adding tabindex="-1" to the target container on iOS devices.

I'm not sure what's causing it, however. I created a very simple codepen to experiment: ​https://codepen.io/joedolson/pen/dygddPV, with just a skip link, a simple nav, and a target container, and it does not require tabindex to get focus.

I also did a test of Twenty Sixteen with wp_head() & wp_footer() removed entirely, to test interference from CSS or JS - and in *that* test focus would briefly land in the main content, then shift focus back to a random item in the middle of the navigation menu.

Diagnosis: I don't think this is our bug.

I noticed in fd6d5db that I put the wrong date, but I fixed that in what I committed to trunk: ​https://github.com/WordPress/wordpress-develop/commit/404fd63386493dd96dd0af8a494ee30fb76362de

Changeset: https://core.trac.wordpress.org/changeset/55861

[audrasjb]

As per today's bug scrub, let's move this to the next milestone as we are at the end of WP 6.3 beta cycle.

[joedolson]

Following discussion at WordCamp US 2023's contributor day and bug scrub on 2023-09-15, we've concluded that this bug must be some kind of incredibly obscure browser/screen reader bug, and is too entangled to justify the time we've already spent to try and solve it. Anybody who wants to tackle this is free to reopen, but for now we're closing it as a wontfix.