Warning:
This wiki has been archived and is now read-only.

AddedElementCanvas

From HTML WG Wiki
Jump to: navigation, search

Canvas Element Accessibility Issues

Issue

The new canvas element is used for rendering dynamic bitmap graphics on the fly, such as graphs, games, animations, image composition et cetera.

The vision impaired are currently shut out based upon their disability and/or use of assistive technology.

HTML5 currently lacks specific mechanisms to add accessibility hooks for content produced using this element. Traditionally, native development platforms provide some degree of automatic high-level accessibility support for built-in controls, and then a low-level accessibility API for custom controls that developers build using drawing primitives and events directly. The Web platform lacks something similar. For images that are generated on the fly, but thereafter not modified, a text alternative might suffice. For animated graphics demos, a description of the demo could be enough. But for truly interactive application-like content that is custom-rendered, a true accessibility API is needed, not just an assortment of different textual alternatives.

If <canvas> is really needed, then accessibility should be incorporated into the design and the specification should include an appropriate fallback strategy that is supported by assistive technology. Accessible fallback for canvas has not been tested. It is unknown if it works.

The latest published HTML 5 Draft on its use states:

"Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas 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 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 element. The contents of the canvas element, if any, are the element's fallback content."

Status

Change Proposals

Polls

Contents

Rationale: Why this element should have accessibility provisions

  1. A native accessible <canvas> would provide a person with disabilities equal opportunity. If HTML5 has an element for content authoring on the web, then accessibility aspects (DOM hooks, SVG on the fly to help augment the Canvas element, or whatever) need to be part of the spec.
  2. A tried an true fallback mechanism would provide a way to present an alternate when the 'main' equivalent(s) can for whatever reason not be presented.
  3. The HTML Charter states: "The HTML Working Group will cooperate with the Web Accessibility Initiative to ensure that the deliverables will satisfy accessibility requirements. Coordination with WAI will be primarily conducted through the Protocol and Formats Working Group, but direct coordination with other WAI groups, such as Web Content Accessibility Guidelines Working Group and User Agent Accessibility Guidelines Working Group, will also be done when appropriate."
  4. It won't work for canvas accessibility problem to be diverted to the expert handlers group. That would would entail making a plug-in that works on all platforms and developers would need to learn new markup. This is unnecessary.
  5. Saying that the accessibility solution for canvas is not needed and a usage problem solvable through education and evangelism will not work either. What ends up happening is legislation prohibits the use of canvas which will create inhibits adoption. This should have been learned from JavaScript. It took us 5 years to undo the last mess when we tried to shovel JavaScript under the carpet.
  6. It is possible to make canvas accessible. Work is being done on this now through the creation of a ARIA-enabled DOM binding.
  7. Applicable Design Principles:
    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."
    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."
    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."

Rationale: Why this Element should not have accessibility provisions

  1. Canvas accessibility problem can be target for expert handlers group. They develop plug-able mechanism to allow AT work with specialized markups.
  2. An accessibility solution for canvas is not needed, it a usage problem solvable through education and evangelism.
  3. It is not possible to make canvas accessible. Add a statement that it is not directly accessible, and stop there. Anything less suggests that it shares the default accessibility story of HTML 4, which it clearly does not. The cleanup techniques for canvas should go in the WCAG 2 techniques for HTML5.
  4. Applicable Design Principles:
    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."
    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."
    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."

Use Cases

Many of the use cases below are thanks to Andi Smith's canvasdemos.

Applications

  • Bespin (text editor) a great example of the utility of the canvas element, its also a worrying example of the barriers to accessibility its use will produce. It includes editable text, folder lists and interactive elements that are all essentially a graphic. there does not appear to be a way to extract any usable information to support Assistive technology to interpret or provide interaction. It is currently totally inaccessible to screen reading technology. Dion Almaer has some ideas to improve its access, like having an accessible mode that keeps a shadow div or textarea that is off screen. With some focus magic, the reader will see it as the editor and will be able to interact with it... and we can use ARIA in that shadow to get things done.
  • cufon (embedded font thingy) An alternative to sIFR, cufon uses VML on IE and canvas on other browsers to render custom fonts in the browser. You have to convert your font to JavaScript first, either using their free hosted tool or by installing the FontForge based server-side script yourself. The JavaScript encoded font file uses VML primitives to improve IE performance; the JavaScript library converts that to canvas calls for other, faster browsers.
  • JuicyDrop - Winamp Music Visualization with JavaScript and Canvas Winamp clone done in html5 and canvas - with visualizations.
  • Yahoo! Pipes uses canvas to provide the interactive application to build "pipes".
  • Canvas Paint Canvas Paint is a clone of MS Paint built using canvas. You might argue that such an application doesn't really serve a practical purpose, which may be true because basic paint applications probably come with most operating systems.
  • A web based email application could provide a basic paint tool for drawing quick sketches to be emailed to someone.
  • iwork.com - Apple’s online sharing tool for iWork Documents uses Canvas to render the document itself in the browser to ensure perfect representations of the actual document.
  • 280 Slides - Online Presentation Application.
  • Shared Whiteboard allows users to draw on their screen and have it duplicated on another. MSN Messenger, for example, provides that ability over their IM chat network. Canvas, in conjunction with XMLHttpRequest, Server Sent Events or maybe even the TCPConnection interfaces being worked on in the Web API WG would allow this to be done using an ordinary web browser.
  • 360-degree player - By Scott Schiller. uses Canvas to draw pretty waveform and spectrum EQ graphs around a circular UI that shows load and play progress. The 360 UI works on the basis of decorating plain old HTML links to MP3 files, allowing play, seek, showing progress etc. using the canvas element.
  • HTML5 Love - IO from 9Elements. This is a visualizations that combines both the HTML5 canvas and audio elements with updates from social networking site Twitter. It loads 100 tweets related to HTML5 and displays them using a javascript-based particle engine. Each particle represents a tweet - click on one of them and it'll appear on the screen. The music will only be played if the browser supports the audio tag. Details in HTML5 Canvas Experiment blog post
  • Canvas Painter painter app - controls on right are canvas based

Mathematics, Visualization

  • Bespin Pie - Ben Galbraith The example uses a canvas pie menu demonstration to which a transparent image map has been added. The image map provides keyboard access to segments of the pie menu, it also provides information about their role and state of each and name (text alternative) for each segment. Note: Use of this image map technique, while useful for illustrative purposes is not proposed as a practical solution.
  • cylinder uses a Java applet to render a cylinder that the user can move around by dragging the mouse to inspect it. There are many other similar examples on this site.
  • square_pyramid actually uses the canvas element for rendering various 3D models. The site appears to be a some sort of educational site about polyhedra shapes. Interestingly, the about page on the site describes how they had used Flash in the past, but changed to using canvas when it became available. For more info visit the about page of the site.
  • Scrolling performance graph
  • Pie Menu
  • Graphics calculator is built using a Java applet and allows the user to plot graphs of mathematical equations.
  • PlotKit is a script that can draw graphs from a set of data (e.g. in a table) using either canvas or SVG.
  • Protovis A graphical toolkit for visualization from Stanford. It takes a graphical approach to data visualization, composing custom views of data with simple graphical primitives like bars and dots. These primitives are called marks, and each mark encodes data visually through dynamic properties such as color and position.
  • RGraph Interactive canvas graph library
  • SoundMaster2 music-visualization Playing Radiohead’s Idioteque, the demo displays frequency bars, waveforms, binary outputs and create an image of Thom Yorke, lead singer of Radiohead.
  • Gauge.js Apple-esque gauges (with shading and reflection) to your webpages. If you use a Mac or an iPod, these gauges will look familiar to you as they are similiar to the disk space allowance gauges.
  • PhysicSketch allows to draw items on the canvas and then hit a button to watch gravity take control.
  • jQuery Visualize Plugin: Accessible Charts & Graphs from Table Elements using HTML 5 Canvas
  • Open Web Tools Directory by Mozilla Directory lists useful applications and tools available to web developers, with a component to allow you to narrow down your search. But rather than display this information in a table, Mozilla have opted to display the information in a canvas element and make a space theme of it.
  • Issues Graph
  • ChemDoodle - By Kevin Theisen. An open source chemistry and chem-informatics toolkit where canvas is being used to solve common chemistry related tasks, displaying the molecules in a variety of different ways. There are 6 different components to ChemDoodle, each of which use canvas to display the end graphics. Some also allow the user to interact through mouse and keyboard gestures.
  • Flot A Javascript plotting library for jQuery created by Ole Laursen. It takes data from an array and uses the canvas element to draw the plotted graph.

Games and Puzzles

  • JavaScript GameBoy (JSGB ) By Sonic1980. JSGB is a Nintendo GameBoy Emulator and debugger (written in JavaScript). It runs many games at full speed (using a browser with a fast JavaScript engine).
  • Creating pseudo 3D games with HTML 5 canvas and raycasting by Opera
  • Rubik's Cube Java Applets. There are quite a few of these on various web sites, that's just one of them. It uses a java applet to render the interactive cube.
  • slide Puzzles implements slide puzzles using canvas.
  • Shooter game is a prototype of a first-person shooter game built using canvas. It allows the user to walk around the map, but doesn't yet provide any actual game play beyond that.
  • Torus online game
  • Super Mario Kart Game
  • Breakout game tutorial
  • Twitch series of minimal games set within small windows using the canvas element created by C.E.B. Reas. As you complete each puzzle, a new window will open with a new puzzle. All puzzles can be solved by clicking the mouse at the correct times.
  • Blob Sallad essentially a physics demo with the ability to split, join, drag and drop the blobs.
  • 3bored A shooter/dodge 'em up created by UpsideDownTurtle. Controlling a boxed shape spaceship, the idea is to dodge enemy fire while charging up your spacecraft to ground pound the enemy. As you progress through the levels, different enemy types and firepower appear making survival a much tougher job.
  • Starfield You can change direction by moving cursor over the windows, change/inverse speed with mouse-scroll and change stars amount by adding ?n= at the end of the url.
  • Defender of the favicon A JavaScript remake of Eugene Jarvis' arcade game Defender.
  • Asteroids demo emulating the classic Asteroids game.
  • Jigsaw Puzzle
  • Canvascape - "3D Walker" First person shooter game by Ben Joffe
  • Berts Breakdown
  • JS Wars by Jonas Wagner
  • JSSpeccy - Matt West ported a ZX Spectrum emulator to JavaScript using canvas to output the display. The emulator comes with 10 games, including Manic Miner and Jet Set Willy.
  • Chain Reaction Game - By Yvo Schaap. A single well placed click will decide whether you pass or fail. There are 12 levels each with a required number of balls that need to be detonated, all from your original explosion.
  • jsnes JavaScript NES emulator by Ben Firshman. Rather than rewriting the game in JavaScript, JSNES emulates and reads the encoded ROMs displaying the screen within a canvas element.
  • Coverfire - by Jerason Banes, is a canvas remake of the Apple II video game Crossfire.
  • Life on a Canvas By Mike Pinkowish. A canvas simulation of the Game of Life, a cellular automaton example originally devised by John Conway in 1970.

Widgets and Extensions

  • Tab Sidebar extension for Firefox The Tab Sidebar extension for Firefox uses canvas to render smaller preview of web pages in the side bar, which makes it easier to recognize and select the page to switch to.
  • Example: clock
  • Apple originally invented canvas for their OSX Dashboard, and so it seems likely that there would be a wide variety of widgets that make use of canvas for something. It's likely that there would also be widgets for Opera that use canvas too.

Art and Presentation

  • Reflection uses canvas to add a reflection effect to images. There's a list of implementations at the bottom of that page showing practical uses of the effect.
  • Gartic Canvas Sketch web based sketching application. It features the usual pencil, eraser, line and shape tools, flood fill, color picker and undo, Gartic also allows you to watch an animation of how you sketched artwork and save it out as PNG, GIF or JPG.
  • Surface Photo Gallery - Ernest Delgado has created The Canvas Photo Experiment – a UI implementation that closely follows the 'photo table' application of Microsoft Surface – with the exception of multi touch due to there only being one mouse cursor.
  • Canvas Party (Warning Flickering Animation) by Michael Nut
  • Content Aware Image Resizing - Stephane Roucheray’s Content Aware Image Resizing demo uses the canvas API to display the dynamically resized bitmaps, showing updates as the algorithm calculates which parts of the image should and should not be resized. he algorithm generates a grayscale image from the source. From the grayscale image it generates an edge detection and energy map. The algorithm then runs from the bottom to the top of the energy matrix looking for the pixel with the lowest energy, creating what is known as a seam of least energy. This seam is then removed from the original image and the result is becomes the source image to repeat this process again until the image is of the desired size.
  • Many Lines This application will draw many lines on and around your cursor. The application, developed by Eric Ishii Eckhardt, uses a particle system to draw the lines following your mouse around the screen.
  • HTML 5 Canvas Animation As canvas comes closer and closer to the features of Flash; canvas-based cartoons are beginning to appear. Starting with this one, featuring two characters called Tomte and Goat; who explain how you can make your own cartoons in canvas.
  • Dynamic Image Collage Berry de Vos (aka RadicalFX) has created a Dynamic Image Collage creation tool, built with canvas. Your collage creating begins with a Flickr search, which will bring up a list of the most popular results. Clicking any of the results will automatically add them to the collage area as a new layer. Each layer can be altered in a variety of ways - from moving, scaling and rotating to changing opacities, blend modes and shadows. You can also adjust the layer position in relation to the other layers. Dynamic image collage with HTML5 and Canvas blog post.
  • Animated website background with HTML5

Canvas 3D

  • Canvas 3D (Proprietary extension to Canvas) "The Canvas 3D project aims to add support for low-level hardware accelerated (where possible) 3D rendering via the HTML canvas element."
  • O3D is an open-source web API for creating rich, interactive 3D applications in the browser.
  • 3D Flickr by Peter Nederlof. As a wall rotates, the user is to click on any panel to reveal a random Flickr photo and push the camera in another direction.
  • Re: 3D Mailing List Proposal
  • 3D Model Viewer by Giuseppe Sicari uses a combination of JavaScript and canvas to display models of three-dimensional objects which are represented by a list of vertices and a set of faces each of which consists of at least three vertices.

Movement Tracker

Maps

  • Cartagen uses GSS - a specification for designing maps. Adapted for dynamic data sources, GSS can define changing geographic elements, display multiple datasets, and even respond to contextual tags like “condition:poor”. Instead of sending pre-rendered tiles for every zoom level, Cartagen draws maps dynamically on the client side. This means maps can move, adapt, and redraw, and can include as many layers of data as needed. Vector mapping is done in native HTML 5, which runs on the iPhone and the Android platforms, and uses less bandwidth overall.

Dynamic Content Injection

Others

  • Manipulating videos using HTML5 Canvas and Firefox 3.5
  • Processing.js John Resig, JavaScript guru and founder of the awesome jQuery library has ported the Processing visualization language to JavaScript, using the canvas element. With help from Casey Reas and Ben Fry they have created a lot of different demos using the library.
  • HasCanvas A tool for creating and sharing Processing scripts and runs on John Resig’s Processing.js.
  • CAKE - Canvas Animation Kit Experiment mouse based manipulation
  • Write Arabic letters with Canvas and Graphics class - Nokia Forum
  • Binary Clock - By Andi Smith. Each circle represent a binary count - when they are filled they represent 1 and when they are empty they represent 0. From the left to right and then downwards, the values represent 1, 2, 4, 8, 16, 32. To get the number 11, the circles 1, 2 and 8 would be filled (1 + 2 + 8 = 11).
  • WPS: PostScript for the Web PostScript/PDF interpreter in JavaScript
  • Canvas used as a captcha.
  • Detexify2 - LaTeX symbol classifier The canvas is purely an input method, not an output method.
  • Oliver's simple fluid dynamics simulator Simple fluid dynamics simulator based on the navier-stokes equations, implemented in JavaScript.
  • Your World of Text - "Your World of Text is an infinite grid of text editable by any visitor. The changes made by other people appear on your screen as they happen. Everyone starts in the same place, but you can scroll through the world using your mouse..."
  • Screen Shoot Me - by Lucho Yankov, provides a way for users to paste an image in their clipboard and make it available on the web in seconds using a shortened URL.
  • Canvas Text tool An implementation of the HTML5 canvas text drawing methods for older browser
  • Fish Simulator By Satoshi Nakajima simulates the famous flocking behavior of fish. The application uses a canvas pre-rendering technique, which generates images of fish in array of off-screen canvas elements. It then uses a CSS transform to specify the location and direction of each fish.
  • Strange Attraction

Related Use Case Notes

  • Also note that canvas was implemented by 3 major browsers before it got added to the spec, so the implementers saw a market demand for it. Since it needs to be interoperably implemented to be useful, it accessibility needs to be speced.

Assistive Technology Support

HAL

HAL

Support unknown.

Linux Screen Reader (LSR)

Linux Screen Reader (LSR)

Support unknown.

JAWS

JAWS For Windows

Support unknown.

NVDA

NVDA: An Open Source Screen Reader for Windows

Support unknown.

Orca

Orca

Support unknown.

VoiceOver

VoiceOver

Support unknown.

Window Eyes

Window-Eyes

Fallback content is currently available in the DOM but it is not announced to the user.

Regarding a time frame for when Window Eyes will announce canvas fallback, the company has said, "Here's a firm commitment, guarantee, absolute fool-proof, official statement that you can take to the bank: we'll do it when we're ready." - Via GW Micro, May 2009.

Proposed Solutions

  • An object model to which authors can apply an accessibility API.
  • A collection of callback interfaces that can be applied to objects to support an accessibility API mapping on each browser and platform and potentially a vehicle to fire events to ATs.
  • A provision for equivalent alternative references that allow a canvas author to specify an alternative resource for drawing that cannot be made accessible through traditional API.

Re: Helping Canvas Tag Be Accessible - Richard Schwerdtfeger. Fw: Canvas Accessibility Next steps - Richard Schwerdtfeger.

1. Specify an Accessibility API for canvas Itself

The canvas API gets information in, so it's possible that one could get information out. The problem is: in what order. There are various heuristics that could be used (the order in which it's drawn, its rendered distance from the origin, or other more elaborate approaches). It may not be ideal, or even the right thing to do, but there certainly is information being provided by the developer to the canvas API that could be exposed to AT. There could, furthermore, be additional pushAnnotation(string)/ popAnnotation() calls added to the API that could provide alternative text information about what is being painted.

Canvas is not mapped to MSAA, but ARIA roles can be added via JavaScript, e.g. resulting in canvas role="img". Still a canvas contains shapes, images, or text. What's missing is a childNode model for those so that they appear in MSAA accessibility,

DOM

Shift some of the work to the browser, by specifying an accessibility API for the canvas itself (If this is a simple canvas tree then it is likely to be missing some of the info that would be required for orientation when you are accessing it via the accessibility API.)

Make a DOM interface to the platform accessibility APIs that would meet the needs of authors trying to hand-roll their UI. Make the child objects available in the DOM where they can receive any ARIA enhancements you can possibly bolt on by scripting. It is true that currently is just a flat bitmap that you can save as PNG or data URL, but when creating shapes and contents in a canvas, why shouldn't you be allowed to add semantics at the same time? But a prerequisite would be browsers mapping those child objects to the DOM, and perhaps using the RDF features of the XHTML role module to expand the available roles by textnodes or things to describe 3D image galleries or future progressive UIs.

For the approach to work, the hidden DOM could be the "model", and the canvas could merely be a photon dependent "view" -- in terms of MVC pattern-speak (and to borrow a TV Raman phrase).

A nested DOM tree could provide access to effectively blind users interacting with speech or braille. It's less obvious what this implies for people who typically interact with visible controls, e.g. people with motor disabilities using switch access, people with bad eyesight using screen magnification, people with reading difficulties using text-to-speech, people who use symbol browsers that convert on-screen text to symbols, people who speak the names of controls into speech recognition programs, people with colorblindness who want to customize interface colors, people with learning disabilities - or, um, ordinary users for that matter, who will struggle to learn interface patterns that diverge from platform or web norms.

Maybe the browser should offer an easy way to disable "canvas" specifically in favour of that DOM tree. Alternatively, efforts like http://dev.aol.com/dhtml_style_guide may help somewhat in terms of enforcing consistency between apps.

Having a hidden DOM under the canvas element, may not be the best way to expose OS integration, not even just for accessibility. If such an approach works with acceptable accuracy and performance then it casts doubt on the motivation for using <canvas> at all; and in general having two completely separate ways of presenting the same content that must be kept in sync (even in the face of dynamic change) is likely to be error-prone.

canvas accessibility: faked "shadow DOM" proof of concept by James Craig.

Expanding on the DOM concept with ARIA and support for Platform Accessibility APIs

Premise I Association of the Objects in the model with graphics contexts

In order to take the object concept to the next level it is important to understand the process by which the author is writing to canvas. The association of the semantic model with the drawing model will be very important conceptually for authors. It will be important to associate the objects, in the model, with a graphics context. It is also clear that applications may have multiple contexts for a given application. At lower levels of graphics systems device contexts are associated with windows or lite-weight drawing objects. In the end this will be no different than canvas. In our objects model, objects may in fact reference the same drawing context.

Premise II How authors write to canvas will be inherently different that the DOM

How developers use canvas will be inherently different than how they use the DOM. Authors will use a collection of drawing primitive to the canvas graphics context. The context will contain at any time the current foreground, background text, clipping areas, and so on. Based on the context the author draws wherever the want to the canvas based on the state of the context. Consequently, there is no W3C DOM the author will load which would then be rendered by the browser. In fact, there is no guarantee that the author will have a DOM structure for things like text. It is most likely the author will have their own conceptual object model i.e. "This part of the canvas represents the text the editor" or "this part of the canvas represents the decision statement in a flow chart."

Premise III The author will store their own content which must be hierarchical and which must support platform accessibility APIs

While the full duplication of the DOM may be possible it may not be practical. Since content is not drawn and structured like a W3C DOM we may need to consider a modified DOM approach. Things like contenteditable areas in HTML 5 have an associated caret position, selected text, etc. This information, along with the text and nodes are mapped directly to the platform accessibility APIs. The HTML DOM does not have enough of this additional functionality and may not be flexible enough. We should consider a modified version of the DOM that allows the author to provide APIs to support text, tabular constructs, caret information, selection information, and ARIA attributes on DOM elements. This allows the author to map their document structure, if needed, to a callback script interface which may be accessed from an assistive technology through the browser. The browser would manage the communication via the transport layer used on each platform (COM for Windows, etc.). This type of DOM could actually be simpler less deep in that the author may choose to have one DOM element to represent a text area - like the text editing area in Bespin. The reason for maintaining a hierarchy is provide context to the user i.e. " these menu items are contained within this menu."

Premise IV Some Canvas content may require alternatives

Some canvas content may be in the form of 2 Dimensional data or other rich graphical drawing where it just does not make sense to have the author go through an enormous effort to make it accessible as there may be a simple solution. For example, most 2D Graphics (Pie charts, Bar charts, histograms) can be easily rendered through an HTML table interface with headers to someone who is blind. In the case where the data changes dynamically, you can simply replace the graph with an aria-enabled grid bound a server data using Ajax. We should consider adding properties to canvas which describe equivalent alternatives, including entirely different objects, that can be used to replace it as an accessible alternative. This flexible interface would also be of great value to HTML elements like the video tag. The video tag may contain a video closed captioned in English. This would be problematic for a hearing impaired user who only speaks Spanish. We may consider incorporating Access For All metadata for <canvas>, <video>, and other HTML elements to allow for this flexibility either in HTML 5 or a follow on. The Ubiquitous Web Application Working group has a personalization roadmap to address providing user preferences that could be consumed by the user agent to perform the content selection.

SVG to Provide Semantics

SVG could be created on the fly in implementations to provide semantics to help augment the Canvas element. One could easily insert any form of XML markup into SVG, including SVG built-in documentation elements.

If we look at the publications that address accessibility in Flash, such as, both Canvas and SVG can be resized, though SVG is the only true vector graphic (regardless of how the graphic is created). SVG can also be embedded in the page, as a file, and opened in a separate window for resizing. Metadata can be added to a SVG element, which can be used to describe what's happening in an animation (that XML mentioned above). There's also been work with touchpad viewers and other plugins and tools to provide a description of the graphics in SVG, such as the text tick marks in a chart, and the path that forms the graph.

The real issue, though, is that the SVG element would provide a way to annotate Canvas element using XML-based metatada--something that probably wouldn't be simple with the Canvas element directly, or HTML, even if using RDFa.

Related Ref:

  • Doug Schepers tweeted that he had submitted a proposal on accessibility and SVG to SVG Open. We might want to get his input.

SVG to Provide Basis for ARIA roles and Properties

SVG could provide the basis for authors to provide ARIA roles and properties if rich components were made using the canvas element.

Other Approaches

Most likely there are other approaches that can be used to add accessibility semantics to the Canvas element--if JavaScript is supported, and we assume with Canvas, it is. Even hiding and displaying textareas, or provide text bubbles in the HTML.

2. Fallbacks

Terse Text Fallback

Require all <canvas> elements to have a terse textual fallback in order to be conformant. e.g. @alt

There is a need for both terse and verbose descriptions. But also a significant enough difference exists that both should exist.

Long Text Fallback

Use aria-describedBy. Apply ARIA markup to the fallback content. If there is a description elsewhere (be it on the page or on another page) then referring to it with aria-describedBy. Otherwise, if it is useful then having it in the content of the element (which should be made available, as per UAAG). This can at least allow for markup (and links, etc).

Element linked to the canvas element through a id/for link

Element, that could be linked to the canvas element through a id/for link.

Fallback Block of 5 Attributes

John Foliot's proposal detailed at Thoughts towards an accessible canvas

  • @title
  • @author
  • @description
  • @alt
  • @notes

Identify Multiple Alternates

Link to several things from inside the canvas for uses like CAPTCHA and multimedia version of an online course. This requires a more complex site structure since you have to start maintaining parallel versions, which is generally a bad choice to have them up to date (the principle of visible metadata). So the question is whether that is sufficient - and given the paucity of current implementation of fallbacks, perhaps it is. You can always use the existing object element to cascade inside the content too. Maybe looking at how multilingual content is handled would give more interesting source material to try and interpret

3. Add Advice/Warning to the Spec

Add a warning and advice to the spec for reasons not to use canvas and other suitable alternatives -- the text in the HTML5 spec saying when canvas is inappropriate doesn't give any justification and seems likely to be ignored. Example

Provide guidance as to when to use canvas and when to use something else.

Discourage inappropriately use of canvas. If one is using canvas as a rendering layer for an application like Bespin then accessibility of that application goes out the window. The solution to that problem is to figure out why people would want to do that and provide them more accessibility-friendly ways of achieving their goals. Disallow canvas as a rendering layer for an application.

ARIA tree

Build something like an ARIA tree as part of what happens inside the canvas. It's not entirely clear how to navigate this tree visually - you need associations with bits of the canvas perhaps, or maybe authoring guidelines tha explain that you need to pick up on navigation by that tree and respond to it.

But that would at least provide a mechanism by which authors who wanted to could make something better than an entire alternative, becaus it would be part of the code that controls the canvas already.

This is essentially authoring guidelines, rather than anything automated, but canvas is for script authors - a step more complex than SVG and therefore a step harder to generalise with easy-fit solutions. And it's about as close as I can see to a solution (since "create a complete alternative" isn't a solution to making canvas accessible, it's just a reason to avoid it altogether - and that won't happen).

4. Use Meta Data

aria-role="application"

Identify with aria-role="application" to identify a bit of inline code that behaves as an external applet (specifically to allow for special handling by tools, where that would be helpful).

RDFa

Use RDFa for metadata (e.g. author). There are many common ways of including information in binary image files, and some common ones are RDF-based and therefore should be readily RDFa compatible. Attach generic metadata to things that are applications (this was clear enough that images do it already, and lots of tools use that data). If there is an issue on doing that in general, this doesn't need to be specific to canvas, but canvas needs to be noted as a use case.

Meeting Minutes Minutes: Accessibility Task Force Canvas Accessibility Subteam

Related References

Related Issues And Bugs

Canvas requires a content selection method

Rationale: Why this element should be added

  1. Users want an increasingly dynamic and interactive experience on the web. Providing dynamic graphics is one way in which this can be achieved.
  2. In the past, Flash and Java have been used for dynamic and/or interactive graphics (among other things). Canvas provides a way to do that with HTML and JavaScript.
  3. There are already examples of it being put to use in the wild.
  4. SVG is used for an entirely different type of drawing that meets different needs and is substantially more complex to implement.
  5. Applicable Design Principles:
    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."
    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."
    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."

Rationale: Why this Element should not be added

  1. Research is required that proves that <canvas> is required, wanted or needed by USERS - not developers.
  2. Canvas is (one of many possible) solutions for dynamic and interactive graphics. For instance the behaviour of the canvas element could be applied to an existing element like img instead.
  3. Canvas focuses on a on potential solution rather than a problem.
  4. Adding this element will cause code bloat. A completely new element is not justified.
  5. SVG provides drawing functionality.
  6. Applicable Design Principles:
    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."
    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."
    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."

Related E-mail Threads

April 2007

July 2007

August 2007

October 2007

November 2007

December 2007

January 2008

February 2008

March 2008

April 2008

May 2008

June 2008

July 2008

January 2009

February 2009

March 2009

June 2009

July 2009

August 2009

September 2009

October 2009

November 2009

December 2009

January 2010

February 2010

March 2010

April 2010

May 2010

June 2010

July 2010

September 2010

October 2010

December 2010

January 2011

February 2011

March 2011

April 2011

June 2011

July 2011

Canvas API Mailing List

Purpose: to facilitate focused discussion on the canvas API and to encourage participation in that discussion from graphics experts and others who may not be members of the HTML working group (and may not want to be).

Search Markmail for Related E-mail

Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=AddedElementCanvas&oldid=11112"