The folks over at WebAim have launched a second survey on screen reader use and the web. Access the blog post talking about the survey at http://webaim.org/blog/screen-reader-user-survey/ and the survey itself at http://webaim.org/projects/screenreadersurvey2/.
Working from home today I had an experience that is really a microcosm of today’s computing accessibility experiences. I’ve often thought I should take the time to do a kind of day in the life of accessibility as it were but given that I haven’t yet, 15 minutes or so will have to do. Given that I work for Microsoft and the Internet Explorer team, I’m going to toss in the disclaimer that these comments reflect my personal opinions.
I have a notebook computer that has some sort of a problem that crops up from time to time where some of the drivers necessary for speech and keyboard functionality do not load correctly at boot. I’m working with the manufacturer to understand the nature of the problem and get it fixed. When the problem happens it is pretty frustrating because it means I’m not able to use the machine until I find some sighted assistance. It is odd because if I boot the machine into Windows Safe Mode, sign in and then boot back into windows normally, everything works correctly. But booting into Safe mode and such requires sighted assistance.
Part of me finds the problem interesting in that solving the mysteries of computing like this is sometimes like being a detective tasked to solve a vexing puzzle. Still this afternoon my goal wasn’t to play riddle solver but rather to finish some work so I was a bit annoyed that the problem happened today.
I’m fortunate that I have a brother who’s often willing to answer questions or otherwise lend a hand for situations like this where he’s able. That said, assisting from 2,000 miles away isn’t the most practical thing when it requires looking at a physical computer screen.
But then again, we do live in the era of webcams, internet and what seems like 24X7 connectedness. So I figure I’ll dust off this old webcam I received when I signed up for my first high speed DSL account many years ago. I’ve used it with success for situations like this before.
Bummer dude, plugging the camera into another machine running Windows 7 gives me the sad sound that device installation failed. No drivers. But wait! There is a friendly message popping up that points to a driver download from Logitech’s web site. Happy times are here again or so I think.
I find some text on the web page that tells me to select my operating system. I hunt and hunt around for some sort of way to actually make this selection. Those familiar with web accessibility can likely guess where this is heading because I’m never able to make the actual selection.
When I run into these kinds of problems, it is back to the detective role to figure out what’s going on and where accessibility could be improved on the page in question. This is where I’ve really come to enjoy the ease that one of the features we built into IE8 has brought to such investigations. Specifically the IE8 Developer Tools have made hunting through the source code of problem web pages a much smoother experience for me.
Simply press F12 and the developer toolbar appears. I’m not going to go into all the different features available but will say that the page source is presented in a very screen reader and keyboard friendly treeview control. Better yet, a search box let’s you enter text and the tree is scrolled and expanded to the location where the search hit is located. I’ve found it makes locating the accessibility issues much faster than hunting through loads of extraneous info in full page source in a program like Notepad.
In just a couple minutes I found the issue with Logitech’s page and sent a note to the company. Who knows if it will actually make a difference. I did say after all that this was to be about 15 minutes of accessibility and well I think we all know web accessibility is more like a marathon or dare I say triathlon since those seem to be all the rage these days.