WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Assistive Technologies / ScreenReaders&GoogleAnalytics

for

From: Tim Harshbarger
Date: Feb 22, 2014 2:05PM

I would suggest that you ask a couple questions. First, what would you do differently if you knew a user was utilizing assistive technology to access your site? Second, what prevents you from integrating that functionality/accessibility into your "mainstream" design?

If you are newer to accessibility, it is understandable that you might find creating a separate interface to be alluring. When you first start trying to design and develop with accessibility in mind, every design and development decision can seem very challenging. As you develop experience with accessibility, you will find that most of the design and development decisions are truthfully very easy.

While there are techniques that can make the creation and maintenance of separate views that provide the same functionality easier to do, it still increases your design, development, and testing time. So, short term it might seem like a great idea, but long term it will likely cost you more. So, you will want to seriously consider if you want to take on the long term costs.

If you find yourself facing a design/development decision where creating a separate interface seems the only option, I would offer 2 suggestions. First, consider seriously redesigning the interface. Second, if you have no other choice but to create the separate design, then offer the user the choice of which one to use.

There really isn't any great way to figure out who is using which AT and which version of the AT. So, personalization is your best bet. By personalization, I mean either adding functionality to the page that allows the user to switch the view on that page or provide a place on the site where the user can optimize personalization's for their own user experience.

If you go the personalization route, I am going to recommend that you avoid labelling personalization options with terms like "Screen Reader" or "Blind" or "Deaf" or whatever. Instead label them with the functionality they provide. One of the secrets of accessibility is that it isn't about disability but about functionality. Providing close captions for a video isn't just about people who are deaf, but about people who have problems perceiving or understanding the audio track of a video. By labelling these options by the functionality you are providing, you increase the likelihood they will be used by people who can benefit from them.

I have my own strong opinions on whether or not AT usage should be trackable...however, I've not come across any compelling case for developing that ability. So, until someone can make a strong case for why tracking AT usage would be beneficial to the end user's experience, I suspect it really seems like functionality that has no real value.

Tim