#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: |
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)
Change History (46)
#2
@
8 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
@
8 years ago
Submitted a bug with Apple Bug Reporter. Issue no. 28889219.
#4
@
8 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
@
8 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
@
8 years ago
Right, @afercia – that's something that should be talked about.
I think reasonable alternatives would be:
- Don't use SVGs. :( Go back to using icon fonts.
- 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.
8 years ago
#8
@
8 years ago
- I hope the browser bug will be fixed soon.
- Could
tabindex=-1
help here inside<use>
?
This ticket was mentioned in Slack in #accessibility by sami.keijonen. View the logs.
8 years ago
#10
@
8 years ago
@afercia: Can you see the same issue on this demo site where I use external path and SVGxuse
#12
@
8 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
@
8 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
@
8 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
@
8 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.
#16
@
8 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
@
8 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
@
8 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 lease 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.
#19
@
8 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.
8 years ago
#21
@
8 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.
8 years ago
#24
@
8 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.
8 years ago
#26
@
8 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.
8 years ago
#28
@
8 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
@
8 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.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#32
@
8 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
@
8 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.
#35
@
8 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.
8 years ago
#37
@
8 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.
8 years ago
#39
@
8 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.
8 years ago
This ticket was mentioned in Slack in #accessibility by davidakennedy. View the logs.
8 years ago
#42
@
8 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" 😯
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.