Back to Blog

The Fresh Tilled Soil Accessibility Stack


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.

Visually Impaired

HTML best practices

Using semantic HTML makes accessibility easy

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:

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:

Vision Simulation

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!

Author Tim Wright

More posts from this author

Sign up to receive updates from our blog

What we do Expertise

From concept to design, we'll partner with your team to deliver amazing product and website experiences.

Recent Projects Work

See the results of our most recent digital product and website engagements.