AWERProcedia

Information Technology
&
Computer Science
1 (2012) 1492-1497

2nd World Conference on Information Technology (WCIT-2011)

Accessing Canvas Element in HTML5

Paniz Alipour Aghdam *, Reza Rafeh
Department of Computer Engineering
Malayer Branch, Islamic Azad University, Malayer, Iran

Abstract

Web users with vision disabilities cannot use graphical Canvas element in HTML5, with desired semantic and functionalities.
This is because Canvas is pixel-based and so is inherently inaccessible. This paper introduces Canvas element and its
applications, then, it reviews the researches done to make Canvas graphical element accessible in HTML5.

Keywords: Web accessibility, Canvas, HTML5, Use map attribute, nonav attribute, Navigable DOM , adom attribute

Selection and peer review under responsibility of Prof. Dr. Hafize Keser.

©2012 Academic World Education & Research Center. All rights reserved.

1. Introduction

Web is a rich source of information which its importance is constantly growing in all aspects of human life.
People with different abilities are involved in the group of this virtual world’s users. One user group is vision
impaired people. Based on the World Health Organization (WHO), roughly, 284 million people are visually
impaired worldwide, 39 million are blind and 245 million have low vision [1]. Vision disabilities have bad effects
on accessibility to existing information on the web pages. Originally, websites were used for text-based
interfaces, but very early (from MOSAIC) they became the epitome of graphic interface applications. In addition,
in modern Web applications, a large portion of the contents are either visual (e.g. pictures, graphics), or rely on
visual perception (e.g. tables, diagrams, etc.). As a result, Web Accessibility has emerged to make the Web
accessible to end users, regardless of the ability of browsing environment. The most useful technology devised
for blind users is based upon “screen readers”, i.e., software tools that “read” pages aloud [2][ 3].
The main issue in web accessibility is the lack of proper design of web pages and using technologies or
elements which are inherently inaccessible such as Canvas element in HTML5. In order to make such elements
accessible many researchers are working to come up with a solution. In this paper we give a brief survey of

*ADDRESS FOR CORRESPONDENCE: Paniz Alipour Aghdam, Department of Computer Engineering Malayer Branch, Islamic Azad University,
Malayer, Iran, Turkey Tel.: +98 21 44640048
E-mail address: alipourpaniz@gmail.com
 Paniz Alipour Aghdam & Reza Rafeh / AWERProcedia Information Technology & Computer Science (2011) 99-104

researches done in the area of canvas accessibility.

The rest of the paper is organized as follows. Section 2 reviews HTML5 and its new specification, Section 3
introduces Canvas elements, Section 4 investigates state-of-the-art Canvas accessibility and Section 5 includes
conclusions and some ideas to solve the Canvas accessibility without any interference of developers.

2. HTML5

The first draft of HTML5 specification published in 2008 by W3C [4] and is still under development. HTML5 is a
language for structuring and presenting content for the World Wide Web [5][6]. HTML5 covers the core markup,
as well as <video>, <audio>, <header> and <canvas> elements. The features are designed to make it easy to
include and handle multimedia and graphic contents in the web without having to resort to proprietary plug-ins
and APIs [5].

3. Canvas

The Canvas concept was originally introduced by Apple to be used in MacOSX website to create dashboard
widgets. Before the arrival of Canvas, using drawing APIs in a browser was possible just through plug-ins such as
Adobe plug-ins for Flash and Scalable Vector Graphics , Vector Markup Language in internet explorer.
Canvas is a pixel-based element which by using scripts enables dynamic rendering of graphics, e.g. graphs,
bitmap images, animations and games [7]. A canvas element by its width and height defines a display region,
which is then accessible through JavaScript using Canvas API drawing functions [8]. Even Canvas can be used for
construction of UI for web application[4][3]. When authors use canvas elements, they must also provide
contents that, when presented to the user, convey essentially the same function or purpose as the bitmap
Canvas. The content of a Canvas element, if any, is the element’s fallback content [9][10]. This is an example of a
canvas element:

<canvas width=”500” height=”500”>

<! - -Insert fallback content here - ->
</canvas>

3.1. Browser Support for Canvas

With the exception of internet explorer, at least versions earlier than IE9, all browsers provide supports for
HTML5 Canvas. In Table 1gives a list of browsers supporting HTML5 Canvas [2][ 4].

Table 1.List of browsers support Canvas

Browser Details
Chrome Supported in version 1.0 and greater
Firefox Supported in version 1.5 and greater
Internet explorer Not supported in versions earlier than 9
Opera Supported in version 9 and greater
Safari Supported in version 1.3 and greater

1493
 Paniz Alipour Aghdam & Reza Rafeh / AWERProcedia Information Technology & Computer Science (2011) 99-104

4. State-of-the-art of Canvas Accessibility

The first draft of HTML5 specification published in 2008 by W3C [4] and is still under development. HTML5 is a
language for structuring and presenting content for the World Wide Web [5][6]. HTML5 covers the core markup,
as well as <video>, <audio>, <header> and <canvas> elements. The features are designed to make it easy to
include and handle multimedia and graphic contents in the web without having to resort to proprietary plug-ins
and APIs [5].

4.1. Adding UseMap attribute to Canvas

The image map solution involves allowing the use map attribute on Canvas. It allows any element in the DOM
to serve as an image map area. In this way, an actual button element can be created in the DOM and attached to
a certain pixel region of a Canvas element, in which case the latter region would be keyboard focusable and
announced to assistive technology [15]. Adding Use Map attribute:

•Simplifies the task of adding interactive areas on a Canvas element.

•Provides a simple mechanism for authors to to ensure that interactive areas of a Canvas element are
keyboard navigable by default.
•Provides a simple mechanism to provide name/role/state and description information to user agents about
interactive areas on a canvas.
•Provides a simple mechanism to expose the focus of interactive areas to accessibility APIs and provide focus
rectangles without burdening the author.
•Provides a simple mechanism to add ARIA attributes to provide additional semantics to interactive areas on
a canvas.
•Makes it easier for authors to make interactive canvas content accessible Of course the there are also two
limitations:
•It imposes additional requirements on implementers.
•It is limited to basic image map shapes [16, 17].

4.2. Navigable DOM

The Navigable DOM concept provides a canvas alternative using a tree of equivalent elements as descendants
of the canvas content. Also this helps the assistive technology users to interact with the canvas content [15].
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. Also when a Canvas element represents
embedded content, the user can still focus descendants of the Canvas element (in the fallback content).
Therefore, authors can make an interactive Canvas keyboard-focusable [9]. Also in Navigable DOM by getting
help from Aria roles elements can be exposed to assistive technologies. Of course this behaviour has not been
implemented yet in any browser that supports Canvas except IE9. The latest version of IE (IE9) implemented the
HTML5 specifications Canvas element fallback concept, which means that it exposes the content inside a canvas
element to assistive technology users even when the browser supports canvas [11].

1494
 Paniz Alipour Aghdam & Reza Rafeh / AWERProcedia Information Technology & Computer Science (2011) 99-104

4.3. Adding nonav attribute to Canvas

Nonav Boolean attribute has a potential valid use, hiding DOM children of the Canvas from assistive
technology and keyboard navigation when this content is intended solely as fallback for browsers that do not
support Canvas at all [20,19].Some of its positive points are:

• Providing a simple mechanism for authors to use to ensure that content in the canvas sub-tree is not
available to users of user agents that support Canvas, when the content has been authored for the situation
when Canvas is not supported.
• Stating clearly what authors are required to do to provide accessible content when the canvas sub-tree is
used as a container for content providing interaction and semantics in browsers that support Canvas.
• Stating clearly how user agents, that support accessibility API, should process the sub-tree to support the
accessibility API
• Clarifying how focus management should be supported in the canvas sub-tree
• Disambiguating the case where canvas sub-tree content is not fallback.[20]

4.4. Adding adom attribute to Canvas

The purpose of the Boolean adom attribute is to indicate if the Canvas sub-tree is an accessible DOM sub-tree
which represents what is drawn on Canvas. If it is true, standard HTML elements may be used in the Canvas sub-
tree, however the rendering of the sub-tree is controlled by script through the Canvas API. When adom is set to
“True” the Canvas must be synchronized with the Canvas rendering. The main challenge is that the author also
uses the same <canvas> sub tree to represent fallback content. The fallback sub tree differs from the accessible
<canvas> sub tree in that the accessible <canvas> sub tree is designed to have its rendering directly drawn to the
<canvas> whereas the fallback tree is not [17,20]. This proposal was rejected as the default functionality of
Canvas fallback content is always mapped to platform accessibility API services [12].

4.5. The result of these proposals

HTML Working Group investigated the following three proposals. First one was using nonav attribute, second
one was using map attribute and at the last one was removal of Navigable DOM support in favour of using map.
Regarding the nonav attribute, the use case for nonav can be achieved through other means without loose of
convenience, but with a bit more verbosity.
Regarding the use of map support, image maps have limitations, just can be used for simple use cases, also
Browser implementers were lukewarm to adding Canvas use map support, high priority.
Regarding removal of navigable DOM in favour of using map, implementation of use map–only attribute
approach may be easier, has less conflict with fallback contents, also navigable Dom is implemented in at least
IE9. By all these discussions, HTML working Group decided to:

• Not to add nonav attribute

• Not to add Image map as an alternative to the Navigable DOM
• Navigable Dom will be retained in HTML5 [20]

1495
 Paniz Alipour Aghdam & Reza Rafeh / AWERProcedia Information Technology & Computer Science (2011) 99-104

4.6. Focus and selection accessibility

Previous sections include mechanisms to expose Canvas contents to assistive technologies. This part include
mechanisms specific to text editing such as focus caret and selection. Working on the area of this part is likewise
continued and some new proposals define and working on them [21].Two main topics which are being
investigated are Focus management and Caret and selection management. In Focus Management, when a
Canvas is interactive, authors should include focusable elements in the element’s fallback content corresponding
to each focusable part of the Canvas and Caret and Selection Management is used to render interactive content
that contains a caret or selection. It is essential that all users become able to follow the current caret or selection
position [22].

5. Conclusion

We gave a brief review of works done in the area of Canvas accessibility. Although some of the problems
seem to be solved, a number of challenges are still remained. These include modifying the spec and/or Canvas
API. Some researchers believe that Canvas accessibility problem has not been solved yet because most of the
developers cannot observe the rules. In making Canvas content accessible, images that are generated on the fly
,but there after not modified, a text alternative may suffice. For animated graphic demos, a description of the
demo is 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 alternative [12]. Thus, it seems that in the area of
interactive application-like content can be provided some other solutions for the problem of accessibility
without any interference of developers. One of the Ideas is to use what is drawn on the interface of Canvas and
image processing to change the drawn interface to an actual HTML interface. In this way blind people can be
aware of the UI on Canvas and consequently do not miss any information on it. In addition, it is supposed that by
getting help of parsing and interpreting scripts the semantics of Canvas can be provided to assistive technology
and people who use it.

References

1. World Health Organization, Visual Impairment &Blindness , http://www.who.int/mediacentre/factsheets/fs282/en/index.html.

2. N. DiBlas, P. Paulini, M. Speroni, “Usable accessibility” to the Web for blind users,” Proceedings of the 8th ERCIM Workshop: User
Interfaces for All, pp. 28-29.
3. E. Jitaru, A. Alexandru, Content Accessibility of Web documents. Principles and Recommendations, Revista Informatica Economica nr.
2(46)/2008, pp. 117-124.
4. P. Lubbers, B. Albers, and F. Salim, “Using the HTML5 Canvas API,” Pro HTML5 Programming, Apress, pp. 25-63.
5. Wikipedia, HTML5 http://en.wikipedia.org/wiki/HTML5
6. W3C Working Draft http://dev.w3.org/html5/spec/introduction.html#a-quick-introduction-to-html
7. Canvas Applications, Canvas demos http://www.canvasdemos.com/type/applications/
8.G. Jakus, M. Jekovec, S. Tomažič, and J. Sodnik, “New technologies for web development ” electrical engineering and computer science,
vol. 77, no. 5, 2010, pp. 273-280
9. R. Hawkes, Foundation HTML5 Canvas, springer, 2011
10. W3C Editor's Draft, Canvas element http://dev.w3.org/html5/spec/the-canvas-element.html

1496
 Paniz Alipour Aghdam & Reza Rafeh / AWERProcedia Information Technology & Computer Science (2011) 99-104

11. HTML5 Canvas Accessibility in internet explorer9

http://www.paciellogroup.com/blog/2010/09/html5-canvas-accessibility-in-internet-explorer-9/
12. Canvas Element Accessibility Issues, 2011
http://www.w3.org/html/wg/wiki/AddedElementCanvas
13. Testing for Accessibility, March 2004
http://msdn.microsoft.com/en-us/library/ms971307.aspx#accessibility_testing_topic1
14. Introducing Bespin, Mozilla Labs
https://mozillalabs.com/blog/2009/02/introducing-bespin/
15. Future Web Accessibility Canvas, 2010
http://webaim.org/blog/future-web-accessibility-html-canvas/
16. W3C, Add usemap attribute to the Canvas element, 2010
http://www.w3.org/html/wg/wiki/ChangeProposals/addimagemaptocanvas
17. W3C, Improve image maps and use them to make Canvas accessible, 2010
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom
18. Change proposals, Canvas accessibility nonav, 2010
http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibilitynonav
19. W3C working Draft, the Canvas element
http://www.paciellogroup.com/blog/misc/canvas/canvas-nonav.html
20. Working Group Decision on Canvas-accessibility and Canvas Usemap
http://lists.w3.org/Archives/Public/public-html/2010Dec/att-0136/issues-74-and-105-decision.html
21. W3C Editor's Draft, Focus Management
http://lists.w3.org/Archives/Public/public-html/2011Apr/att-0657/canvascarseldecision20110426.html#focus-management
22. W3C, Cange Proposals Caret Selection
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection

1497