Authors are encouraged to demonstrate compliance with WCAG principles per the methodologies laid out in this document, and the programmatic commitments laid out in WCAG 2.0. Authors of editing tools and document processors should also follow ATAG and UAAG. Canvas is used in a scripted environment: the terms "webpage", "page" and "application" are used interchangeably in this document.
Some Canvas use cases are controversial and unsupported by many browser vendors. WCAG applies to all digital content, Canvas products, included. Until vendors and W3C spec editors are able to show public support for the use of Canvas in web applications, authors will face an uphill battle for WCAG conformance when developing software traditionally reserved by browser vendors as part of the user agent experience.
WCAG 2.0 is a document copyrighted by the W3C. This document is not authored nor condoned by the W3C. This document is released under a public domain license by a United States corporation and is also released under the Creative Commons Zero license. Because of licensing considerations, this document references sections of WCAG with minimal inclusion of content. This document may be altered in the future, as it may still conflict with W3C copyright policy.
This document, along with the accompanying JavaScript implementation and tests, may be used under the terms of the CC0 1.0 Universal License. Thus anyone may reuse, modify, and redistribute them without restriction.
Canvas elements may incorporate a sub-tree with various DOM elements and/or WAI-ARIA attributes corresponding to relevant content. This method works well for browsers that do not support Canvas, and maintains an accessibility tree for browsers that do support Canvas and have met UAAG principles for exposing DOM data to assistive technologies.
Authors may use various means for input controls. The HTML input type button is the easiest element to use and support with Canvas in a manner that degrades gracefully. If, instead, fallback content is used within the Canvas sub-tree, authors are encouraged to use the HTML title attribute on the Canvas element to help convey the current control that is in focus or otherwise active or would be activated by further user input. This should be used in addition to rich ARIA and/or HTML semantics
When embedding a Canvas element inside of a button, the author may use CSS reset techniques so that the appearance of the button does not alter or interfere with the appearance of the Canvas element. The "appearance: none" CSS style attempts to do a reset. Other styles are useful as fallback techniques.
When embedding a button inside of a Canvas element, the author should use onclick hooks to help support for touch events, as well as redundant ARIA and strong native HTML semantics. Authors should be aware of focus semantics and test keyboard navigation through tabindex ordering. Many early canvas implementations fail to pass focus events into the Canvas subtree. Conforming implementations will pass focus events into the subtree correctly and thus require less work with focus management and event delegation.
Content placed in the Canvas sub-tree or placed adjacent to the canvas sub-tree should include sufficient information for users and developers to operate in an eyes-free user interface. The Canvas element itself should be marked with some usable information. The alt tag is not supported on Canvas, but title is.
The adjacent canvas tag demonstrates the use of ARIA tagging as well as the title attribute. It has not been drawn onto, and so is completely transparent.
Canvas may be ignored by assistive technology or otherwise marked as an "image". If the canvas is purely decorative, the image may be marked by ARIA semantics with a presentation role. Developer documentation, whether labeled semantically, included in a "data-" prefixed attribute, or included as HTML comments should describe the presentational attributes of the element, so non-sighted developers are given appropriate information to carry out development.
Canvas authors are encouraged to use the built in audio and video tags of HTML5. These tags may not be sufficient: in those cases, the Canvas drawImage method can be used to enhance the video tag. These tags may be included in the Canvas sub-tree.
Alternative content should be included either in the sub-tree or in a nearby sibling in a manner that can be accessed programatically. If the canvas tag is used for enhancement, authors should still use appropriate semantic markup on the video tag and place the video tag in the Canvas sub-tree or another tree in the same document.
All existing guidelines for audiovisual content apply to usage of the Canvas tag to enhance video and audio streams. Consider the Canvas tag as a layer which sits above audio and video. If the Canvas tag is used for the purpose of displaying images or audio controls to the user, be certain that all controls have been made accessible. As with most Canvas concepts, this is a complex task with many commitments.
Use ARIA attributes often. Redundancy may be helpful to support compatibility and the scripting environment. Use ARIA attributes within the DOM and with the scripting environment to ensure the state is constantly and consistently updated, and to assist with testing. Convey as much relevant information as is appropriate for the scene in the DOM, taking care to monitor the performance of your application.
ARIA, Semantic HTML and tabindex must be used by authors in a manner that enables effective programmatic access of interactive regions. Nodes should be made available in the DOM in a manner that can be traversed intuitively. Ordering the DOM logically is an easy method, ARIA provides additional attributes when the ordering of nodes in the DOM is insufficient. tabindex should be used extensively. There are always means of providing alternatives: Application vendors should consider multiple alternatives for users who are accessing the application in a manner that is eyes-free, hands-free, ears-free as well as for users impaired by computing delays or cognitive delay, distraction or multitasking.
See the maximum compatiblity example to target older browsers. Note the ARIA redundancy example to target more recent browsers.
Users may not have access to the color scheme the designer or author of the application intended. Designers and authors should incorporate high-contrast methods to make the scene usable under a variety of lighting conditions and access opportunities. This is particularly important for applications. If the color design is critical to the intent of the application, an alternative design should be made available to users who are not able to access the design as it was intended. This alternate viewing mode is essential to making the software accessible.
Scenes rendered in Canvas should carry sufficient contrast that users are able to interact with the scenes and understand author intent. Large text may have less contrast, as outlines may be more visible than smaller text. Logotypes may necessarily have less contrast, given their position as trademarked or otherwise standardized graphics. That said, efforts should be made to offer alternatives to assist in visibility cases. There may be instances where non-critical components have lowered visibility to enable better contrast for critical components. If high contrast requirements conflict with the aesthetic or functional purposes of the program, it is recommended that authors provide an option to users to toggle high contrast or other thematic modes.
Authors should support browser page zoom. Typical browser zoom levels are from 50% of the original size to 200%. Increasing browser zoom will likely decrease the amount of information being shown to the user at a given time. Zoom is used in a variety of situations, and authors are encouraged to support the full spectrum of browser zoom. Additionally, authors may provide their own zoom support in two methods: users may zoom in to specific regions of the application, effectively hiding other regions, or they may zoom the entire application, decreasing or increasing the virtual size of the display. Mobile devices often offer users the former option, desktop user agents often offer the later option. Both methods are useful to users. Both methods should be expected as a part of the user agent environment. Authors are strongly encouraged to support zoom up to 150% or otherwise provide a means to enlarge text content while maintaining a functional page.
Enabling users to select color themes may help the user to perceive the application. Allowing the user to set text margins, or otherwise restricting margins to no more than 80 consecutive characters (40 if CJK) may help the user perceive text. Controls or generous line spacing and large text features will help with readability.
In instances where the author is not able to convey information using HTML tags and CSS or circumstances otherwise lead authors to use Canvas instead of the browser’s render tree, careful integration of the DOM with the current visualization of the Canvas element is vital. Some user agents may consider all canvas elements as images. These are not accessible. Any text on a canvas that is intended to be shared with the user, or is a priority to convey to the user over other information on the page, should be available in the DOM. Users may need to customize the image for visibility through zoom, color and high contrast options. Non-visual interfaces will necessarily use the DOM. Keyboard and pointer interfaces should be supported. Pointer interfaces may include mouse, keyboard and touch. Keyboard interfaces may include keyboards, remote controls, braille devices, and other input devices. The terms Keyboard and Mouse are not restricted to the physical class of devices that their names are inherited from.
Canvas is not merely a dynamic image. It contains a sub-tree and can be made accessible. When possible, native widgets should be used. Canvas based user interface may be essentially to the application. Continue to provide fallback content that provides some subset of functionality or information. Do not use Canvas without considering accessibility.
Audio visual media may have multiple tracks. The ability of a user to toggle various tracks may help them to understand the content contained within each stream. If available, users should be able to turn off background sounds through controls provided by the author and/or the user agent. Though tracks may be intended to be played synchronously, it may help the user to edit, manipulate or listen to the tracks if they can be played independently. Consider your user and developer needs when working with and playing audio. Consider that audio may be experienced through other means, such as through purely visual means, or through interpretation or translation.
Ensure that all audio on the page can be stopped. Unless the user has expressed interest within an action to begin playing audio, or the automatic initiation of audio is critical to the function of the application or the intent of the user, do not play audio automatically. Always allow a user to mute the audio and to adjust audio levels, if this is supported by their user agent. If controls are not supported by the user agent, authors are encouraged to express that the active window is playing audio by changing the title of the page, so that users accessing multiple tabs may easily identify the application that is causing audible disruptions and easily close the application or halt the disruptions. Enhancements to ARIA and the
Authors should handle keypress events for interactive Canvas elements. Use tabindex to provide a route for users to focus on the element. Various input methods may be used, the author should not assume that one particular keyboard locale, or device will be used for text input.
Users must be able to navigate away from interactive Canvas elements. Do not trap the user from pressing ESCAPE or TAB to leave focus from the element. Some input elements may require processing ESCAPE or TAB differently. These input elements should inform the user as to how they can escape the keyboard trap. Many assistive technologies will re-map keyboard actions. Some interactive elements may require delegating keyboard focus to an input element to properly receive events.
If possible, all functionality should be available through the keyboard interface.
For interactive content, users should be able to pause or otherwise adjust timing. Time limits may be inaccessible.
Updates to the client may interrupt users. Use appropriate ARIA semantics and allow users to pause or otherwise manipulate the timing of updates.
Timing should not be required unless essential to the purpose of the application. In those cases, provide an alternative which does not require timing, with a subset of functionality or information. This could be a manual, for instance.
Users should be able to disable notifications.
Dynamic images may provoke seizures in certain viewers. Canvas may be updated very quickly. Web pages should flash anything faster than three times per second. It may be possible for a user to navigate through items, such as an image gallery, quickly, by pressing or holding keyboard buttons. Be aware that the user may inadvertently cause flashing or that another viewer may be present. It’s recommended that such navigation be rate limited. Other techniques may be used, such as switching to a carousel when navigation is moving, then zooming into a single image when the speed of navigation has slowed.
Users should be able to bypass widgets on the page. Long blocks of content may make it difficult or tediuous to reach other features. Use page anchors to help users jump through blocks of content.
Keyboard operations involve setting focus on a particular element. Focus should be indicated visually when the keyboard is active on an interactive element.
Alternate content should be easy to understand. Content should be written in plain language consumable by native speakers. Authors should not assume that the user can visually perceive the application: content should detail the application in way that is still relevant when the Canvas elements are not visible. Such content may be used for instruction or translation.
Focus on and input on elements should not immediately change the context of the page. Authors may provide an option to users to have such navigation change context, but this should not be the default behavior. As the user changes focus between elements, elements should be identified consistently; users may often cycle through multiple user interface elements on their way to finding the functionality they are seeking. Many tree based navigators or rotators, simply work through lists. List types include headers, ordered and bullet lists, as well as definition sections. Sections within the DOM should not arbitrarily switch between them. The consistency means it’ll be reasonably easy to navigate. Lists can also be handled with ARIA semantics, including tables. Table based lists may be complex and have less support than other list types. Lists benefit from the use of aria-activedescendant when used as part of a user interface component. Lists and menus are often collapsed in scripted pages. This is different than documents, where lists are visible and jump links are more likely to be used.
ARIA can be used to signify input errors, such as spelling and grammatical mistakes. Labels must be used for all interactive form elements present in a Canvas widget. Instructions should be provided when context is not otherwise available. Help may be made available for all widgets through the use of ARIA pointing to text nodes. Users should always be able to undo input.
Authors should strive for compatibility with a variety of devices and platforms. The DOM should be used to convey semantic and state information with the UA and in turn the OS. Authors should test on a variety of platforms. Issues with width, height, resolution and DOM access may be identified through testing. Many platforms have bugs and workarounds can be quite difficult. Set priorities. Use redundancy in semantic tagging. Scripting can help to automate some redundant tagging.