RE: html5 editor responds to Canvas accessibility related bugs

On Sun, 26 Sep 2010, Richard Schwerdtfeger wrote:
> 
> Aside from individuals who care that accessibility is the right thing to 
> do, companies that sell product to governments (federal, state, local, 
> and international) are required to sell accessible IT. Furthermore, the 
> U.S. Dept. of Justice recently stated that their interpretation of the 
> ADA is that it applies to all public web sites much the same way that 
> companies are required to put wheel chair ramps in place so that 
> mobility impaired people can access buildings. They do this so that all 
> people can participate in society regardless of ability and because 
> there are people and companies out there who see accessibility as a cost 
> and if they were required to do it to sell to a customer would not. What 
> you are hearing is that both IBM and Microsoft believe we need the tools 
> to do the job as both companies have a long legacy of supporting people 
> with disabilities as it is the right thing to do and because our 
> customers demand accessible products. They also demand that we innovate 
> and possibly use canvas in ways you would not like. Also, we may buy an 
> innovative startup some day where, in most cases, accessibility is low 
> in priority and seldom addressed. Our job in accessibility is to allow 
> authors to innovate yet be given the tools to make the results 
> accessible. Frankly, it is a bit of a culture shock when they get 
> absorbed that they now have to support a whole host of requirements they 
> did not have to before: IPV6, internationalization, accessibility, 
> security, privacy, etc.

I completely agree and understand. My point is that the way to make a 
canvas editor accessible is not to bolt on some API to report the caret 
and selection position. It's to rip out the canvas and do it the right way 
with contentEditable or <textarea>. As a side-effect, you will 
simultaneously also achieve better internationalisation (since it's 
unlikely the canvas editor will have bidi support), better features (since 
it's unlikely the canvas editor will have platform-native drag-and-drop, 
spell-checking, selection-to-speech, direct-clipboard access, search 
integration, and all manner of other features present in browsers these 
days), and better reliability (since browsers are much more likely to have 
been thoroughly debugged than a small team's canvas editor).


> A good analogy is seat belts. Many states have seat belt laws to protect 
> people from themselves and to reduce the insurance liability costs. All 
> cars have seat belts - a tool to meet the law and to protect yourself. 
> You have the choice to ignore the seat belt warning and clip the belt 
> behind your back and continue on your merry way. That is your choice. If 
> a person wants to assume the risk of injury and risk of getting a ticket 
> who are we to argue?

If clipping the belt behind your back is using a canvas editor, and 
clipping it in front is doing it right, then providing a caret/selection 
API is like providing a belt that you can tie to the belt behind your back 
and then wrap around yourself. Nobody sells that, it would be stupid. 
Instead, if people want to be safe (if people want to make an accessible 
editor) they should unclip the belt from behind them, and clip it in front 
of them (they should throw out the idea of using canvas, and use the 
native editing features). That's the law (both for belts, and for Web 
pages -- unless we provide an API, in which case we'll be saying you can 
use canvas, even though we all agree that's a bad idea).

Let's not provide a belt to tie to the belt behind one's back.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 September 2010 02:40:02 UTC