Project timelines

I find it very difficult to estimate project timelines. Things usually take longer than I expect, and I never seem to learn. When someone asks me for a project timeline, I usually tell them that it will take somewhere between two hours and eighteen months.

As a recent example, I wanted to add a skip-to-main-content feature to a web application, because the application was growing a large block of navigation links at the top of every page. I figured this problem would have a widely-accepted solution, and that this would be a ten-minute task.

A web search quickly disabused me of that assumption. Lots of people solve this problem in different ways. I was looking for something that would

  1. work in most or all modern browsers
  2. hide the skip link until the keyboard user TABs to it
  3. not require JavaScript
  4. (most importantly) manage focus such that using the TAB key again advances focus to the next focusable element.

Here’s the implementation I ended up using. It’s still not perfect, because it won’t work in Firefox on OS X (not without some help, anyway).

So with evaluating search engine results, trying several different things, and then testing on a bunch of browsers, this ten-minute task took all morning one day.

At times like this I’m reminded of The Money Pit, a 1986 film with Tom Hanks and Shelley Long about a couple who buy a house and hire a bunch of contractors to renovate it. Every time they ask the foreman how much longer the work will take, he says, “Two weeks” (typically with derisive laughter).

So if you’re writing about someone who works in technology and need some day-to-day flavor for her, have her deal with a money pit assignment and an impatient customer.


2016 AccessU

I spent most of last week at the John Slatin AccessU conference, an annual digital accessibility conference held on the St. Edwards University campus in Austin. This post will be a somewhat haphazard collection of observations from the conference, but it may serve as sort of a followup to the web accessibility post from a couple of months ago.

There were several people at the conference with visual impairments. Two in particular stand out in my mind, as they were in several of the sessions I attended. One of them used a service animal (German Shepherd, I think), and the screen of his laptop was remarkably smudged (because, why would he care?). The other fellow used a collapsible cane, and he typically only opened his laptop far enough to get his hands on the keyboard. I’m not sure their laptop screens ever actually came on (which probably helped the battery life). The second fellow said he works part-time as an accessibility tester for Knowbility (the group that organizes the conference).

There was another fellow there who was sighted but had no arms (born that way, I presume). I didn’t see him use a computer, but I’ve seen pictures of other people who don’t have the use of their arms. They grasp a stick or pencil in their teeth and use that to type (that must take a lot of patience).

And there was a woman with diminished vision who gave a presentation demonstrating how she uses a computer. She uses a combination of a screen reader and a magnification tool. She uses the magnification tool to set the screen in reverse video mode for high contrast. Her demonstration was particularly interesting, because the computer she was using had trouble connecting to the wireless network, and then it wanted to run Windows updates. She got some help and rolled with it pretty well, but it was instructive to see what a barrier it was to be faced with poorly-presented error messages.

The third day of the conference I attended a mobile accessibility bootcamp presented by Paul J Adam, and that was really interesting. The presenter said that people with visual impairments favor iOS over Android, and it turns out that it’s by a pretty wide margin: in a July 2015 survey of over 2500 screenreader users, about 70% use an iOS device as their primary platform (compared to around 21% using Android).

As one of the exercises in the mobile accessibility bootcamp, I tried using a native app on my Android phone with the Talkback screen reader, and it was a real struggle. Some of that was my unfamiliarity with screen readers in general and Talkback in particular, but some of it was probably poor accessibility in the app (and that’s likely pretty common).

If you ever visit Austin, the St. Edwards campus is really nice (the Sorin Oak is particularly impressive), and Pinthouse Pizza has really good beer.

Computers are for everyone

Did you know that an experienced blind person can use a computer at least as efficiently as a sighted person? If you want to write about a character with a visual (or some other physical) impairment, it doesn’t preclude that character from using a computer.

Assisstive technology (AT)

There’s a whole class of technology that helps people with physical challenges use computers. This is called assistive technology (AT). A lot of AT is focused on helping people with visual impairments, and that will be the focus of this post. But AT helps lots of people: Stephen Hawking is able to use a computer just by moving his cheek.

(The following paragraphs have a couple of YouTube links. If those links no longer work, try searching for “using a screen reader” on

People with diminished vision may use a screen magnifier, software which magnifies part of the computer screen. Here’s a short video of someone using a screen magnifier.

A person with little or no vision probably uses a screen reader, software which interprets what’s on the screen. Here’s a video (around 13 minutes long) of a woman using a screen reader. She has the screen reader set to read pretty fast (the reading speed is configurable), and it can go even faster. Someone who is good at listening to a screen reader can consume content even faster than a sighted user reading it off the screen.

Web accessibility

I’m a web programmer, and there is a vast array of techniques available to me to make web pages and web applications easier to use for people with certain types of difficulties (especially visual impairments). If you hear someone talking about web accessibility, they’re probably referring to these techniques. I don’t know nearly as much about this as I wish I did, and I quickly feel overwhelmed by the staggering amount of literature on the topic.

Making web pages accessible is important work. And it’s more than just the right thing to do. There is federal legislation requiring it, and there are real consequences in failure: there have been successful (and costly) court decisions requiring Netflix, Target, and institutions of higher education to make their electronic resources available to people with disabilities.

Here are a few simple things you can do to make your web pages more useful:

  1. When you create a link, make sure that the link text is meaningful by itself. People often tell the screen reader to read out a list of a page’s links. A link that just says “click here” is worse than useless.
  2. If the thing you use to make web pages allows it, provide alt text whenever you put an image on a web page. The alternative text should give a brief description of the image. The screen reader will read the alt text aloud, and this allows a visually impaired person to know what information you wanted to convey when you included the image. (And remember that uploading an image of text, a popular way of circumventing twitter’s 140-character length limit, only works if the user can read it.)
  3. If you are writing a long page with lots of different sections, use headers and sub-headers to break up the page (like the Web accessibility header on this page). Make sure you’re using actual headers, not just large text set off by itself (you probably want to look in the styles gizmo for something like “heading level N,” where N is a number between 1 and 7). People sometimes tell the screen reader to read off the page’s headers so that the user can jump straight to the part of the page that interests them.
  4. Make sure your page has good color contrast. Light grey text on a white background is really hard to read for all kinds of people. You can use the WebAIM color contrast checker to the test the contrast between two colors.

WordPress themes

At the time of this writing, I’m hosting this blog on using their free plan. As such I’m limited in the variety of themes I can use. The theme I selected (the twenty sixteen theme) is pretty bland, but it has better accessibility than most of the nicer-looking themes (which is why I picked it). Even so, it’s not perfect: the share this buttons have poor color contrast. This blog is still an experiment. If it seems successful, I’ll probably upgrade to one of the paid plans which claim to offer greater theme customization.

So if you have a character who’s as blind as a bat, she can probably use a computer even better than some 20/20 mouth-breather.