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

RE: Thoughts towards an accessible <canvas>

From: Jon Gunderson <jongund@illinois.edu>
Date: Wed, 18 Mar 2009 08:34:56 -0500 (CDT)
To: "John Foliot" <jfoliot@stanford.edu>, "'richarduserite'" <richard@userite.com>, "'John Foliot - WATS.ca'" <foliot@wats.ca>, "'Wai-Ig'" <w3c-wai-ig@w3.org>, wai-xtech@w3.org, "'HTMLWG'" <public-html@w3.org>
Cc: "'WebAIM Discussion List'" <webaim-forum@list.webaim.org>, "'Gawds_Discuss'" <gawds_discuss@yahoogroups.com>
Message-Id: <20090318083456.BQK12925@expms1.cites.uiuc.edu>
It would be useful if browsers had an accessibility mode that would allow web developers to easily view the accessibility of the content of a web page and at least have keyboard support for navigation to headings (h1-h6) and the new ARIA landmark roles.

Accessibility mode would have at least the following features:

1. Render alternatives in place of non-text content
2. Remove CSS and tables that are being used for layout

This would provide at least one level of visualization of the content to people using assistive technologies.

The Opera Browser does have built-in support for header navigation and they do make it easy to switch between many different renderings for web developers to view their content for many devices and users, including the features above.


---- Original message ----
>Date: Tue, 17 Mar 2009 09:45:41 -0700 (PDT)
>From: "John Foliot" <jfoliot@stanford.edu>  
>Subject: RE: Thoughts towards an accessible <canvas>  
>To: "'richarduserite'" <richard@userite.com>, "'John Foliot - WATS.ca'" <foliot@wats.ca>, "'Wai-Ig'" <w3c-wai-ig@w3.org>, <wai-xtech@w3.org>, "'HTMLWG'" <public-html@w3.org>
>Cc: "'WebAIM Discussion List'" <webaim-forum@list.webaim.org>, "'Gawds_Discuss'" <gawds_discuss@yahoogroups.com>
>Richarduserite wrote:
>> However I am not so sure about your idea of not rendering non-
>> conforming content
>> "Finally, I propose that any instance of <canvas> that lacks at a
>> minimum
>> the 2 proposed mandatory values be non-conformant and not render on
>> screen."
>> Would you apply the same rules all non-text content such as images?
>Actually, yes, I have proposed this form of draconian response before
>It's about consequences: until such time as there are real consequences
>for slack developers/tools that allows content to exist that is
>incomplete, then there will be content that is incomplete - it's a simple
>as that.  Why would <img src="path..." /> be any more complete than <img
>alt="Photo of a leprechaun" />?  I mean, clearly, anyone processing that
>info in their user-agent will 'get' the intent of the author, right?  Yet
>today, the first example will render in the browser, the second delivers a
>'fail'.  Ergo (to me) there is a problem of inequity here that must be
>addressed - if it fails for some, it should fail for all.
>> The crucial thing is that the users software (browser, screen reader,
>> etc.)
>> is able to render the appropriate alternative (if it exists). And for
>> this
>> to happen you are right that the software developers as well as web
>> authors
>> need to be given a definitive, unambigous, set of guidelines. But I
>> don't
>> think you can ask Microsoft etc to create browser that refuse to
>> display any
>> content that is not fully accessible.
>I get that.  However, it does not change my thoughts, it only suggests
>that I will likely not get what I believe should be given.  But sometimes
>an extreme position must be articulated, if for no other reason than to
>set the outside bars far enough that the compromise (middle) position
>remains a win most of the time. Shooting for the stars will hopefully
>deliver the moon.
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/
Received on Wednesday, 18 March 2009 13:36:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:43 UTC