Re: The Canvas 2D API 1.0 Specification

Well, I heard similar concerns when I started ARIA but here we are. The 
complaint was that we can't even get people to do alt text. Over 50 IBM 
products are using it and frankly the developers get ARIA. They are also 
starting to see that they really can make a RIA as usable as desktop 
applications. They are jazzed about the new keyboard paradigm shift we 
introduce with ARIA. Industry adoption outside IBM is also massive - YUI, 
Dojo, gmail, google reader, and many others. This really is another 
accessibility curb cut.

... and if you really want to get jazzed you should check out the work 
going on in the Open Ajax Alliance in the way we are redefining next 
generation tooling for accessibility: 
http://www.openajax.org/member/wiki/Accessibility

I appreciate your concerns. With canvas there is no silver bullet but we 
will work to make it as easy as possible. What we learn from canvas will 
accelerate our work on SVG accessibility.

All the best, 

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist



Simon Harper <simon.harper@manchester.ac.uk> 
Sent by: w3c-wai-ua-request@w3.org
08/24/2009 03:36 AM

To
Richard Schwerdtfeger/Austin/IBM@IBMUS
cc
Jim Allan <jimallan@tsbvi.edu>, UAWG list <w3c-wai-ua@w3.org>
Subject
Re: The Canvas 2D API 1.0 Specification






Hi there Richard,

I think that I agree about your statement that 'Canvas is doable' but 
reading the wiki supports my own view that it is doable with lots of 
caveats and also with lots of premise / pre-assertions.

I worry when I read the wiki comments that
1) It seems that we are assuming that people who build sites are 
trained developers (who understand procedural code) and that these 
developers will therefore use toolkits; and
2) That these developers will start to add extra information, not 
specified directly in html5 canvas and not required for an html5 
canvas to execute visually correctly.

It seems that html5 lead and aria is then shoehorned into suggesting 
that accessibility is possible if the web developer jumps through a 
number of hoops; which they are never really likely to.

I really hope I'm wrong about this - but web creators don't even 
manage to create a table 'summary'. It seems to me that just as 
people are specifying the 2d api canvas, why then cannot pf attempt 
something like a canvas accessible interaction api / gui api so that 
accessibility is built in from the start and not an after thought?

Cheers
Si.

=======================

Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk

My Site: http://hcw.cs.manchester.ac.uk/people/harper/

My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ 
phpicalendar/week.php
My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/ 
SimonHarper.ics





On 22 Aug 2009, at 22:22, Richard Schwerdtfeger wrote:

> Hi Jim,
>
> I organized a small group under the HTML working group. Canvas is 
> doable. Take a look at a post I had Laura Carlson put up for me 
> while my wiki access was getting approved:
>
> http://esw.w3.org/topic/HTML/ 
> AddedElementCanvas#head-7417bcc86e63e6a528872dd1ab93576887e6208d
>
> I formed a working group in HTML to address this. We are working on 
> a version of this strategy but the general idea is holding so far. 
> We have participants from Microsoft, TPG, Apple, Mozilla, IBM (me), 
> and W3C. We are doing some proof of concept prototypes this with a 
> DOM backing for a canvas. Essentially, your DOM becomes your 
> accessibility hierarchy with focusable elements bound to the 
> canvas. This coupled with an equivalent alternative content 
> mechanism should go a long way. The lightweight W3C DOM structure 
> with ARIA markup will go a long way.
>
> If you go out to wai-xtech I have posted minutes for the first 
> meeting. I don't know if we will be able to get all the scenarios 
> for canvas when HTML 5 goes out but applications like Bespin are a 
> slam dunk. Adobe could execute a similar strategy for Flash.
>
> Cheers,
>
> Rich
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
>
> <graycol.gif>"Jim Allan" ---08/20/2009 10:00:53 AM---Good idea. At 
> first blush it seems nearly impossible.
>
> "Jim Allan" <jimallan@tsbvi.edu>
> Sent by: w3c-wai-ua-request@w3.org
> 08/20/2009 09:55 AM
>
> <ecblank.gif>
> To
> <ecblank.gif>
> "'Simon Harper'" <simon.harper@manchester.ac.uk>, "'UAWG list'" 
> <w3c-wai-ua@w3.org>
> <ecblank.gif>
> cc
> <ecblank.gif>
> <ecblank.gif>
> Subject
> <ecblank.gif>
> RE: The Canvas 2D API 1.0 Specification
> <ecblank.gif><ecblank.gif>
>
> Good idea. At first blush it seems nearly impossible.
> Scenario:
> Object with flash. I suppose the actual name of the swf file would 
> be some
> 'useful' information. Other than that is there anything other 
> information to
> feed to the user.
>
> All of the actual content is wrapped up in something the 'base' UA 
> cannot
> access.
>
> BUT...if the flash player is the UA and the swf file is the 
> content. The
> flash UA should 'know' (one hopes) the content of the swf file. 
> Then is the
> responsibility of the flash UA to provide the fallback content to 
> the 'base'
> UA so it can be provided to the user.
>
> Here is a tree view. Hope it makes sense.
>
> Base UA
>
> <object>
> <flash player UA>
> <fall back content provided by author>
> Something useful and meaningful
> </fall back content provided by author>
> <swf content src=foo.swf>
> (some fallback content created on demand from the
> Base UA by the Flash UA on because of none existence of author 
> supplied
> fallback content.)
> </swf content>
> </flash player UA>
> </object>
>
> > -----Original Message-----
> > From: Simon Harper [mailto:simon.harper@manchester.ac.uk]
> > Sent: Thursday, August 20, 2009 9:32 AM
> > To: Jim Allan
> > Cc: 'UAWG list'
> > Subject: Re: The Canvas 2D API 1.0 Specification
> >
> > In this case should we not think about possible scenarios for UAs to
> > generate missing fallback content. Maybe a set of examples,
> > principles, etc so there is at least some consistency?
> >
> > Cheers
> > Si.
> >
> > =======================
> >
> > Simon Harper
> > University of Manchester (UK)
> >
> > Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
> >
> > My Site: http://hcw.cs.manchester.ac.uk/people/harper/
> >
> > My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/
> > phpicalendar/week.php
> > My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/
> > SimonHarper.ics
> >
> >
> >
> >
> >
> > On 20 Aug 2009, at 15:11, Jim Allan wrote:
> >
> > > PF is already on this. Interestingly, HTML5 is as much a
> > > specification for
> > > designing a user agent as it is a language spec. Viewed in that
> > > light, it
> > > could prove useful to UAWG as a jumping off point for filling-in
> > > accessibility gaps. One area to fill in would be the notion of
> > > fallback
> > > content. The user should have access to the fallback regardless of
> > > the state
> > > of the parent element. In other words, the user should have access
> > > to the
> > > fallback content whether canvas scripting is on or off, or other
> > > conditions.
> > >
> > > The question becomes, will UA developers actually implement these
> > > items.
> > > Canvas will still work even if the user has no access to the 
> fallback
> > > content. This is the status quo with 'objects' now (Flash, video
> > > players,
> > > etc.). They all function, yet the user has no easy access to 
> fallback
> > > content.
> > >
> > > Jim
> > >
> > >> -----Original Message-----
> > >> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua- 
> request@w3.org] On
> > > Behalf
> > >> Of Simon Harper
> > >> Sent: Thursday, August 20, 2009 3:10 AM
> > >> To: Jim Allan
> > >> Cc: 'UAWG list'
> > >> Subject: Re: The Canvas 2D API 1.0 Specification
> > >>
> > >> It seems then that the accessibility interface to canvas is 
> the bit
> > >> we should be working on as canvas seems like a mini-ua? We should
> > >> start to make suggestions and give solutions to the html5 
> people IMO.
> > >>
> > >>
> > >> Cheers
> > >> Si.
> > >>
> > >> =======================
> > >>
> > >> Simon Harper
> > >> University of Manchester (UK)
> > >>
> > >> Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
> > >>
> > >> My Site: http://hcw.cs.manchester.ac.uk/people/harper/
> > >>
> > >> My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/
> > >> phpicalendar/week.php
> > >> My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/ 
> harper/
> > >> SimonHarper.ics
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On 19 Aug 2009, at 18:53, Jim Allan wrote:
> > >>
> > >>> Thanks Simon. It's a nice statement. We all know, if a developer
> > >>> can do
> > >>> something they will.
> > >>>
> > >>> One troubling bit is
> > >>>> When authors use the canvas interface element, they must also
> > >>>> provide
> > >>>> content that, when presented to the user, conveys 
> essentially the
> > >>>> same function or purpose as the bitmap canvas. This content 
> may be
> > >>>> placed as content of the canvas interface element. The 
> contents of
> > >>>> the canvas interface element, if any, are the element's 
> fallback
> > >>>> content.
> > >>>
> > >>> UAAG20 has
> > >>> 3.1.1 Notification of Alternative Content: Provide a global 
> option
> > >>> for the
> > >>> user to be notified of alternatives to rendered content (e.g.,
> > >>> short text
> > >>> alternatives, long descriptions, captions).
> > >>>
> > >>> 3.1.2 Configurable Default Rendering: Provide the user with the
> > >>> global
> > >>> option to set which type of alternative to render by default. 
> If the
> > >>> alternative content has a different height and/or width, then 
> the
> > >>> user agent
> > >>> will reflow the viewport. (Level A)
> > >>>
> > >>> We had similar stuff in UAAG10. However no User Agents have yet
> > >>> implemented
> > >>> a way to easily get to the internal element "fall back content".
> > >>>
> > >>> Another troubling item is
> > >>>> In interactive visual media, if scripting is enabled for the 
> canvas
> > >>>> interface element, the canvas interface element represents an
> > >>>> embedded element with a dynamically created image.
> > >>>
> > >>> This implies there is separate scripting for canvas. Separate 
> from
> > >>> javascript? A different instance? How does a user (or agent) 
> turn
> > >>> off
> > >>> scripting for just canvas?
> > >>>
> > >>> Jim
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-
> > >>>> request@w3.org] On
> > >>> Behalf
> > >>>> Of Simon Harper
> > >>>> Sent: Wednesday, August 19, 2009 10:46 AM
> > >>>> To: UAWG list
> > >>>> Subject: The Canvas 2D API 1.0 Specification
> > >>>>
> > >>>> I was monitoring xtech and saw this going through
> > >>>>
> > >>>> http://dev.w3.org/html5/canvas-api/canvas-2d-api.html
> > >>>>
> > >>>>
> > >>>> which says..
> > >>>>
> > >>>> 5. Accessibility Considerations
> > >>>>
> > >>>> Authors should not use the canvas interface element in a 
> document
> > >>>> when a more suitable element is available. For example, it is
> > >>>> inappropriate to use a canvas interface element to render a 
> page
> > >>>> heading: if the desired presentation of the heading is 
> graphically
> > >>>> intense, it should be marked up using appropriate elements
> > >>>> (typically
> > >>>> h1) and then styled using CSS and supporting technologies 
> such as
> > >>>> XBL.
> > >>>>
> > >>>> When authors use the canvas interface element, they must also
> > >>>> provide
> > >>>> content that, when presented to the user, conveys 
> essentially the
> > >>>> same function or purpose as the bitmap canvas. This content 
> may be
> > >>>> placed as content of the canvas interface element. The 
> contents of
> > >>>> the canvas interface element, if any, are the element's 
> fallback
> > >>>> content.
> > >>>>
> > >>>> In interactive visual media, if scripting is enabled for the 
> canvas
> > >>>> interface element, the canvas interface element represents an
> > >>>> embedded element with a dynamically created image.
> > >>>>
> > >>>> In non-interactive, static, visual media, if the canvas 
> interface
> > >>>> element has been previously painted on (e.g. if the page was 
> viewed
> > >>>> in an interactive visual medium and is now being printed, or if
> > >>>> some
> > >>>> script that ran during the page layout process painted on the
> > >>>> element), then the canvas interface element represents embedded
> > >>>> content with the current image and size. Otherwise, the element
> > >>>> represents its fallback content instead.
> > >>>>
> > >>>> In non-visual media, and in visual media if scripting is
> > >>>> disabled for
> > >>>> the canvas interface element, the canvas interface element
> > >>>> represents
> > >>>> its fallback content instead.
> > >>>>
> > >>>>
> > >>>>
> > >>>> they say...
> > >>>>
> > >>>> Techniques and additional APIs to make specific uses of canvas
> > >>>> interface elements more widely accessible are under 
> discussion, and
> > >>>> will be reflected in this draft as progress is made.
> > >>>>
> > >>>> I wonder what these are?
> > >>>>
> > >>>>
> > >>>> Cheers
> > >>>> Si.
> > >>>>
> > >>>> =======================
> > >>>>
> > >>>> Simon Harper
> > >>>> University of Manchester (UK)
> > >>>>
> > >>>> Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
> > >>>>
> > >>>> My Site: http://hcw.cs.manchester.ac.uk/people/harper/
> > >>>>
> > >>>> My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/
> > >>>> phpicalendar/week.php
> > >>>> My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/
> > >>>> harper/
> > >>>> SimonHarper.ics
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
>
>
>
>