- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sun, 18 Dec 2011 17:44:48 +0100
- To: "Steve Faulkner" <faulkner.steve@gmail.com>, "Paul Bakaus" <pbakaus@zynga.com>
- Cc: public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On Sun, 18 Dec 2011 11:15:59 +0100, Steve Faulkner <faulkner.steve@gmail.com> wrote: > Jonas wrote: > >> However even for hit testing and focus management, maybe we would >> design the API differently if we weren't trying to use them to built >> text editors. I really don't know enough about accessibility to fully >> answer that. One proposal was to re-use the image map paradigm, because it is well known, widely implemented interoperably (modulo some implementations being partial - just like HTML5 and SVG and CSS3...), and because it already provides at least a great many of the necessary hooks to make an interactive visual representation of something accessible. There are indeed other ways to do this (e.g. we could use the aria syntax that builds the same thing, we could design the API from scratch, we could adopt something from SVG, etc), but what I do know about accessibility leads me to doubt that we need to reinvent this wheel again from scratch. We should of course examine it for the use cases which go beyond "accessibility" before taking such a decision. > For hit testing, example uses and background is provided by Frank > Olivier in the doc i pointed to: > http://www.w3.org/wiki/Canvas_hit_testing > He has also publicly stated that building text editors in canvas is a > 'fools errand': > http://lists.w3.org/Archives/Public/public-html/2011Nov/0210 > So I think it is reasonable to assume that Franks hit testing proposal > is not motivated by the desire to build text editors in canvas. I also believe that building text editors in canvas is a fool's errand, but that hit testing with a level of "what pixel was touched" would be valuable. There are a lot of use cases. I'll detail some and roughly describe some more. I cc'ed Paul because I recall him saying that for games this would be really valuable. Use case: Graphics editors Canvas has been used to create numerous applications for manipulating graphics. Where button controls are drawn into the canvas, some relatively simple calculation needs to be done to check whether they have been activated. Where there is any dynamic aspect to this (e.g. a brush selection button results in a number of possible brushes being shown) the complexity of the calculations required increases rapidly. Elements which can have a listener applied and whose coordinates in the canvas can be easily described (which is already done to draw or "undraw" them) reduce the complexity and increase the maintainability of the code. (Having had such tools on the Apple II Plus (1983) I find the argument that this sot of application is not suited to keyboard use a load of post-hoc rationalisation of nonsense, although I recognise that it has been successfully employed in the past for setting legal requirements. The difference between that and technical use cases is one related to where the burden is imposed. Applying the principle that things should be easiest for users and hardest for proponents of theoretical technical purity, I conclude that making this possible in a browser is less burden on the world than making every app developer do it on their own). Use case: Adaptable games Many very simple graphical games (pitched around kindergarten level) can be made in either SVG, HTML+CSS or canvas, with the most important determinant being the programming paradigm most suited to the developer's further needs. peepo.com provided a suite of such games for people with severe intellectual disability, explicitly designed to familiarise people with the use of the mouse to interact with on-screen objects which were randomly drawn on the canvas. The ability to hit-test and determine which of a set of objects is nearly all of the active code in a canvas implementation (the examples on peepo happened to use SVG because the author was more familiar with it, and it is indeed better suited to this kind of application). NB There are many demos of "piles of photos" which have similar underlying code requirements. Use case: Jigsaw puzzles Canvas is ideally suited to making dynamic jigsaw puzzles. Taking a picture, cutting it into fragments, and randomly distributing them on the canvas is much easier in canvas than SVG. But to enable a user to dynamically interact with the pieces, some kind of hit-testing is required. Doing this with listeners on elements whose location can be updated, rather than having to do the calculation in javascript every time, makes a significant difference to the amount of code required and to its complexity and maintainability. In many ways this is a specialisation of the previous use case, but one where the use of canvas really is far more natural than any alternative. Use case: Accessible visual testing The tests required for a driving license in Victoria (and presumably in many countries, since the underlying parts are basically the same) include many based on visual interpretation of a scene and identifying important points. The level of visual perception required for the normal presentations of the test (on relatively small touch screens) is notably higher than the level of visual perception required to drive safely. Similarly, the use of visual interactive canvases to explain chemistry and then examine students is decades old*, but a certain proportion of prospective chemists will need to zoom and pan around the presentation because their vision is insufficient to interact with the default system (while perfectly good enough to be expert chemists - something that in fact people can do being completely blind). The ability to dynamically adjust the size of the canvas without having to re-calculate all hit zones simplifies the task of making the system meet legal requirements for accessibility. (I studied chemistry decades ago and had to squint to use such systems.) Some other places this would be helpful beyond simple generalisation of the use cases above include: + 2-dimensional interactive map and map-based interactions (from treasure-map games to crowd-sourcing information about danger spots in a given area); + offering the ability to move annotations on a map so they don't overlap; + games which intrinsically require zoom and pan e.g. to mimic the limited view a pilot has at any time over the entire set of controls available in a flight deck; + Interactive UI design tools that allow for live addition of functionality to components initially drawn and manipulated on a canvas This is by no means exhaustive, just some illustrative examples. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Sunday, 18 December 2011 16:45:34 UTC