Tag Archives: accessibility

Web Accessibility Visualization Tool: tota11y

Testing web sites and apps come in many forms. Testers try their best to test everything, but obviously there’s only so much they can do within a schedule. Some forms of testing are more prioritized than others, and that’s not inherently bad; for a solo tester on a team, one usually tests in a way that covers more bases at the beginning.

Web accessibility testing is one of those forms of testing that often takes a backseat, sometimes even forgotten. Web accessibility helps people with disabilities get better surfing experience. Although websites are typically not built with such functionality in mind, it matters.

And tota11y is a tool from Khan Academy we can leverage for testing accessibility. It is available as an easy-to-use bookmarklet. For whatever page we want to test, we just need to go there and click the bookmarklet, after which the tool will appear on the bottom left corner of the page. Clicking the tool reveals options and using each helps us spot common accessibility violations.

Here are some screenshots of using it on a page I test at work, checking headings, contrast, and link text:

Spotted: Nonconsecutive heading level use

Multiple insufficient contrast ratio violations

And unclear link texts

Looks like there’s room for improvement, although these violations are not necessarily errors.

Running Application Audits with Lighthouse

It was only recently that I was made aware of Lighthouse, a relatively new tool for running notable audits for web apps. It’s an open-source tool from Google, and can be found inside Chrome’s DevTools under the Audits tab.

Here’s what it looked like when our team tried it on a recent project (click GIF for a full view on another tab):

Running Audits with Lighthouse

The results:

Accessibility, Best Practices, and SEO Audits

Apparently we did good on accessibility, SEO, and best practices. We don’t usually test for these things, but it’s nice to know that we do enough on them. The application running on localhost wasn’t configured to run on HTTPS yet so it’s about right that we failed that audit for best practice. It’s also true that our app was designed to have small font sizes.

Performance Audit

What’s interesting to see was the dreadfully poor app performance. Throttling our page on a mobile device with 3G connection, it took at least 20 seconds before anything appeared on the page. That’s not good.

And some culprits:

Performance Audit: Opportunities for Improvement

It seems we can do better with our images and style sheets. And it also looks like our JS takes too long to boot-up. We don’t exactly do high-detail performance testing at work so it is awesome to have such a quick audit report from within the browser that notify us about such issues early. At least we’ll know the areas where there’s room for improvement right away.

There’s no excuse to not testing performance (as well as SEO, accessibility, and best practices) on a web app anymore, as far as tools are concerned.