Twenty Seventeen: Keyboard navigation on Safari 10

[afercia]

Not sure if it's just me but keyboard navigation on Safari 10 has some weird behaviour:

can't open a main navigation menu drop down (works on Chrome)
can't complete navigation of a page (any page): at some point while tabbing the tab order starts again from the root and it's impossible for me to even reach the sidebar.

Seems there are multiple points here this happen. A first one is the menu drop-down, when a navigation menu has sub-items. A second one, after tabbing on a post published date and author name (before the post title).

Note: This was confirmed and discussed more here: ​https://github.com/WordPress/twentyseventeen/issues/486

[davidakennedy]

Confirmed by @afercia on that GitHub issue

​https://github.com/WordPress/twentyseventeen/issues/486#issuecomment-254847408

It seems to be a bug with Safari itself. Not sure what can be done about a possible workaround, but it should be explored.

[rianrietveld]

At WordCamp Milan tested this on
Safari Version 10.0 (11602.1.50.0.10) OS X El Capitan Version 10.11.6 it works fine.
in Safari 8 with Yosemite the SVG's don't show, which makes sense and the tab order works ok (thanks Siobhan McKeown)
in Safari 9 with El Capitan the site itself does not get focus at all (thanks Angelo Ghigi)

it's a know bug, see ​https://github.com/facebook/react/issues/7852

[swissspidy]

Submitted a bug with ​Apple Bug Reporter. Issue no. 28889219.

[davidakennedy]

Thanks @swissspidy!

So, @afercia and @rianrietveld, just to double check here – seems like there isn't much that can be done, and we can close, hoping that Apple fixes this soon?

[afercia]

@davidakennedy I'm afraid the real question is if WordPress can ship a feature that breaks keyboard navigation (and thus makes the theme impossible to use for screen readers too) in one of the major browsers. Thinking this should be discussed in the next weekly dev chat maybe.

[davidakennedy]

Right, @afercia – that's something that should be talked about.

I think reasonable alternatives would be:

1. Don't use SVGs. :( Go back to using icon fonts.
2. Explore a way to ditch use xlink. Maybe this will help? ​https://css-tricks.com/svg-use-with-external-reference-take-2/

I'd love to decide sooner rather than later because of the big impact this has on the CSS and color schemes.

[sami.keijonen]

1. I hope the browser bug will be fixed soon.
2. Could tabindex=-1 help here inside <use>?

[sami.keijonen]

@afercia: Can you see the same issue on this ​demo site where I use external path and ​SVGxuse

[swissspidy]

@sami.keijonen Same issue on that site.

[afercia]

@sami.keijonen yes, same as @swissspidy (hey you beat me!) as soon as focus gets to the first icon, then it is lost and returns to the first control in the browser's toolbar. Using macOS Sierra and Safari 10.

[sami.keijonen]

Of course there is the same issue:)

@swissspidy: any news from the Apple bug ticket? I don't have access to it.

I'd also like to read this ​SVG bug article but SM have been down for me 12 hours already.

[arush]

This comment will close this ticket, so someone will need to reopen once it's posted.

I think there are two ways to fix this, neither of which are going to be fun. either fall back to font icons only in Safari, or granularly manipulate the tab order using tabindex. I vote for the former, but am looking forward to what gets discussed during the meeting tomorrow. I think manipulating with tabindex would get very messy very fast, and would introduce lots of possibility for errors.

[sami.keijonen]

Thanks @arush for comment.

One more idea. When you visit ​Github site, do you see the issue?

I'm not sure could we inject the SVG right in the markup in the similar way as explained in ​Github SVG article.

[swissspidy]

No update on my bug report, although I found two related issues on the Webkit bug tracker:

• ​https://bugs.webkit.org/show_bug.cgi?id=154114
• ​https://bugs.webkit.org/show_bug.cgi?id=162866

The latter mentions a possible workaround:

Even though we've found a workaround (a very odd one i must say, you need to insert a whitespace around <use> like here: ​https://jsfiddle.net/hsrdm2vv/), we sincerely hope for this to be fixed, because it breaks user experience on a lot of websites that use svg icons.

I can confirm that this works as expected! See attached patch.

Note: Shouldn't <use> and the <span> tag be self-closing? Was that intentional?

[sami.keijonen]

Oh, that would be cool fix even if it's weird!! Thanks for digging into this one.

Note: Shouldn't <use> and the <span> tag be self-closing? Was that intentional?

Does self-closing means this <use xlink:href="#icon-' . esc_html( $args['icon'] ) . '" />?

If that's the HTML5 specs let's definitely go with that one. I haven't check the specs on this one.

[afercia]

A whitespace, really? I mean, come on Apple
I can confirm the fix works in macOS Sierra and Safari 10, even when using VoiceOver.
More specifically, seems the whitespace added after <use> fixes the bug when tabbing forwards, and the whitespace added before fixes it when tabbing backwards. Also a line break "\n" seems to work, I guess Safari parsing issues?

I'd recommend to test this in at least the last two OS X/macOS versions with both Safari 9 and 10.

@swissspidy if this works in all the recent combos, I'm going to vote for you at the next President of the Universe election.

[afercia]

Quick note about self-closing:

Not really a SVG expert here, but all the examples I see in the current W3C Recommendation are self-closing, e.g.:

<use x="20" y="10" xlink:href="#MyRect" />

​https://www.w3.org/TR/SVG11/struct.html#UseElement

On the SVG 2 spec, which is still a Candidate Recommendation, there's one example of not self-closing <use>:
​https://www.w3.org/TR/SVG2/struct.html#DescriptionDefinitions

  <use href="#star">
    <title>Favourite</title>
    <title lang="en-us">Favorite</title>
    <title lang="nl">Favoriet</title>
    <title lang="">★</title>
  </use>

That's a particular case though. I guess it's not a big deal but since the <use> doesn't contain anything in the Twenty Seventeen implementation, maybe better to self-close it?

[davidakennedy]

I can confirm that patch works in Sierra on Safari 10 and El Capitan on Safari 9.1. Tested via Browserstack, but happy to have more testing.

I would be for committing this patch, assuming it works in all testing. It can be removed later when the bug is fixed.

[swissspidy]

As per the discussion on Slack, let's call for testing during dev chat.

[sami.keijonen]

Any news from this ticket? I'm good with current solution before Safari bug is fixed.

[davidakennedy]

It turns out that xlink is deprecated. See: ​https://wordpress.slack.com/archives/core/p1477612475010462

Supporting documentation on that: ​https://www.w3.org/TR/SVG2/linking.html#XLinkRefAttrs

So, it should probably be switched to href, however, as far as I know the bug still exists. I need to test with this patch to see if it's fixed. We may be able to use both for backward compatibility. That needs to be investigated as well.

[sami.keijonen]

That's interesting. I need to look into it more also. I haven't notice any new articles or browser testing using only href.

[afercia]

Discussed a bit in today's accessibility bug scrub, this ticket would need a decision about xlink (it is deprecated in a Candidate Recommendation). Also some more testing on real devices, not just Browserstack. At the very least:
Sierra + Safari 10
El Capitan + Safari 9
El Capitan + Safari 10
maybe also on iOS, just to be sure the svg icons don't mess up something even if there's no keyboard navigation no iOS :)

[rianrietveld]

Tested patch 38387.diff for menu/dropdown on

• Safari Version 10.0.1 OSX El Captain Version 10.11.6: works
• Safari Version 10.0.1 OS Sierra 10.12.1: works

Note: without the patch the menu/dropdown where not keyboard accessible at all.

[davidakennedy]

In 39164:

Twenty Seventeen: Improve SVG markup, providing more options customization

• Removes aria-hidden argument. Lets aria-hidden="true" be there by default and sets it empty when there is title and desc.
• Adds unique IDs for title and desc for accessible implementation options.
• Removes absolute path in the Customizer. It didn't work in Internet Explorer, and the original bug is fixed in #30028.
• Add whitespace around <use>, from #38387.

Props sami.keijonen, swissspidy, laurelfulford.

Fixes #38659.
See #38387.

[davidakennedy]

This is fixed in r39164, but let's decide how to handle the deprecated xlink attribute here.

[davidakennedy]

Uses both xlink:href and href for future friendly markup plus a fallback.

[davidakennedy]

We talked about this today in the bug scrub, and after some experimentation, I think I have a good solution. In 38387.2.patch​, I add the href, but keep xlink:href too. In testing, many browsers have not implemented just href including Safari 10, IE 11 and more. But according to the spec, both can be there. See:

​https://www.w3.org/TR/SVG2/linking.html#XLinkRefAttrs

I didn't alter the declarations at the top of the SVG file, again for maximum compatibility. Those are these:

version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"

This worked well in all the target browsers, plus some older ones with SVG support.

[sami.keijonen]

Seems good to me. Also tested on Windows using Chrome, Firefox, IE11 (emulated IE10, IE9, IE8), and worked like it should.

[afercia]

38387.2.patch​ looks good to me. At the moment Chrome seems the only browser that works with only the href attribute. Firefox still needs xlink:href though ​MDN categorically states "do not use" 😯

[karmatosed]

In 39206:

Twenty Seventeen: Keyboard navigation on Safari 10 fix

This resolves the weird behaviour on Safari 10 has some weird behaviour.

Props rianrietveld, swisspidy, afercia, sami.keijonen, arush, davidakennedy
Fixes #38387