Foundation-sites: [Reveal] Safari (macOS): Tab focus is not inside modal

[LayZeeDK]

In Safari 9.x on a Mac, tab focus is not inside the opened modal when a modal is made with Reveal like in the docs:
http://foundation.zurb.com/sites/docs/reveal.html

This is not in compliance with WCAG 2.0 and not coherent with the behaviour of other contemporary browsers, where you are only able to tab between the close button and the content of the modal when the modal is active.

[zurbchris]

Safari strikes again! I'll see what I can do to get this fixed.

[zurbchris]

Ok, this is a Safari only bug. Can we all just agree that Safari has come up lame and Apple should do the right thing, "Yes, Mama. But he was my browser. I'll do it."?

Back on point, does anyone have a potential solution to this? I'd rather ask the community than spend the next day researching if someone has an answer.

[LayZeeDK]

Tell me some good news, @zurbchris :-)

[sethkane]

@zurbchris & @gakimball & @LayZeeDK

I have been reviewing this issue with screen readers and I believe it is larger than just with Safari. I have created some videos to demonstrate of the Reveal code isn't accessible.

Zurb Code via Jaws: https://www.dropbox.com/s/eaj2jxmge3jbn4o/jaws-reveal-zurb.mov?dl=0

I haven't contributed before but I would really like to help make the Reveal more accessible for not only safari but all browsers and all screen readers.

From my first look at the code the issues are:

• Body has a tab index of -1
• Modal Overlay has a tab index of -1
• Modal doesn't have a role=region
• Modal doesn't have a tab index of 0
• Modal aria-labeledby is assigned to either the link that opened it or an randomly generated assigned ID

These issues looks/sounds like:
https://www.dropbox.com/s/l56ofy1kewpqgwf/jaws-reveal-sample-not-accessible.mov?dl=0

Proposed solutions:

• Remove all the unnecessary -1 tab index
• Add correct role and tab index to modal
• Update the aria-labeledby to look for a header in the modal content and utilize that content

I have a small working example of this at:
https://www.dropbox.com/s/2405owtqi0s39xd/jaws-reveal-sample-accessible.mov?dl=0

Let me know if and how I can help.

Seth

[kball]

@sethkane Absolutely you can help! Probably the best approach is to create some test cases that exhibit the bugs (probably for this example in the visual test suite: https://github.com/zurb/foundation-sites/wiki/Testing-Guide#visual-regression-tests). From there, develop fixes to address the issues and submit a PR with them and your proposed fixes.

@Owlbertz you are probably the most experienced of the Yetinauts on accessibility, do you have any other pointers for @sethkane on getting started here?

[Owlbertz]

Hi @sethkane, thanks for the effort you put into this - much appreciated.
If you want to help you can open a pull request with enhancements at any time or just open issues/write comments like the one above if you want another contributor to fix the issues.
If you want you can contact me directly via mail or Gitter so we can discuss what should be changed in detail.

[sethkane]

I think I am going to try and fix it in my own branch and then do a pull request. I will keep you all posted. Thanks for allowing me to help out.

[sethkane]

@Owlbertz I sent you an email let me know if you didn't get it. Note: I pushed my branch a few times but kept needed to clean it up that is why it is crazy pushes. Sorry new to contributing to public repos. This commit has the latest: 61e94d3

[Owlbertz]

Yeah, don't worry. I got the mail and will review your stuff tomorrow. I'll mail you back.

[sethkane]

@LayZeeDK This issue was merged into the develop branch if you want to check it out.

[LayZeeDK]

Thank you for making progress, @sethkane. However, I don't have access to a Mac anymore.

[LayZeeDK]

@sethkane @Owlbertz @kball Seems that @sethkane's commits were merged into v6.2.4, right? Now, who has access to a Mac to test whether this issue can be closed?

[sethkane]

These changes were merged in a long time ago but now that I think about it I think I might need to update the Visual Tests and such. I will look this week.

[kball]

Doing a little testing on some of the visual tests, it definitely seems like reveal keyboard accessibility (not just on safari) still needs some work

[sethkane]

@kball Can you unpack what "still needs some work" means. I just checked http://foundation.zurb.com/sites/docs/reveal.html and it has the code I updated and it works as I would expect it.

[kball]

You bet... I was looking at the reveal visual test (http://localhost:3000/reveal/basic.html) and upon opening one, I could not tab through the interior links.

[sethkane]

Yeah like I said before when I did this one I wasn't even aware of the visual tests and such I just worked straight from the docs. I will have to review and update the visual tests but the code itself is good so if you wanted to you can check out the code and examples in the docs. Stay tuned and I will let you all know when it is updated in the tests and such.

[LayZeeDK]

How is it coming, @sethkane?

[sethkane]

@LayZeeDK Haven't looked into it for over a year and have been out of the foundation framework for that amount of time too. Sorry someone else will have to pick it up from there.

[LayZeeDK]

Thank you for getting back to me, @sethkane.

@kball Are you able to pick this up? Test the issue on a Mac using Safari?

[DanielRuf]

What is the current state here?

[LayZeeDK]

I have no idea, @DanielRuf. I do, however, currently have access to a Mac, so I will test the issue one of these days.

[DanielRuf]

I have no idea, @DanielRuf. I do, however, currently have access to a Mac, so I will test the issue one of these days.

Great, keep us updated and let us know if you need any help.

[LayZeeDK]

For Foundation for Sites 6.4.3, I just tested this on Safari 11.0.3 (13604.5.6) on macOS. Unfortunately, this is still an issue. The tab focus is not inside the modal, it is on the page elements that are behind the backdrop overlay.

In Chrome on macOS, it works as intended, with the tab focus inside the modal.

Steps to reproduce issue on Sites Docs

1. Navigate to https://foundation.zurb.com/sites/docs/reveal.html.
2. Press the _Click me for a modal_ button in the _Basics_ section.
3. Press the _Tab_ key on your keyboard.
4. The tab focus should be on the _X_ (close) button.

I also tried this from the develop branch.

Steps to reproduce issue on develop branch

1. Run npm start.
2. Your browser opens on http://localhost:3000.
3. Navigate to http://localhost:3000/reveal.html.
4. Press the _Click me for a modal_ button in the _Basics_ section.
5. Press the _Tab_ key on your keyboard.
6. The tab focus should be on the _X_ (close) button.

[tiger-chan]

This is a Safari setting that is off by default which seems to be the root cause.

When enabling it the modal in your Basic section it appears to work just fine. With that said i'm not sure if it's possible to work around the setting.

[DanielRuf]

Do you mean the Press Tab to highlight ... setting?

[tiger-chan]

Yes, sorry for not stating that more clearly.

[LayZeeDK]

Great discovery, @tigerchanay. Thanks!

[DanielRuf]

Closing as this is a browser bug.

[LayZeeDK]

A bit more context? Isn't Foundation supposed to iron out browser compatibility with its components? Is there an issue on Safari for this?

[DanielRuf]

https://github.com/foundation/foundation-sites/issues/7904#issuecomment-386329363 suggests that this is browser bug / issue.

In general this is a very old Safari version that even Apple does not support anymore.

It's not a good idea to "fix" browser bugs with JS workarounds.

[LayZeeDK]

I don't have a Mac to test it in the most recent version of Safari.

I see your point if that setting is the root of the problem. However, accessibility sometimes needs to be ensured with extra JavaScript and HTML. Foundation boasts to be accessible.

[DanielRuf]

Well, see https://github.com/foundation/foundation-sites/blob/develop/js/foundation.reveal.js#L312-L319

So there is already code to "fix" such cases but Safari is just problematic. The ssue still occurs in the latest Safari version.

When I enable the option to higlight all elements on the page when tab is pressed it works as expected. If it is disabled the issue occurs.

So Safari keeps control of the focus. Something that we can not directly fix.

Even the trapFocus does not work in this case.
This is why I say that we should not try to fix it using JS, it is very unreliable in general.

[DanielRuf]

See also https://stackoverflow.com/questions/52783375/anchor-with-href-not-taking-focus-in-safari-even-with-all-accessibility-keyboard and https://css-tricks.com/a-css-approach-to-trap-focus-inside-of-an-element/

Disclaimer: The

demos in this article are tested on Chrome and Firefox browsers only. Safari has some weird issue where not all elements are focused while doing a normal keyboard navigation with Tab key!

This fixes it too:
https://css-tricks.com/a-css-approach-to-trap-focus-inside-of-an-element/#comment-1618363

For the Safari standard keyboard navigation problems, have you made sure that in System Preferences->Keyboard->Shortcuts, Full Keyboard Access is set to “All Controls”?

So this is a very specific issue on macOS where the system takes over the control and these two settings (System Preferences->Keyboard->Shortcuts, Full Keyboard Access is set to “All Controls” is sufficient) "fixes" this.

This is probably a feature of Sfari and macOS. But at least not a bug on our side or something that we can prevent / fix as you can see.

[DanielRuf]

I fail to see how we can fix this when Apple takes the control like this. So my opinion is still the same: don't try to fix browser bugs / issues with JavaScript. This won't work.

[LayZeeDK]

Alright Daniel. Thank you for clarifying 😊