- 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 UTC