Here at Americaneagle.com, we have run into all types of issues and quirks that can only really be determined through manual testing. Having gone through audits and accessibility web development for projects, we have a bit of a list accumulating of different "gotchas" or hidden issues even when spec appropriate code is being used. Unfortunately, browser differences in the accessibility tree of the DOM can be the culprit for some hidden a11y issues. This is by no means exhaustive and there are many resources and developers out there trying to figure out workarounds. I figure a little bit of insight into the inconsistencies will help out web masters and content providers as well as developers out there.
Ready to take your website's accessibility to the next level? Contact us today to learn more about our web accessibility consulting services and how manual testing can enhance your site's inclusivity.
For this round of "gotchas":
Whitespace can be dangerous…
Safari actually has a couple of big ones people will want to watch out for since these issues break usability. One of these that stands out but is somewhat under the radar is related to whitespace. Wait, whitespace in code is dangerous to accessibility? In general I would say no, but surprisingly in this case it is a definite yes.
If you are thinking of minifying your html code to reduce whitespace and are using SVG <use> tags, keyboard usability of your site will break. Currently there is a bug in Safari that if there isn’t whitespace between the <svg> and <use> tags the browser will create a keyboard trap. Once the user tabs to the first instance of a SVG icon (e.g. if it is inside of an anchor) without that whitespace they will end up in the address bar of the browser. If you have a minifying tool that can parse/minify while adding in at minimum a space or new line, you are then in luck. Here is the bug tracker for this Safari bug and since it is webkit that’s the only major browser you really need to worry about for this. We’ll have to see if it is fixed in their next release cycle. But in the meantime definitely code your svg icon sprite tags with a bit of extra whitespace.
SVG quirks in browsers aren’t limited to Safari
The next particular SVG bug is for Internet Explorer and Edge. The spec for SVG 1.1 and SVG2 wasn’t adopted in IE but rather SVG 1.2 Tiny. This has led to quirks of SVGs always being focusable unless declared otherwise in those browser. This is true even if you add a tabindex="-1" to the SVG tag, since that is part of the SVG2 spec. So what happens because of this? In the similar instance to the prior Safari bug if a user is tabbing to anchors and an SVG icon is in that, expected functionality isn’t quite met. This is by no means as bad of an issue as the Safari bug, but it is an annoyance. What happens is that as screen reader user for example is tabbing through to the anchor the text will be read, but when they tab again the user will read the same icon text again because they focused inside of the anchor on the SVG. Depending on how the SVG is setup nothing might be read at all, so a user would end up on an area of the page with no direction and just silence.
So what can we do to fix that? Luckily there is an attribute "focusable" which most people aren’t aware of, because the use cases for it are lacking. If you add focusable="false" to your svg tag then it is removed from the tab index flow and thus return back to normal behavior of all other browsers.
Title attribute is not a fix all solution
This issue isn’t really a specific browser issue but rather a mixture of browsers and screen reader inconsistencies. I’ve seen WordPress plugins and other tools try and fill in blank anchor tags with the title="anchor description" to help fix the issue. However, what we noticed in actual testing is that many times that is not read by default or at all. This is why even the W3C added a warning note to avoid use of title attributes. The best way to have an accessible link is to actually have text inside. If you are using an icon font to create an image inside of an anchor note that not all screen readers read CSS injected characters and many times it won’t be helpful. So what to do if you want a visual indicator but don’t want to actually show text. This is where the styling for a "visuallyHidden" or in Bootstrap "sr-only" comes in.
.visuallyHidden, .sr-only {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
The above code method will make sure that the text is visually hidden but still accessible to screen readers. Do note that if you are using general looking icons, including some visual text will help all users better understand what that link does or where it goes. Even adding the word "menu" under a hamburger menu will make it faster for users to figure out where to click.
