RE: Example canvas element use - accessibility concerns

Geoffrey Sneddon wrote:
> 
> > mandated accessible fallback for <canvas>
> 
> What should be the fallback for <http://canvex.lazyilluminati.com/>?
> That's what canvas is really designed to be used for, not content, as
> is the case with bespin.
> 

Valid question.

Since one of the primary goals of <canvas> is to provide native
functionality to UAs that is currently done via proprietary tools such as
Flash and Silverlight, might we not look to what the accessibility community
has already suggested for these current technologies?  The RNIB has a good
page at: http://tinyurl.com/27you3 (Your search tool of choice will likely
also turn up numerous other resources regarding accessible Flash content)

As always, the final answer comes down to the specific implementation and
instance.  In your example, I likely would ensure that at the very minimum,
some explanatory text be inserted that outlines the nature of the
application ("this is an online game that uses keyboard controls to allow
the user to move through various rooms.  It was developed by _______ at
www.__________.com").  Due to the nature of this implementation it cannot be
consumed by some users (an admitted problem with no solution), but to say
nothing to them, to completely shut them out with not even an
acknowledgement that they exist, is offensive at the very least. There is
*always* something that can be said (via text): 
	http://www.rossettiarchive.org/docs/op76.rap.html 
	http://tinyurl.com/ataqwy 

Geoffrey, I did admit earlier that a certain amount of E&E is still required
(to avoid the "get a browser that supports frames sucker" comments of yore),
but within every velvet glove there needs to be some sort of fist, a point
that the HTML5 WG seems to shy away from every time it gets down to the
nitty-gritty.  Insisting (not simply suggesting) that a textual fallback to
all <canvas> elements must exist to be conformant sets the stage, at which
point we simply need to train the actors.  No stage however, and there is no
incentive to learn or implement - it's a glaring hole that practically
screams "we don't really care" - because if you/we *did* care, really, we'd
simply put our collective feet down and say *must*!  

And for the tired old saw re: bad accessibility data (repeated as mantra in
the @alt discussions), everything in life is in degrees - "bad
accessibility" content is still better than "no accessibility" content 99
times out of 100.

Meanwhile Rob Sayre wrote:
> 
> These discussions work better if you stick to technical issues, rather
> than making subjective claims rooted in your own value system. Debates
> on accessibility requirements for HTML are particularly prone to this
> kind of moralizing.

The problem with many of those who hold your particular view is that you
lose sight of the fact that there is a *humanistic* element of what it is we
are attempting to achieve here as well. And unlike the evolution of other
forms of communication and information transfer, this time around we have a
lot more data on, and understanding of, alternative modes of information
input and information transfer.  But *NEWSFLASH*, not all of this
understanding can be expressed as binary bits of science.  

Doing things simply because you can has a long and strong roots system in
the scientific community, but there *are* other points of view that have
equally valid contributions to make.  Sam Ruby hit the nail on the head when
he suggested that the W3C process requires a _broad_ consensus base, which
makes the humanist arguments as equally valid as the most technical jargon
you care to spew forth when it comes to finalizing this particular
specification - the next basic 'glue' for the web today and into the future.

> 
> I want the accessibility of the Web to improve,

What an inane start to your attempt to dress me down.  Is there really
anybody on these lists (of off them for that matter) that would publicly
take an opposing point of view?  Seriously?  But good for you!

> and I think I understand
> and share the morals underlying your positions. I disagree that the
> tactics you're advocating will be effective.

Then propose something that will be equally or more effective and more
palpable to your scientific sensibilities. 

We continue to come to these types of standoff because the scientific vein
of discussion insists that they have a lock on how things should be - you
are the scientists, you know best.  Yet when those of us who care about
other aspects of the issue (we empaths) ask for answers, we are derided as
not knowing enough, or accusing us of clouding the issues with morals and
value system ideals.  You want the web to be more accessible, just so long
as it doesn't make you have to do anything difficult or hard... it is way
easier to suggest that you will leave the door open, but not actually force
people to go through. It may salve your conscience to makes those
suggestions, but what happens when people choose not to take the suggestion?
The catalyst of this current thread is BeSpin... built using the current
spec that makes the accessibility suggestion, yet we now have an on-line
*text editor* that is completely and totally inaccessible to screen reading
technology - if nothing else, conclusively proving that suggestion alone
will not solve this particular problem.  That you cannot understand both the
irony and total frustration of this is beyond my comprehension. You are
entitled to your opinion, but it is an opinion, not god-given right or the
"one real truth".  Want some thoughts on how to make HTML5 more accessible?
Try doing research in areas of human motivation and outcomes management.
Try some of these:

	Nudge: Improving Decisions About Health, Wealth, and Happiness
[http://tinyurl.com/aou8w4]
	The Tipping Point: How Little Things Can Make a Big Difference
[http://tinyurl.com/anlsn3]
	Creating Contagious Commitment: Applying the Tipping Point to
Organizational Change [http://tinyurl.com/crl943]

(none of these even talk about 'code')

So: How does HTML5 ensure that when <canvas> is used, it is made accessible
to those users who cannot see?  Suggestions aside, what mechanism exists so
that specific users are not excluded?  Come up with a workable answer, any
foolproof workable answer, and we will then have a solution.  But to simply
'suggest'?  I am sorry, but the road to hell is paved with good
intentions...

> In Ian's current document, there is a short novel
> written on alternate content for the img element. 

Yes, in *Ian's* document... (sigh, it should be *our* document, but
apparently again I don't understand...).  

Let's look at Ian's short novel shall we?  He makes all kinds of
recommendations on how to use @alt, but I wonder, how much actual
user-feedback was solicited before he presumed to tell all and sundry how
best to use @alt.  Ian suggests:

"...<img src="images/parsing-model-overview.png" alt="The network
passes data to the Tokeniser stage, which passes data to the Tree
Construction stage. From there, data goes to both the DOM and to
Script Execution. Script Execution is linked to the DOM, and, using
document.write(), passes data to the Tokeniser.">..."

For real?  Hands up on this list - how many blind users really want that
much data as part of their alt text?  

*Real* user research suggests exactly the opposite:

	"In general, those with disabilities, those that use a screen reader
more, and those with higher screen reader proficiency all tended to prefer
the more brief alternative texts more than those with no disabilities, less
frequent use, and lower proficiency."
http://webaim.org/projects/screenreadersurvey/#images 

(Hey Ian, that's content/text for @longdesc.  Appropriate @alt value is
likely more along the lines of alt="visualization of the Parsing Model
Overview"... )

Joshue O Connor wrote:
> 
> The rub is when new technologies/methods of development etc gain ground
> and popularity that are not only flawed but non-inclusive from the
> start. No amount of bolt ons etc will fix the situation and
> accessibility will only ever be a 'we're working on it' situation.

Amen brother!

JF

Received on Friday, 20 February 2009 21:54:14 UTC