Accessibility: 3 simple steps

Did you know that at least every fourth American is a person with a disability? Or, that globally, there are at least a billion people with disabilities? And, although there is no data available regarding the number of programmers with disabilities, the estimates show that one in every 200 developers is blind. Why is it then that so many developers are still unaware of the fact that their products are inaccessible to many people? Also, wasn’t the accessibility of information one of the key values of the Internet? In the words of Molly E. Holzschlag from Open Society and Technology Initiative:

Access is a primary structural pillar of the web as it was imagined… and with education and encouragement can, in fact, happen if we all start accepting that this is more than a responsibility; we are all accountable.

After the first month of Flatiron School’s bootcamp, I realized that designing for accessibility is really simple. Here are a few tips everyone can implement to make the web more accessible.

1. Write your code well.

Have you ever been to a foreign country in a small town with many small alleys and happened to have no map? Or, worse, your phone died and that was it for Google Maps? I imagine that this feeling of disorientation and confusion might compare to what people experience reviewing badly-written program. (“What does this variable_a1 do? And variable_aa1?”) Now imagine, that on top of that, there are programmers who use a screen reader, who are tired, who have attention deficits, or who just don’t speak English as their first language.

Here are a few tricks that will enable you to come across as a more responsible programmer:

• name your variables and functions to represent what they actually do — that would be a favor to your future self as well who for sure won’t remember your thought process here and now — see picture below;
• add comments because why not to guide others through the jungle of your mind?
• remember about indentation so that it is easy to understand where one thing ends and another begins;
• food for thought: do you really need to show off with fancy one-liners? One-liners look great and I myself prefer using, for instance, Ruby’s .map(&:name) than its longer version. However, in some cases, the fancy one-liner cuts the number of lines but increases the amount of time some people will need to make sense of what just happened in code.

For instance, take a look at these pictures below. The pictures show a solution to one of the Flatiron School’s labs. The picture on the left comes from the official solution branch provided by the school. It includes one-liner methods, as well as variables named without an underscore, which makes it more difficult to read (and perhaps unintelligible for screen readers). The screenshot on the right comes from a GitHub of one of my fellow students, Chris Ogilvy. It features variables named in a clean way and two comments on what’s happening in the code. Whenever stuck for a longer time on a bootcamp lab or having finished a troublesome one, I check Chris’ solutions because I know it will be easy to understand his code.

The picture features two screenshots from Github. The screenshot on the left comes from the Flatiron School’s GitHub and the screenshot on the right from Chris Ogilvy’s solution to the problem.

2. Write readable documentation

Remember that you are writing for a global community, as well as for people who may be tired, stressed, or with a disability. Don’t approach documentation as a testament to your college major in English. Believe it or not, such consideration is already takin place in IT. For instance, Google provides its developers with writing conventions to make their documentation more accessible. Quick tips:

• choose plain English;
• write short sentences;
• be concise and clear;
• avoid passive voice and favor active voice;
• don’t use jargon and culture-specific references.

And, if you want to make extra sure that your text will be understood by a wide audience, you can use the help of the free websites like the Hemingway Project that will scan your text and tell how and where you could do better. See in the below gif how simple this is:

This gif features a screen recording of Hemingway App assessing the accessibility of the Giphy API documentation.

3. Use HTML intentionally and correctly

Have you ever tried scraping in Ruby a website whose developers approached HTML tags with a lot of liberty? For one of our group assignments, we wanted to scrape Ruby-Docs and after this experience, I feel sorry for people who navigate the web through a screen reader. Screen readers locate the tags such as <h1> or <label> to help its user orient themselves on the website. If you don’t treat the tags seriously, not only does that show that you didn’t do your Intro to HTML homework but also that your website will be inaccessible for many visitors. Here are quick tips on how to improve the accessibility while working on front-end:

• use correct tags and don’t skip levels (after h1 comes h2, etc.); be intentional about how you use them: h1 is reserved typically for the title of the website or subpages;
• if you include a link in the text, be as descriptive as you can — instead of writing, “if you want to know more about me, click here”, say “if you want to know more about me, visit About Me subpage” (imagine trying to choose the correct link through the screen reader going through a list of “click here” links);
• why would you ever create pop-ups that don’t close automatically? Screen readers can’t close them!
• be aware of the colors;
• provide alt-descriptions for your pictures — describe what you see in the picture; this will also benefit people who switched off pictures for instance, due to data limitations; moreover, this is also how search engine optimization (SEO) makes sense of your website!
• bonus: remember that captcha is impossible to pass with a screen reader! Here are some alternatives: http://webaim.org/blog/spam_free_accessible_forms/

BONUS: Check your website with a screen reader

This may come as surprise so brace yourself: you, too, have access to a screen reader! Command + F5 and you’ve activated Mac’s VoiceOver! And if you’re using Windows, you can download NVDA for free. Give yourself the experience of your website through a screen reader and learn from it.

For instance, having learned that not all screen readers can navigate Command Line Interfaces, my team and I created an audio version of the app — you can check it on my GitHub. All it took was just three helper methods and improving the general logic of the app. We used the standard Mac VoiceOver, chose two voices for our app (Samantha and Alex) and gave Samantha the opportunity to speak at two speeds (standard and slower, or -r 100). See below how we made our CLI speak:

The picture features a code screenshot with the helper functions used for the accessibility version of our CLI.

If you are interested in the subject of accessibility, check this free Udacity course.