Accessibility as Performance

Velocity 2016

Your site isn't accessible when it hasn't loaded, but is it accessible once it has? Are you thrashing the main UI thread, impeding user interaction? Did you disable zooming, making your site illegible to many? To make your clients happy, your site must be accessible: it has to make it onto to device quickly, has to work once there, and has to have good usability no matter the current physical and cognitive status of your user.

The goal of web performance is to make your customers happy. If your customers can't access your site because it's too slow, they'll leave your site and become someone else’s customers instead of yours. Similarly, even if your site does load quickly but is not accessible, it will result in your visitors being unhappy, potentially losing them as potential customer for life.

The common statistic is 19% of the US population has a disability (pdf). When it comes to web accessibility, this statistic is irrelevant. Some of the disabilities making up that 19% don’t impact web usage ability at all, whereas traits that aren't considered a "disability" by research respondents impact how users interact with their connected devices. We are all at times differently abled.

The 19% includes Americans who are paraplegic, visually impaired, hard of hearing, etc., but does not include users who temporarily can't use a mouse, see the screen, use audio or completely focus on the task at hand. The 81% of us who are not "disabled" are only temporarily abled. Almost everyone will experience some difficulty experiencing the web in some way, even just temporarily: whether it's needing reading glasses, experiencing carpal tunnel pain, or even just breaking a headset and having to go without audio.

My conference topic for Velocity Santa Clara this year is accessibility as performance. Performance improves customer satisfaction. Using simple, semantic markup instead of relying on résumé-driven development (RDD), reduces bloat, improving performance. Semantic markup improves accessibility. In my Velocity talk, I show how simplifying your code base to semantic markup improves accessibility while improving performance. I cover a use case in which I reduced a site down from 55,000 lines of JavaScript to less than 1,000 lines by removing all dependencies and using well-thought-out, simple, semantic HTML features. I re-coded a single page web app using semantic HTML, reducing the file’s size and download time, removed the UI thread thrashing caused by the over-reliance on JavaScript frameworks, and in the process eliminated the queue of accessibility bugs.

In the process I came up with three innovative, semantic, accessible plug in replacements. I demonstrate how I created a performant, accessible input masking script by using valid, accessible HTML5 and a few lines of JavaScript. I also demonstrate Merry-Go-Round, an accessible replacement for carousel script frameworks and plug-ins that requires less than 100 lines of JavaScript. I also demonstrate a styleable select replacement that still doesn’t have a name or a Github repository.

It has taken a few years to convince developers, but performance has finally become a priority. Why? Because performance has been proven to impact the bottom line: it impacts the corporate pocket book. You know what else impacts the corporate pocketbook? A site that is not usable because it isn't accessible.

We've convinced the CTO that the dev team needs to care about how fast the site loads: why are we having so much difficulty convincing the CTO to also care about customers with disabilities? When your site has bad UX because it's too slow, because it's inaccessible or because it simply has bad user experience, your customers will become your competitors customers. Don't let that happen.

Learn more about Instart Logic: