RE: Example canvas element use - accessibility concerns

Rob Sayre wrote:
> 
> The text above demonstrates a belief that the spec can force people to
> do things. I don't think it can.

Sure it can.  In many ways, that is *why* the spec exists in the first place
- to have a common 'rule' book that tells people what they must or must not
do to achieve X result.  It's not a guide, it's a specification.  I want the
specification to ensure that accessibility *happens*, that it is not simply
a 'suggestion', and every velvet glove needs an iron fist.  And unlike some
others, I have no issue being draconian about it.  It does not have to be
identical, it needs to be equivalent, and to say that this is not possible
is narrow minded and unimaginative.

Telling content authors that a workable fallback solution *must* exist for
<canvas> would have either stopped BeSpin in its tracks, or challenged its
creators to solve the problem before launching the application.  Being an
empath, and having belief in the ingenuity of 'developers', I'm sure if they
*had* to find a solution, they would.  (But conversely, if it is only a
suggestions... why that simply gets in the way of the rush to market...
we'll log it as a bug and get to it in the next iteration, or the one after
that, or in v. 17... Ya, I clearly don't understand the development
community or Web 2.0...)

>  I want the spec to accurately reflect
> reality,

...and it currently does: <canvas> today can be used with zero fallback
content and it renders on screen.  It also allows to completely shuts out a
specific user-group based upon their disability and/or use of a specific
technology (screen readers).  It empowers the ability to completely fail any
accessibility goal of ensuring that those users get some form of content,
even if it is not the primarily intended or delivered functionality. That is
the reality, fostered (promoted?) by the current spec.  I say then that the
spec is broken, and it is at odds with *your* stated goal of wanting to make
the web a more accessible place.  That's what you said you want. 

>  and that is a goal directly at odds with making rules that
> will
> be ignored. I hope you can at least understand my position, though you
> may violently disagree.

I do. And I do.  We both want a more accessible web, I'm just willing to
fight harder to get it, whilst you are prepared to allow a certain amount of
status quo rule the day.  I understand.  You also have the
engineer/scientist perspective that predominates these discussions, while I
spend my days selling various shades of gray.  That's OK too.

> 
> As for not doing things that are difficult or hard, I can't claim to be
> an expert in accessibility technologies, but I can point to a piece of
> code that I am responsible for
> 
> <http://mxr.mozilla.org/mozilla-
> central/source/toolkit/components/feeds/src/FeedProcessor.js#1202>

Good!  I wrote this:
http://html4all.org/pipermail/list_html4all.org/2008-April/000797.html  
 in April 2008

"... If we are to relax the mandatory requirement for @alt in the next
generation
Markup Language, then we must also explicitly note and provide as many
/other/ ways of providing this information as possible:

 @alt and/or @longdesc
 @alt and/or @legend
 @alt and/or @id
 @alt and/or @figure
 @alt and/or @caption
 @alt and/or (ARIA Variants suggested)
 @alt and/or (suggested reserved values)
 @alt and/or (open to further suggestions)

With these (and perhaps other) means/tools at their disposal, I cannot think
of *any* scenario where one of these options could not be implemented,
either by the end (human) author or at the "program" level (WYSIWYG/file
upload site/etc.). Having *any* of the above methods of expanding upon the
visual-only content present would thus render the <img> element conformant."

which looks surprisingly like Option F of this:
http://lists.w3.org/Archives/Public/public-html/2008Aug/0759.html :

"... So. We need another option.

Are there cases where the image is lacking good alt text that wouldn't be 
covered by one of the following?:

 - title="" attribute on the <img> itself
 - <legend> of the <figure> that contains the <img>
 - heading of the section that contains the <img>

F. We could say that for these "key content without alt text" cases, we 
have the alt="" attribute omitted, but there must be at least one of the 
above, and the first of the above that is present must include sufficient 
information to orient the user."

where Ian then concludes with:
"I've put proposal F into the spec." 


(However, he did not take to heart my other suggestion: " ...I would then
suggest that any other HTML 5 implementation of <img> which lacks *any* of
the provided means of "equivalent alternatives" be non-conformant, and
further suggest that this result with the most drastic of consequences:
non-rendering.  (Give out more rope, but increase the risk of hanging
oneself)" - this of course being 'too radical' for the engineers [all the
while forgetting that this is in effect what non-sighted users would be
getting, but, oh well, too bad, so sad...])

> 
> That's good, substantive feedback. If it's accurate, it looks like
> there are some spec bugs there. The discussion is working well here.
> 

Then leave your opinions of my morals and belief systems out of the
discussion.  Tell the web accessibility community your proposal on how to
fill the gap and solve the problem, and stop telling me or any other of us
that we just cloud the issue with our morality and beliefs.  They have their
place in the larger discussion, whether you agree or not.

JF

Received on Saturday, 21 February 2009 02:58:18 UTC