E-mail List Archives
Thread: Re: Thoughts towards an accessible <canvas>
Number of posts in this thread: 7 (In chronological order)
From: John Foliot
Date: Tue, Mar 17 2009 10:50AM
Subject: Re: Thoughts towards an accessible <canvas>
No previous message | Next message →
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
(http://tinyurl.com/dgrd8b).
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.
JF
From: Jon Gunderson
Date: Wed, Mar 18 2009 7:40AM
Subject: Re: Thoughts towards an accessible <canvas>
← Previous message | Next message →
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.
Jon
---- Original message ----
>Date: Tue, 17 Mar 2009 09:45:41 -0700 (PDT)
>From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
>Subject: RE: Thoughts towards an accessible <canvas>
>To: "'richarduserite'" < = EMAIL ADDRESS REMOVED = >, "'John Foliot - WATS.ca'" < = EMAIL ADDRESS REMOVED = >, "'Wai-Ig'" < = EMAIL ADDRESS REMOVED = >, < = EMAIL ADDRESS REMOVED = >, "'HTMLWG'" < = EMAIL ADDRESS REMOVED = >
>Cc: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >, "'Gawds_Discuss'" < = EMAIL ADDRESS REMOVED = >
>
>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
>(http://tinyurl.com/dgrd8b).
>
>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.
>
>JF
>
>
>
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/
From: Simius Puer
Date: Wed, Mar 18 2009 8:00AM
Subject: Re: Thoughts towards an accessible <canvas>
← Previous message | Next message →
Hi Jon
Extensions do exist for many browsers. The most thorough one that I could
not live without is the web developer toolbar for Firefox [
https://addons.mozilla.org/en-US/firefox/addon/60]. Something similar
exists for Opera [http://operawiki.info/WebDevToolbar] but I've not tried
that yet.
You can do stuff like:
- disable cache/Java/JavaScript/Cookies etc
- disable styles at embedded/inline/external/all level
- disable images/show alt tags
- display abbreviations/accesskeys/title attributes
...this is only a fraction of what it will help you do.
Not sure why you would want to remove tables used for layout as that might
give you a false impression of how assistive technologies would deal with
the page. Best to use the actual AT software to test for that. Advice
regarding such tables would be to remove them anyway.
Hope that helps
From: Jon Gunderson
Date: Thu, Mar 19 2009 7:30AM
Subject: Re: Thoughts towards an accessible <canvas>
← Previous message | Next message →
Are the ARIA properties ARIA-LABELEDBY and ARIA-DESCRIBEDBY going to be implemented in HTML5?
Jon
---- Original message ----
>Date: Wed, 18 Mar 2009 21:44:05 +0000
>From: Alasdair King < = EMAIL ADDRESS REMOVED = >
>Subject: Re: Thoughts towards an accessible <canvas>
>To: Jon Gunderson < = EMAIL ADDRESS REMOVED = >
>Cc: John Foliot < = EMAIL ADDRESS REMOVED = >, richarduserite < = EMAIL ADDRESS REMOVED = >, "John Foliot - WATS.ca" < = EMAIL ADDRESS REMOVED = >, Wai-Ig < = EMAIL ADDRESS REMOVED = >, = EMAIL ADDRESS REMOVED = , HTMLWG < = EMAIL ADDRESS REMOVED = >, WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >, Gawds_Discuss < = EMAIL ADDRESS REMOVED = >
>
>John Foliot:
>1 Could we perhaps have a way to define (e.g. meta tag) that the
>canvas shouldn't be rendered to some set of users, like alt="" does
>now?
>2 The only other content is likely be be a brief text string, but this
>might be extended to a link to some equivalent data source, like a
>simplified-HTML version of the content.
>
>I don't think you're going to get anything else put in there, based on
>my experience of writing a web browser and looking at the contents of
>things like LONGDESC nodes.
>
>Jon Gunderson:
>May I pitch this to you?
>http://www.webbie.org.uk/webbiefordesigners.htm
>Another alternative is to install NVDA and try the page out in Firefox
>with your monitor turned off.
>
>Cheers,
>Alasdair King
>WebbIE
>http://www.webbie.org.uk
>
>On Wed, Mar 18, 2009 at 1:34 PM, Jon Gunderson < = EMAIL ADDRESS REMOVED = > wrote:
>> 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.
>>
>> Jon
>>
>> ---- Original message ----
>>>Date: Tue, 17 Mar 2009 09:45:41 -0700 (PDT)
>>>From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
>>>Subject: RE: Thoughts towards an accessible <canvas>
>>>To: "'richarduserite'" < = EMAIL ADDRESS REMOVED = >, "'John Foliot - WATS.ca'" < = EMAIL ADDRESS REMOVED = >, "'Wai-Ig'" < = EMAIL ADDRESS REMOVED = >, < = EMAIL ADDRESS REMOVED = >, "'HTMLWG'" < = EMAIL ADDRESS REMOVED = >
>>>Cc: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >, "'Gawds_Discuss'" < = EMAIL ADDRESS REMOVED = >
>>>
>>>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
>>>(http://tinyurl.com/dgrd8b).
>>>
>>>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.
>>>
>>>JF
>>>
>>>
>>>
>> 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/
>>
>>
>>
>>
>
>
>
>--
>Alasdair King
>
>
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/
From: John Foliot
Date: Fri, Mar 20 2009 7:20PM
Subject: Re: Thoughts towards an accessible <canvas>
← Previous message | Next message →
Charles McCathieNevile wrote:
>
> I think that this is a non-starter. As explained in a narrower follow-
> up,
> the penalty to browsers who do this means that mainstream browsers
> simply won't, in all probability.
I will note your comment, and likely return to it in a subsequent follow-up
> >
> > Title:
> > [mandatory] A brief description or name of the canvas content.
>
> If we want alt, we could add it. I think there may be value in that,
> even
> though I expect it to be misused a lot (I don't see that as
> overwhelmingly
> harmful). The use case is for a quick functional explanation of what
> you
> are missing, or not perceiving as clearly as needed to make sense of
> it,
> right? So it would help make a decision about whether to zoom the
> canvas,
> look inside for the alternative content, or just skip it and get to the
> thing you were looking for.
Yes, thanks for re-stating the use-case. This is exactly what I am
suggesting. If re-purposing @alt here makes more sense then +1 for that
> > Author:
> > [mandatory] The owner or creator of the widget. May be an
> individual
> > or entity, and may also include the anchor element to another URI
> > Examples:
> > * <a href=http://www.fox.com>;The FOX Broadcasting Company </a>
> > * Joe Blough for My Web Developer Company LLC
> > * Mozilla Labs Project - Dion Almaer, on behalf of the Bespin
> > development team
>
> I am not sure why this should be mandatory. It's also the sort of thing
> I
> would see as being more generally useful (e.g. for anything that is
> aria-role="application"), and I think it is the kind of use case that
> RDFa
> might more effectively deal with.
Re: methodology - sure, open to any and all ideas. Thought RDFa was still
"contentious" in HTML5, but that seems reasonable.
Re: why. Honest response - social engineering. When someone signs their
name to something, they tend to take the time to do it right - it's their
name after all. So it's a check and balance thing - are you comfortable
putting your name to this widget? Willing to concede that it is
non-technical, but often so am I <grin>.
> > Description:
> > [optional] A more detailed explanation, expanding upon the Title.
> We
> > cannot presume that all users want a verbose explanation of the
> canvas
> > 'widget', however there are times when some might, and providing this
> > information would be of great use.
>
> Putting this in an attribute seriously reduces its utility - you have a
> big pile of text that cannot include markup. If there is a description
> elsewhere (be it on the page or on another page) then referring to it
> with
> aria-describedBy seems to make more sense. Otherwise, if it is useful
> then
> having it in the content of the element (which should be made
> available,
> as per UAAG [1]) seems more appropriate, since that can at least allow
> for
> markup (and links, etc).
Once again, methodology is open to what works best. Key point is a
separation of terse description and verbose description - there is a need
for both, but also a significant enough difference that both should exist.
>
> > Alternate:
>
> I think that given we are developing a new thing, the aria-describedBy
> should be used for this (it is in fact analagous to longdesc, just
> applicable to more elements). I also think that this should be the
> primary role of the content of the canvas element.
>
> One issue that hasn't been articulated anywhere I can think of is what
> to
> do where you have multiple alternatives. Since most of the examples of
> canvas I have seen don't provide any meaningful alternative at all,
> this
> may be a use case based on wishful thinking, but in principle it is at
> least a reasonable thing to do...
+1 for that
>
> > Notes:
>
> Again, I think that this is probably information that can be added to a
> description, and thus covered by the content/@title/@aria-describedBy
>
Fair enough, I was thinking more along the lines of a catch-all container -
version info or change-log data, text stuff like that. Non-critical data,
but this was just a vague thought anyway.
With a reworking of "titles", there is also a need to think through the
actual pattern of this data as it would be included inside the opening and
closing <canvas> 'tags'. I had thought of a definition list as being the
most 'semantic' container, but is there another pattern container that would
make more sense? Feedback/discussion encouraged.
Cheers!
JF
From: Joshue O Connor
Date: Sun, Mar 22 2009 4:15AM
Subject: Re: Thoughts towards an accessible <canvas>
← Previous message | Next message →
Maciej Stachowiak wrote:
>
> On Mar 19, 2009, at 8:34 AM, Charles McCathieNevile wrote:
>
>>
>>> 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. The inclusion of this
>>> information should not be left to chance - the specification requires
>>> that some fallback content exist - and if it does not exist then the
>>> <canvas> element is incomplete, thus it should simply fail all users...
>>
>> I think that this is a non-starter. As explained in a narrower
>> follow-up, the penalty to browsers who do this means that mainstream
>> browsers simply won't, in all probability.
>
> I agree with Chaals on this. We would likely not be willing to stop
> rendering existing <canvas> content in Safari.
Yes, all the more reason to ensure that the API is suitable /before/ it
leaves the stable so we are not facing a situation where we need to
retrofit the API for accessibility.
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Benjamin Hawkes-Lewis
Date: Mon, Mar 23 2009 8:05AM
Subject: Re: Thoughts towards an accessible <canvas>
← Previous message | No next message
On 23/3/09 06:15, John Foliot - WATS.ca wrote:
> What is the price for non-conformance?
Well, in that particular case, the price would be similar to the costs
of other instances of inaccessibility:
1. Loss of audience, with the attendant loss of funds or influence.
2. Denial of the audience's rights, with the attendant ethical, social,
and legal risks.
I think the question of denying the entire audience content which is
only accessible to part of the audience and the general question of how
to promote web accessibility via a specification are large and
interesting ones, but there is a serious risk of them sidetracking
discussions of the technicalities of making content accessible in the
first place. These questions are not "canvas" specific - the same
discussion has been had around "alt". So I'd recommend separating the
three issues:
1. How do you make content (e.g. "canvas") accessible to end-users?
2. How should HTML5 encourage use of its accessibility features?
3. How should HTML5 consumers handle partial content? (e.g. "img" with
"alt" but no "src")
Without decisions about (1), questions (2) and (3) are pretty valueless.
--
Benjamin Hawkes-Lewis