W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2009

Re: The Canvas 2D API 1.0 Specification

From: Simon Harper <simon.harper@manchester.ac.uk>
Date: Thu, 20 Aug 2009 17:12:41 +0100
Message-Id: <89DAEAAC-6EB2-4BEC-A0A0-61CFFFFD211B@manchester.ac.uk>
Cc: "'UAWG list'" <w3c-wai-ua@w3.org>
To: "Jim Allan" <jimallan@tsbvi.edu>
I agree on this one. So we should stipulate this in UAAG, and then  
move on to stuff like the 2d api 3d api etc.

There is some very nice work on Flash access at:
http://www.eclipse.org/actf/docs/users/aiBrowser/docs/

In which the text is accessed from a Flash presentation.


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:55, Jim Allan wrote:

> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>
Received on Thursday, 20 August 2009 16:13:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:52:15 GMT