Back to Blog

Revisiting the Fresh Tilled Soil accessibility stack

Author

At Fresh Tilled Soil we continue to believe that accessibility is a large part of designing great user experiences. Back in 2014 we published an article outlining our accessibility stack, calling out tools we use to ensure we are building experiences that are accessible for people with visual impairments, or those that are deaf or hard of hearing.

Today we’d like to revisit this post, because as we all know, technology moves fast and in the three years since the original post, we’ve made a few modifications to our accessibility stack that we’d like to share with you today.

Creating Accessible Interfaces:

Here is an outline of some of the things we keep in mind, and the tools and resources we will use when designing and developing accessible user interfaces.

Before we even start coding

Checking our designs for color contrast issues is one of the earliest wins we can achieve when creating accessible user interfaces:

  • Color Oracle is an application for Mac or Windows that will simulate the three most extreme types of color blindness: Deuteranopia, Protanopia, and Tritanopia.
  • WebAIM Color Contrast Checker: For quick pairings of foreground and background color combinations, the WebAIM checker will give you immediate results on how your combinations fair against WCAG AA and AAA standards.

For more information about designing for color blindness, please read Designing for (and with) Color Blindness.

Moving into the browser

One of the most important pieces of our stack that continues to hold true is that we take great efforts to follow HTML best practices. Regardless of whether your project is built with WordPress, Drupal, React, or Angular, the output will be HTML, and to ensure accessible user experiences, that HTML needs to be used appropriately in the context of what you’re building.

In adherence to markup best practices, here is a list of the primary checks and tools we use when developing our projects:

Try to use your website/app without a mouse

  • Can you easily tell where you are?
  • Are you able to interact with important inputs and controls?
  • Does your focus ever become “trapped” (e.g. you can’t tab past or back out of a certain portion of your interface)?

Use the semantic, appropriate markup for the task at hand

  • Links go places
  • Buttons perform actions
  • <divs> are not meant to be clickable!
  • etc…

Only use ARIA when there is no native markup solution

If you’re building web components, build them with semantic markup elements. If you’re finding yourself in a situation where standard markup just isn’t cutting it, use ARIA to help augment your markup to help meet user expectations.

Check your interfaces for accessibility compliance

We run automated and manual tests against our code and interfaces for any accessibility missteps.

Build with Progressive Enhancement

This doesn’t mean websites and apps need to work the same with or without JavaScript. But how does your site or application work if certain assets become blocked or are unavailable for any reason? Try turning off JavaScript or CSS using developer tools to see how your interface fares.

Test with Screen Readers!

Accessible HTML5 browser implementation has come along way, to the point where Microsoft Edge has 100% implementation support! This means that testing with screen readers is even more important, as you should get more consistent and expected results when writing semantic, accessible code. There are even free or built in screen readers you can be using to test your interfaces:

  • VoiceOver on OSX and iOS (built in)
  • JAWS on Windows
  • ChromeVox for Chrome OS and Chrome Browsers on Mac and Windows (built in / free)
  • Narrator for Windows (built in)
  • NVDA for Windows (free)
  • Talkback for Android OS (built in)

See what browsers best pair with different screen readers.

Visual Simulation

While screen readers are used by many people with low to no vision, there are many people that may not use a screen reader because they don’t associate themselves with having a disability that would necessitate a screen reader. Think about people with color blindness, or even those that just wear reading glasses. These people can see but there may be situations where they may have issues parsing a design in less than optimal conditions.

We use the following tools to help us test for these, and other, visual impairments:

Accessibility refers to all media types

Beyond all the above mentioned resources and techniques, we must also keep in mind that making an accessible interface doesn’t just mean making it accessible for people with vision impairments. We continue to use the following resources when working with rich media like audio and video on the web:

We still use Vimeo and Wistia because of their options to upload a caption document. YouTube has an auto-captioning service, but it still is not perfect. We still use Speechpad to generate caption files, which (at the time of this writing) only costs $1 per minute.

  • Video services that accept captioning
  • Speechpad transcription service
    • Audio transcripts
    • Video captioning

In closing…

As the web grows and technology rapidly changes, we’ll continue to be on the lookout for new and better ways to ensure we’re building accessible user experiences. And, as we mentioned last time, there are many other types of accessibility concerns to test for, but we hope you’ve found this primer to be useful to get a good base in creating accessible user experiences. Check out some of our other accessibility posts and get in touch if you want to know how we can improve the accessibility of your website or product.

Author Scott O'Hara

As a designer and developer, Scott loves pushing the limits of CSS, designing usable, accessible experiences for all, and teaching and writing about UX development.

More posts from this author

How we work Process

Product Hero Talin Wadsworth