Re: hit testing and retained graphics

Mozilla labs is jumping the shark, again, with a PDF rendering webapp using Canvas.

http://andreasgal.com/2011/06/15/pdf-js/

They have noted (as I have), that there are cases where imperative drawing of a scene can beat-out the poor performance of the browser's generalized and declarative render tree implementation.

I feel that practical usability is a reasonable use case; there are situations where the browser render tree and Dom manipulation just are not performant, and specialized render trees (via canvas), with contextual aria (think aria-posinset, aria-live) are performant, work across devices (tv, phone, tablet, desktop) and are accessible (screen reader, zoom, machine translation, search indexing).

This Mozilla labs crew may receive a cold welcome by Mozilla browser implementers -- it may be a repeat of the bespin incident, or it may drive innovation in a11y and render trees.

Regardless, it's another very serious project, and one which is actively looking for a11y semantics to work with canvas.

I've proven several defects through implementation, and still been rebuffed by Mozilla developers: I've been told before that they will not implement nor approve patches to remediate some of the defects. I hope that my additional attention to use-case authoring will unstick the situation.

Meanwhile: I hope that the developers who have advised Apple and Microsoft browser managers about canvas a11y will spend some time engaging in this list. Current comments from MS and Apple have suggested that pointer device canvas a11y has been categorically rejected; though both companies have accepted keyboard a11y via the canvas shadow tree and focus rings.

-Charles


-Charles

On Jun 29, 2011, at 7:23 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:

> It took me 5 minutes to find these examples of people "doing it wrong"
> http://www.ericom.com/AccessNow_FAQs.asp
> http://www.thinvnc.com/index.html
> http://tge.stormwarestudios.com/example/2010-07-20/
> http://bitterspring.net/webshifter/
> https://www.lucidchart.com/
> http://creativefan.com/20-shockingly-cool-html5-canvas-applications/
> 
> To suggest that a feature as powerful as canvas is not going to get used for general UI and is simply an enhanced image is frankly ludicrous.
> 
> -----Original Message-----
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of E.J. Zufelt
> Sent: 29 June 2011 14:50
> To: Paul Bakaus
> Cc: Tab Atkins Jr.; John Foliot; Charles Pritchard; Charles McCathieNevile; Richard Schwerdtfeger; Cameron McCormack; Cynthia Shelly; david.bolter@gmail.com; Frank Olivier; Mike@w3.org; public-canvas-api@w3.org; public-html@w3.org; public-html-a11y@w3.org
> Subject: Re: hit testing and retained graphics
> 
> On 2011-06-29, at 9:33 AM, Paul Bakaus wrote:
> 
>> Hi everyone,
>> 
>> I absolutely agree with TJ here. I think a lot of people here are trying
>> to solve theoretical issues right now, which is very dangerous. I have
>> closely observed the canvas landscape, and there are very few production
>> apps out there that could benefit largely from increased accessibility on
>> the canvas object itself. Mostly, today's canvas applications are game
>> demos and drawing apps.
>> 
> What about tomorrow?
> 
>> If you are writing your GUI in canvas, you are doing it wrong. If you are
>> building a chart/graph and don't run the canvas visualization from data
>> markup that was progressively enhanced, you are doing it wrong. Hell, even
>> if today you are trying to create a full game on canvas, you are probably
>> doing it wrong (unless you want really fancy particle fx and can live with
>> a super small canvas size). Canvas *is* an enhanced <img>.
>> 
> And, when developers build a GUI on canvas, and therefore are "wrong", how will persons with certain disabilities access that GUI so that they can be full participants in the "wrongness", be it at school, work, or for entertainment?
> 
> Everett Zufelt
> 
>

Received on Wednesday, 29 June 2011 19:11:13 UTC