In IE11 double focus bug (accessibility related)

[gtibrett]

In IE11 if you tab through links (or any focusable element) containing SVG elements it will have two tab stops.

Fix is to add focusable="false" to the SVG element.
This works around an IE11 bug that defaults SVG elements to focusable="true".
The double focus can also cause some screen readers to double-read.

Example Page: https://labs.levelaccess.com/index.php/Remove_SVG_from_Tab_Order
Also See: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8090208/

I understand that:

• I'm submitting this PR for reference only. It shows an example of what I'd like to see changed but
  I understand that it will not be merged and I will not be listed as a contributor on this project.

[tagliala]

@gtibrett thanks!

[tagliala]

is this also affecting Edge < 14.14393 ?

[gtibrett]

We tested in Edge 17.17134. The IE bug is not present there.

The linked Microsoft defect states that it is fixed in 14.14393

Fixed in EdgeHTML 14.14393

[robmadole]

Ok, we'll have to be careful with this one. It's a simple code change but could have ripple effects. I'll get this one on the board. Thanks @gtibrett !

[bliles]

Any updates on this? It's still an issue currently that affects our users. I would open a new PR since there are conflicts here, but given that this repo is used only for reference/publishing there doesn't seem to be much value to that since the fix is simple to implement.

[bliles]

Also, just a detail since we might have the tendency to dismiss IE issues, most JAWS users are likely still using IE.

References:
https://webaim.org/projects/screenreadersurvey7/#browsercombos http://www.hollier.info/browserpairing/

[robmadole]

Alright folks, sorry for taking so long. We are catching up on older issues as we can.

So I hesitate to add focusable because it doesn't seem to be the future direction of SVG. The newer spec uses the same type of focusing mechanism as normal HTML elements.

Right now you can add an icon and specify this yourself using the extra attribute pass through. Like this:

<i class="fas fa-beer" focusable="false"></I>

Would this work? If this is a valid workaround I'd be happy to add to our accessibility docs.

[gtibrett]

The issue is that without adding focusable="false" IE will create a double tab stop on the svg when navigating by keyboard. FA is already injecting aria-hidden to make the icons accessible to screen reader users, but, without the focusable="false", they remain inaccessible to keyboard only users.

The issue is widespread and affects all svgs, so I would expect it to be auto injected as part of the advertised auto-accessibility feature of FA. I added it inside the autoA11y blocks as that seemed to be the best solution.

[bliles]

I agree with @gtibrett that we would prefer to have this functionality baked in, either as a configurable option or the default autoA11y behavior since it's going to require a lot of markup adjustments on our end. However, to answer your question @robmadole, adding focusable="false" to the <i> tag does work and it is the approach we had settled on as a workaround.

[jimjenkins5]

I'd like to add my support for adding this feature.

The accessibility docs say:

Getting accessibility right can be tough. So we’ve tried to make it as simple as we can with our auto-accessibility feature. Using a dash of JS, we add supporting HTML elements and attributes so that your icons are accessible to the widest audience possible.

Since JAWS/IE is the most popular screen reader/browser combination, it seems that this attribute fits the qualification for the auto-accessibility feature. It would definitely make the icons more accessible to a large part of the audience. This is an easy thing to miss and a hard thing to figure out. If the accessibility feature is aimed at making the difficult task of accessibility easier, this seems like a perfect candidate to add by default.

[stevefaulkner]

FWIW adding focusable="false" to non interactive SVG elements is standard practice to fix the issue that occurs in IE. Note this issue also effects non-screenreader keyboard users in IE. The inclusion of focusable="false" has no known negative effects.

[scottaohara]

@stevefaulkner beat me to it :)

Another thing to consider, per the previously linked accessibility docs

<i class="fas fa-camera-retro" aria-hidden></i>

snippets like that should probably be updated to specifically call out aria-hidden="true". Without a set value, aria-hidden defaults to undefined and screen readers can still parse the content.

[tagliala]

@scottaohara thanks for reporting this. Could you please open a new issue?

[scottaohara]

@tagliala created #14506

[robmadole]

@gtibrett @bliles @jimjenkins5 @stevefaulkner ok, you all have convinced me. My only concern with making it the default is the potential to create a problem for someone else. You all are telling me there are no downsides so I'll take that bet with ya. Let's .

This should be implemented as part of 5.7.0.