At Fresh Tilled Soil we strongly believe that accessibility is a large part of designing a great experience. It’s frustrating to see some designers and developers ignore a large segment of the population, so we host events like Global Accessibility Awareness Day, write articles (like this) and make it part of our everyday life to try and build awareness.
Accessibility isn’t sexy. But, when trying to create a complete experience that works regardless of the way it’s being accessed, it is critically important. It’s part of Progressive Enhancement, it’s part of Responsive Design, it’s part of Universal Design, and it’s part of whatever popular buzzword you want to use (because it’s a large part of the Web).
One of the difficult parts of testing for Accessibility is knowing what’s available (knowing is half the battle). With that in mind I’ve put together a list of the tools we use here at Fresh Tilled Soil to help you fill out your testing suite. I’ve broken it down into two major buckets: Visually Impaired and Deaf & Hard of Hearing. And yes, I triple checked those terms as to not offend anyone, but in case I missed something please send all your vocal complaints to @stevehickeydsgn on Twitter (see what I did there?).
A lot of times if I’m having trouble convincing someone about the importance of accessibility (usually because they don’t see how it will increase profits…) I refer to Karl Groves’ list of accessibility-related lawsuits (last updated 2012) and the value is immediately realized.
HTML best practices
Google’s Shawn Lauriat gave a great presentation about accessibility in complex web applications for Boston’s Accessibility Conference recently, where he said that using semantic HTML gives you a lot of great accessibility features for free (little developer effort). This is why properly using meaningful HTML is so critical.
Here are some basic points that will guide you in creating semantic markup:
- Try and use your site/app without a mouse (the basic accessibility test)
- Follow Web standards, use alternative text, and implement semantic markup
- Section 508
- Using ARIA roles
- Progressive enhancement
Screen reading software
Getting good screen reading software is critical. Some of them (JAWS) are really expensive and some are free (NVDA, VoiceOver, ChromeVox). Personally, I like the free ones; besides the obvious cost savings, they are generally more advanced than the paid ones. They’re a great quick litmus test for checking the accessibility of your app or site.
Try out these screen readers:
Visual accessibility doesn’t stop at the blind. There are many other types of visual impairments to keep in mind while designing an experience, including (but not limited to): colorblindness, low vision, contrast loss/blur, glaucoma, and even eye floaters. A lot of these are difficult to simulate, but we’ve found a couple tools that have been extremely helpful.
NoCoffee is a Chrome extension built by our friend Aaron Leventhal, who spoke at Global Accessibility Awareness Day this year. It’s one of my favorite accessibility tools, as it simulates a wide variety of visual disabilities. I very much recommend checking it out.
Here are a couple tools for vision simulation:
Deaf and Hard of Hearing
Accessibility on the Web doesn’t stop at the eyes. In a Web with increasing audio and video media, we need to make sure these resources are accessible without sound. For this reason, we want to be sure that everything we produce has a text-based version as well (captioning for videos and transcripts for audio).
For video, we use Vimeo & Wistia because they have an option to upload a caption document. YouTube has an auto-captioning service, but it leaves a lot to be desired. To generate those caption files (.vtt) we use a service called Speechpad, which (at the time of this writing) only costs $1 per minute… which is awesome.
- Video services that accept captioning
- Speechpad transcription service
- Audio transcripts
- Video captioning
There are, of course, a lot of other types of accessibility to test for, but using this list as a baseline has allowed us to have a reasonable starting point for testing project-to-project. The suite of tools changes a bit every time we use it, but we’ve found over time that creating this list of standards has helped us a great deal. Of course, we hope that it helps you as well!
If you have anything to add to this list, I’d love to hear your thoughts!