I am privileged. I am able to navigate the web in all it’s glory, with all the amazing animations, crazy stuff happening on scrolls, great videos and the latest style for input fields.
Unfortunately, not everyone can.
A person can have a hard time using your product for a multitude of reasons, from being blind to having a motor disability or even being new to technology.
Research is key at this point. How many users do you have? How many of them are not able to use your site? Is it an internal tool, or a product for the masses?
When in doubt don’t make assumptions. Try to be as inclusive as possible and feasible in your time frame.
The stage of the product is also a factor in this. Building a prototype, an MVP or improving an area of a website used by millions of people daily, have very different constraints and also very different amounts of information available about the target audience. In my opinion, there is no excuse for at least having this in mind in the conceptual stage of your product.
In the words of University of Cambridge’s Engineering Design Centre:
Every design decision has the potential to include or exclude customers. Inclusive design emphasizes the contribution that understanding user diversity makes to informing these decisions. User diversity covers variation in capabilities, needs, and aspirations.
Inclusive and Universal Design are often used interchangeably, and you’ll see it referred to as the same thing on your internet searches. Some people, such as Brian Kelly defend that Inclusive is a better name than Universal, which:
leads people to believe that a single universal solution is possible or, indeed desirable.
You can read WCAG’s guidelines and implement them all in all of your web products.
Coming back to reality, that is both infeasible and undesirable, since it is a massive undertaking just to read it, and possibly a bigger one to implement it.
There are a lot of seemly small things that you can start doing to improve the accessibility of your website. Here’s a few, from Cameron Cundiff’s talk at the NYC Accessibility & Inclusive Design Meet-up:
There are a lot more things you can do, but this is definitely a good start.
There are already some good tools that you can use to help test, manually and automatically, your websites for accessibility.
Lea Verou has a great website for testing the contrast of colors according to WCAG 2.0.
Google Chrome as an add-on for the developer tools that allows you to inspect an element and test the color contrast, among other things.
With the add-on I have just mentioned, you can perform and audit on accessibility.
A better tool for this, in my opinion, is Tenon by Karl Groves and his team. You get really detailed reports on how accessible your website is, and recommendations on how to fix issues. I highly recommend it (it will be a paid service, but free for OSS).
Let’s face it, if you don’t use a screen reader everyday, you won’t really know how it feels to use your website with one. It doesn’t hurt to try, though.
If you are in a Mac, you have VoiceOver out of the box, trigger it with cmd + F5. This should be good enough to give you a rough idea of how you are doing.
It’s probably a good idea to pay some users who do use them everyday and do usability tests with them.
If you are using Ruby, you can automate some of these accessibility tests, using a custom webdriver for your integration tests. This is made easy with capybara-accessible, there are literally no changes required to your tests, just the setup.
Here is some common issues and interesting techniques you might want to use.
Breadcrumbs at the top of the page are common, also most users will have no problems understanding what they are. A user with a screen reader, however, will have to go through some of the breadcrumb links to know where they are. You can easily add context with a hidden text before the links, for instance, “You are here:”.
A great technique for providing a link to skip to the main content of the site, for both screen reader and keyboard only users, can be found in the WebAIM website.
A common mistake/misconception on the web, is to use headings (
h2, …) for
style, instead of structure. Screen readers use headings as the page outline,
and it’s the primary way for finding information
by their users and therefore is very important not to mess up. An
h1 should be
a main title, and if there is a subtitle it should be an
h2 and a subtitle
inside of that an
h3 and so forth.
HTML5 introduces a new document outline algorithm, alongside with sectioning
content elements such as
article. Sematically it is now valid to
h1 inside such an element, and it should be nested under an outer
h1. Take into account, though, that screen readers will probably disregard this
new algorithm entirely and thus, it is recommended
not to use it.
I am privileged, but I shouldn’t be. Everyone should be able to enjoy all of the web’s content with minimum restrictions, obvious ones aside.
As web developers and designers it is our job to make it so. Go and make the web more accessible, because accessibility matters!