WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#38387 closed defect (bug) (fixed)

Twenty Seventeen: Keyboard navigation on Safari 10

Reported by: afercia Owned by: davidakennedy
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords: has-patch needs-testing dev-feedback
Focuses: accessibility Cc:
PR Number:

Description

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

Attachments (2)

38387.diff (1.2 KB) - added by swissspidy 3 years ago.
38387.2.patch (703 bytes) - added by davidakennedy 3 years ago.
Uses both xlink:href and href for future friendly markup plus a fallback.

Download all attachments as: .zip

Change History (46)

#1 @davidakennedy
3 years ago

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.

#2 @rianrietveld
3 years ago

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

#3 @swissspidy
3 years ago

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

#4 @davidakennedy
3 years ago

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?

#5 @afercia
3 years ago

@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.

#6 @davidakennedy
3 years ago

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.

This ticket was mentioned in Slack in #design-dashicons by sami.keijonen. View the logs.


3 years ago

#8 @sami.keijonen
3 years ago

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

This ticket was mentioned in Slack in #accessibility by sami.keijonen. View the logs.


3 years ago

#10 @sami.keijonen
3 years ago

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

#11 @swissspidy
3 years ago

@sami.keijonen Same issue on that site.

#12 @afercia
3 years ago

@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.

#13 @sami.keijonen
3 years ago

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.

#14 @arush
3 years ago

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.

#15 @sami.keijonen
3 years ago

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
3 years ago

#16 @swissspidy
3 years ago

  • Keywords has-patch added; needs-patch removed

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

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?

#17 @sami.keijonen
3 years ago

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.

#18 @afercia
3 years ago

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.

Last edited 3 years ago by afercia (previous) (diff)

#19 @afercia
3 years ago

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?

This ticket was mentioned in Slack in #accessibility by sami.keijonen. View the logs.


3 years ago

#21 @davidakennedy
3 years ago

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.

This ticket was mentioned in Slack in #accessibility by davidakennedy. View the logs.


3 years ago

#23 @swissspidy
3 years ago

  • Keywords commit added

#24 @swissspidy
3 years ago

  • Keywords commit removed

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

This ticket was mentioned in Slack in #core by davidakennedy. View the logs.


3 years ago

#26 @sami.keijonen
3 years ago

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

This ticket was mentioned in Slack in #core by davidakennedy. View the logs.


3 years ago

#28 @davidakennedy
3 years ago

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.

#29 @sami.keijonen
3 years ago

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

This ticket was mentioned in Slack in #design-dashicons by empireoflight. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

#32 @afercia
3 years ago

  • Keywords needs-testing added
  • Owner set to davidakennedy
  • Status changed from new to assigned

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 :)

#33 @rianrietveld
3 years ago

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.

#34 @davidakennedy
3 years ago

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.

#35 @davidakennedy
3 years ago

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

This ticket was mentioned in Slack in #core by helen. View the logs.


3 years ago

@davidakennedy
3 years ago

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

#37 @davidakennedy
3 years ago

  • Keywords dev-feedback added

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.

This ticket was mentioned in Slack in #core-themes by davidakennedy. View the logs.


3 years ago

#39 @sami.keijonen
3 years ago

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

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by davidakennedy. View the logs.


3 years ago

#42 @afercia
3 years ago

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" 😯

#43 @karmatosed
3 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

This ticket was mentioned in Slack in #core-themes by sami.keijonen. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.