W3C home > Mailing lists > Public > public-html@w3.org > February 2009

RE: Example canvas element use - accessibility concerns

From: John Foliot - WATS.ca <foliot@wats.ca>
Date: Sat, 21 Feb 2009 10:56:08 -0800
To: "'Geoffrey Sneddon'" <foolistbar@googlemail.com>
Cc: "'Rob Sayre'" <rsayre@mozilla.com>, "'HTML WG'" <public-html@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Message-ID: <076a01c99456$0eb34de0$2c19e9a0$@ca>
Geoffrey Sneddon wrote:

> 95% of the web is invalid. Why is HTML 5 going to suddenly start to
> make people create valid (yet alone conforming) documents?

...and so the solution is to lower the bar?  Ya, that works.

You know, back in the time when IE started switching back and forth
into/from quirks mode based upon DTD, a lot of developers stood up and took
notice. Rightly or wrongly, Microsoft set a bar to be met, and for the most
part developers rose to the challenge and more standards based code emerged
as a result (movements like WaSP and voices like Zeldman's also helped push
the issue, and inform/educate the masses).  Today, we have a class of web
developers who are way more standards aware, and who work towards meeting
these standards.

HTML5 has the opportunity to raise the bar as well.  We need to ingrain and
mandate accessible behaviors to all of the new and wonderful ideas that
HTML5 wants to advance.  The ideas are great (really, <canvas> is a great
idea) but as we introduce these new ideas, and develop the proofs of
concepts (like BeSpin), glaring holes need be plugged (like should vs. must)
so that the ideas deliver not only on the technical level, but on the larger
moral level as well - and whether readers of this agree that there is a
moral responsibility here or not, there are sufficient numbers who believe
that it is true that their voices cannot simply be drowned out.

The BeSpin example illustrates that there is a problem: a technical proof of
concept was 'launched' that clearly does not meet WAI expectations or
considerations.  It is clearly broken and non-functional for the visually
impaired, and there is no fallback mechanism in place to address the
fundamental rights of those members of society.  This can eventually be a
business problem, as any entity that is mandated by law to respect all human
rights will not be able to use any technology that is using, or is based
upon, this initial PoC.  Google is trying very hard to sell their bundled
suite of online applications to Universities and other similar institutions,
and are having a tough haul of it because many of the bundled apps do not
meet even the bare-bones Section 508 requirements (GoogleDocs!); these
institutions are becoming increasingly fearful that they will be tapped as
breaking the law and so are avoiding any possibility of 'issue'. (When a
sales rep from Google was queried about this by me, his response was "we
know we have a problem" - great!)
(whistling past the graveyard? See: http://www.dralegal.org/)

The current draft left a hole in the spec which sadly is the exploit.  Oh,
the developers have "some thoughts" about accessibility, but because it was
not mandated, only suggested, they were able to continue to move forward and
launch a flawed tool - seriously flawed.  However, if the spec had been more
stringent in its requirement to provide alternative data to non-visual
'consumers', this flaw would never have seen the light of day, as it would
have been part of the original design draft for BeSpin to address this
issue.  Thus the spec would set the condition to be met to ensure success
*on all levels*. 

Maybe my suggestion of changing 'should' to 'must' is too simplistic - what
do I know?  But until such time as this fundamental issue is resolved,
<canvas> now has a pall cast upon it that will continue to haunt it.  So fix
it now, or deal with it later.

Received on Saturday, 21 February 2009 18:56:51 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:43 UTC