Home Truths About Web Accessibility
I think a lot of web developers and designers have misconceptions about the ways to best create accessible websites. I say that after doing much research in past days by using screen readers to look at web pages. From that I learned a number of things about accessibility that contradicted what I previously believed (lots of which I am probably not alone on). So, those finding are what we are going to talk through but first I feel it is important to say that, for most of these issues, I was unable to find solutions that I thought were satisfactory. As a result of that, this post is less about giving actual solutions than just highlighting some general concerns to think about next time you’re developing a website. Of course, if you’re someone who has an intimate knowledge of this and can help shed some light, I’d love to hear what you have to say in the comments.
Tools For The Job
Before I even really got into specifics of actually checking my pages, I ran across the hurdle that is having to figure out what to use. A sin that I see committed by a lot of people in the web world (me included) is just saying something along the lines of " we need to make sure this markup is understandable to screen readers." The gaping flaw in that statement is generalizing screen readers and assuming that they all work the same as this is simply untrue. From what I found, cross-screen-reader quirks can be twice as hard to troubleshoot than cross-browser problems but aren’t spoken about half as much. The reason I say this is that, with the browser market, the stats make it easy to decide which browsers to support but, using screen readers, it’s less cut-and-dry.
These are the tools that I had access to and so chose to test with (remember though, the more apps you can test the better):
- VoiceOver – This is the tool built in to OS X that can read out content for most of the default applications. Thankfully, one of those that it works with is the Safari web browser.
- Fangs – An add-on for the Firefox web browser that allows you to load a page and then have a text based transcript of the elements that it found.
Things That I Noticed:
ALT Attributes For Images Not Placed In Context
So, the "alt" attribute should always be used on image elements because it is shown in place of the image if it fails to load but is also checked by screen readers. VoiceOver just spoke the text placed in the attribute but didn’t make clear that the text was connected to an image. The way around this one is just to include notation that is an image within the attribute value before any description of the contents.
CSS Styling Matters
A common accessibility tactic is to have an invisible link at the very top of a page to jump the header and navigation and dive into the important content. Theoretically, the benefit of this is that, a user being talked to doesn’t need to sit through all the stuff for the menu (which would normally come before the actual content) because they have a handy link to jump to where they need to be straight away. Upon trying it, the narration completely skipped over it because the CSS told that link to display: none. If that is the reason, then you have a choice to make; either you display the link for screen readers (and everybody else) even though most of the visitors won’t need it, or you can just leave it out all together.
Little Respect For The "tabindex" Attribute
The tabindex attribute can be applied to any HTML element and is a method to order the elements on the page in terms of tabbing through them with the keyboard. Unfortunately though, in my testing, the applications still failed to show up elements in the order that I had specified.
Conclusion
As I said at the start, those are just some interesting things to think about but, if you have any more information, please feel free to share down below.
An interesting survey of screen reader usage