How we added accessibility to our web app

We recently held our Fall Hackathon where all teams at Panorama take a 24-hour period to collaborate across the whole company to hack on great things. Many of our Hackathon projects are outside of our day-to-day work, would move Panorama’s efforts forward, or just solve that nagging problem that you just hadn’t gotten around to yet. For the four of us (1 engineer, 2 account managers, and 1 director) on Team A11y, we focused on the accessibility of our product.

Accessibility here refers to the design of products, devices, services, or environments for people with disabilities. Our products are used by students, families, and educators around the world, and we need to be able to serve every user as equally as we can. Fortunately, there are some initiatives in the tech world that provided us a lot of guidance and helped to shape our thoughts on how to approach this, in particular: the a11y project and W3C’s guidance on accessibility .

How We Approached This

Making a product accessible is a hard problem to approach, particularly if you don’t have experience with the tools and technologies used to make the web accessible to users. Luckily, there is a wide set of auditing and testing tools available to developers to make the job easier.

In order to establish a baseline, we explored our product using Apple’s Voiceover tool. Using this tool gave us some insight into what a user with a screen reader would experience on our current site. Although most of our pages were functional using a screen reader, there were definitely gaps (see the advice at the bottom of this post). We also got in touch with friends of Panorama who either work in the area of accessibility compliance or are blind themselves.

Once we had enough experiential information, we set our sights on getting more rigorous testing and auditing in place. The W3C’s Web Content Accessibility Guidelines (WCAG) is a set of standards which defines what it means to be an accessible website. There are several tools which check your page content against the WCAG and will alert you to problems. Both Chrome and Firefox have extensions which will audit pages (such as Chrome Accessibility Developer Tools and the aXe Core Extension-Available for and ), and there are bookmarklets and plugins that help inspect page content (such as ). We used these plugins to start attacking some of the bigger accessibility problems we had.

It’s a well known problem that manual testing is only good if it’s done regularly. As engineers, we know the importance of automated testing to prevent regressions. As part of the accessibility project, we wanted to ensure that all of the work we were doing wouldn’t go away as changes are made. We ended up setting up Capybara in our existing RSpec suite, and added a set of tests using the wonderful axe-matchers gem from dequelabs (https://github.com/dequelabs/axe-matchers). Each of our pages now has a corresponding test that ensures that the page is accessible. Any future changes will have to maintain compliance.

In addition to compliance in a desktop environment for folks who using tools like screen readers, we also thought about the 15–20% of our clients who use our application on a mobile device. Our website has not historically been designed with mobile users in mind. For example, here is how our survey taking interface would look on an iPhone 5:

Mobile compatibility is an area where Chrome’s Mobile Emulation was a wonderful tool for local development. It gave us a lot of flexibility in emulating different devices and the ability to switch between mobile and desktop as you tweak structure and style. Then, as we neared a new mobile-friendly version, we ended up using to test how it felt on our teammates’ actual mobile phones.

Our last steps were testing edge cases of accessibility like mobile phone usage with Voiceover and how our right-to-left languages support was affected. (It was so cool hearing this survey page read in Arabic on my phone!)

Advice for Our Future Selves

• Think carefully about colors. We use a standard shade of green across our brand that does not contrast well enough with white to be easily read. We also had to fix other contrasting colors around the application.
• Avoid using only images as the way to use or navigate parts of the application. For us, this meant requiring alt-texts for images that could viably explain the purpose of the image, or providing alternative ways to represent the image. (As an example, one friend that we consulted suggested providing an export to Excel for chart images, since Excel is a more well-known tool from an accessibility angle.)
• Think about mobile first. Our survey-taking app first assumed that you would have 960px or more of width and then structured the page from there. Given that most mobile devices don’t support that, we were already in a difficult place.

In the end, we successfully shipped a project (in 24 hours!) that moved the bar for equal access and availability for our app-a big improvement for many members of the school communities we serve.

For another view, here is a link to the post on our education blog about our accessibility work.

And if you’d like to come work with us on building tools like this to hear from everyone in a school community, we’re hiring!

Originally published at https://engineering.panoramaed.com on November 30, 2015.