RE: The Canvas 2D API 1.0 Specification

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


                                                                           
             "Jim Allan"                                                   
             <jimallan@tsbvi.e                                             
             du>                                                        To 
             Sent by:                  "'Simon Harper'"                    
             w3c-wai-ua-reques         <simon.harper@manchester.ac.uk>,    
             t@w3.org                  "'UAWG list'" <w3c-wai-ua@w3.org>   
                                                                        cc 
                                                                           
             08/20/2009 09:55                                      Subject 
             AM                        RE: The Canvas 2D API 1.0           
                                       Specification                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >