W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2012

Re: UPDATE suggested alternatives to accessible version

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Mon, 20 Feb 2012 16:40:24 -0600
To: w3c-wai-ig@w3.org
Message-ID: <OF741945CC.4083F060-ON862579AA.00693261-862579AA.007C8CD4@us.ibm.com>
> . . . you can practice UD and still have a product that only 30% can 
use. 
> Design a fighter pilot cockpit. 

Maybe a more simple example will illustrate: a kiosk or even more simple - 
a so called hand help remote control for a T.V.:
some folks want lots of small buttons that can do everything, some just 
want a CC button, some just want a DV button, some are confused with 
either button.  Some want larger buttons.  How many larger buttons?  how 
large is larger - 3 mm, 5 mm, 10 mm ?  OK, so then we get into having more 
than one remote control, a small one, a medium size one, and a larger one. 
 And then we need one with larger yellow on black buttons, and so it goes. 
 btw, tablets and smart phone as 'configurable' remote controls are a 
promising trend here.  Should the TV manufacture just publish its 
interface specs and let the "remote control" developers of the world make 
a variety of them (or apps) for sale?  What happens when government 
regulations get in the way trying to help and say things like the service 
provider (not the manufacturer) must provide a remote upon request? which 
remote? which app (do I even have a smart phone or tablet?) how many 
varieties of remote controls? for free or extra costs?  and it goes one 
and on.  And this is a simple hand held remote control scenario.  My point 
only being that we don't need a complex fighter pilot cockpit to 
illustrate the point about the difficulty of Universal Design. 

Often we on this interest group list are coming from the "PC/desktop or 
laptop with a web browser" paradigm where there is lots of hardware, 
operating system platform, browser settings, and end user settings before 
we ever get into add-on assistive technology software and hardware (e.g. 
switches).  In the more constrained world of hand held remote controls, 
public kiosks (such as ticket vending machines), and smart phones we often 
have to make more trade offs - or more importantly - decide where is best 
to place to give the requirement, such as with the web site itself 
creating a link to an alternative page and how best to label that link 
discussion we are having here.. 

Others have replied but I think it would be best to select a "phrase" that 
actually meant something specific, instead of trying to define a 
"universal term". 

A "universal term" falls into the same problems as "universal design" when 
trying to create a "one phrase" fits all scenarios.  For example, if the 
issue for requiring an alternative site or page is related to not working 
in older browsers - could it say "Internet Explorer 6 users click here" or 
something like "Mobile phone users click here" or maybe, but probably not 
get too technical with phrases like "non JavaScript user click here".  I 
think "Basic version" is making a lot of progress towards a meaning 
something specific in some situations.  My point being to address the 
alternative link text in terms that make sense to why you have the 
alternative page or site.  Of course that is AFTER you add the code that 
helps automatically get the user's browser to the better supported page if 
possible.  But, it actually sounds like it is often a non disability issue 
and more of a technology support issue that could be solved by upgrading 
the technology the user has. 

If it is a problem with "not sufficiently supported by ATs," then perhaps 
spend your time fixing the AT so all users of the AT can benefit instead 
trying to put the burden on the site developers to come up with an 
alternative.  I find it interesting how many screen readers like using the 
mobile versions of some social media apps, and btw, they didn't click on 
an "accessible (or basic) version click here" link to get there, the end 
user got some awareness about it.  Users and care givers have some stake 
and responsibility in here as well, its not all on the web site to solve 
the problems.  btw, I don't agree with web site all coming up with their 
own solutions for larger fonts with confusing icons and text links for 
larger fonts, or different contrast schemes - again that is better solved 
with end user awareness training and browser and AT support.

And I'm curious about the original comment on "the other extreme, an 
application that is to have a short web-life is dependent on a legacy 
system that it is difficult or impossible to make sufficiently 
accessible."  I think the clue to that answer is in completing the rest of 
the sentence; sufficiently accessible to whom using what?    So, how short 
is "short web life?  Is it only a screen reader version x on platform y 
access issue?  Is it a cognitive issue that really requires a total 
re-design or alternative to the site? or is it really a fundamental 
alteration - meaning impossible?

Another suggestion following the thread to provide more awareness training 
to end users is to look at the BBC's "My Web My Way - Making the web 
easier to use" mini-site.  The link to get here from the main home page is 
"Accessibility Help", but the problem is with the user realizing that they 
in fact need to click the link to get there in the first place - correct? 
I believe the term "Help" is more helpful in conjunction with 
"accessibility" instead of "accessibility" by itself.  And I would like to 
see studies that said "Help" by itself would be any better or worse. 
Again, this is often just a "Learn-ability" or first time set-up problem, 
and once the users is helped with set up and configuration and orientation 
there is no longer a problem.  In other words - accessibility does not 
remove the need to learn something or to learn how to configure something 
for easier use.  Sure we all want to reduce the time it takes to learn 
something, and the training and assistance needs to be made accessible 
itself too, but there are still two fundamental requirements - easy to 
learn and accessible to use.

Regards,
Phill Jenkins, 
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
http://www.facebook.com/IBMAccessibility
http://twitter.com/IBMAccess
http://www.linkedin.com/in/philljenkins
Received on Monday, 20 February 2012 22:41:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 February 2012 22:41:14 GMT