WAI comments 27 October 2004 Working Draft of SVG 1.2

Edited by: Jon Gunderson, University of Illinois at Urbana/Champaign

Last revised: $Date: 2004/12/21 22:39:33 $

Introduction

The comments are based on the October 2004 Scalable Vector Graphics (SVG) 1.2 Working Draft

The accessibility of SVG resources to people with disabilities is dependent on both a person with a disability being able to access accessible SVG content and the author ability to verify that the content they created correctly uses the accessibility features of SVG and accurately represents the information in the SVG resource.  The following are comments are related to the ability of the SVG 1.2 specification to allow users and authors to restyle SVG content, have available views of conditional content related to structure and text equivalents, be able to access SVG content through the keyboard alone and be able to play of animations at a slower rate or pause them. 

Colors

The ability of users to restyle content to meet their own needs is very important.  Both the Section 508 and the W3C Web Content Accessibility Guidelines Guideline 2 require that information cannot solely be encoded in color.  The User Agent Accessibility Guidelines Checkpoint 4.3 require that users be able to override author specified colors.  Simple visual transformations need to be part of a conforming SVG user agent to allow authors to verify they have not used colors as the only way to perceive information and allow common visual impairments, like color blindness to be able to have access to content. 

Color Features Requested

Gray Scale Viewing Option
Colors are converted to shades of gray
High Contrast Viewing Option
White or near white colors are converted to black or background color of the users choice for text content
Black or near black colors are converted to white or a color of the users choice
Luminosity Inversion Viewing Option
Colors stay true, but their luminosity is inverted (dark becomes light, light becomes dark)
Color Information Available through APIs
Color information must be made available through accessibility APIs (UAAG Checkpoint 6.1 , UAAG Checkpoint 6.2 and UAAG Checkpoint 6.4 ).  Since many assistive technologies do not support application specific APIs like the DOM, at least the color and content of text information must be made available through platform specific APIs.

Requested Document Changes

Additional Requirements in Section 10 Rendering Model section 10.1.6
Add a "gray scale" compositing operation to section 10.1.6 The comp-op property
Add a "high contrast" compositing operation to section 10.1.6 The comp-op property
Add a "Luminosity inversion" compositing operation to section 10.1.6 The comp-op property
Add new section in Section 10 Rendering Model related to accessibility
Describe disabilities benefited by these features
Allow users to designate a SVG 1.2 defined compositing operation be applied to the text element of an SVG document
Allow users to define a SVG1.2 defined compositing operation be applied to the entire SVG document

Benefits to People with Disabilities

Document Structure and Text Descriptions

SVG provides a means for authors to logically group elements of a SVG presentation and to provide text descriptions of the groups.  The text descriptions and logical grouping information is critical for accessibility by people with blindness and severe visual impairments.  The structures are also important for supporting efficient keyboard navigation to enabled elements for users who cannot use the mouse, this includes people with visual and physical impairments, and poor perceptual motor processing (often users who are older).  For authors to verify the text descriptions and structural information is correct it is very helpful if they can view the structure and text descriptions in a "text only" view of the SVG resource.

Requested Document Changes

Include Accessibility Features as part of SVG Examples
Add an example to Section 4.4 on how flowDiv amd other flowDiv elements can be used to create a more accessible SVG document
Describe accessibility features in the SVG example in section 4.15
Add new section in Section 4 FLowing Text and Graphics related to accessibility
User must be able to render a structured or outline view of text descriptions and text content view of an SVG resource in a conforming SVG user agent

Benefits to People with Disabilities

SVG DOM Implementation Issues

Future dynamic content accessibility is being discussed in the Protocols and Formats working group of the Web Accessibility Initiative.  Part of the DHTML Road Map for accessibility of dynamic content relies on the implementation of certain features in document object models.

Requested Document Changes

Add to Section 16.3, Section 15.1 and/or Section 3.12 all elements in the DOM include a focusable property
Having the focusable property is a big plus for accessibility. This allows JavaScript to request that an element receive focus as long as the attributes is set.
The focusable property should apply to "all" media, not just "visual".  Focus should be defined not by the meida, but whether the element can respond to user inputs.
Create a section on pre-defined xbl defintions that can be used by assistive technologies to understand sematics
sXBL provides a mechanism to theoretically define improved semantics through the creation of xbl definitions. They are also capable of defining what events get triggered by these new higher level document constructs.
What they do not do is define how the user agent maps these definitions to the accessibility interoperability layer. Basically, the definitions are adHoc and do not provide pre-defined mappings to standard Accessible roles on the target platform. An assistive technology would have to guess what the purpose of these definitions are. Also, there is inadequate state information capable of support dynamic web content.
nav-index
Although this was also included in CSS3, we replaced this with nextfocus attribute in xhtml 2. Please look at what the xhtml 2 working group has done with next focus.
State information
Accessibility is dependent on knowledge of state data (expanded, collapsed, checked, required, etc.) Is this information declarative in all cases? In xhtml 2, XForms and its model are tightly integrated whereby the XForms data model is bound to elements from which we can acquire the state data. SVG 1.2 is not specified as such.
The event handlers look like xml event handlers but it is not clear. XML events has a handler <description> which will be used to help with accessibility to tell the assistive technology what the purpose of the handler is. This is essential.
In section 1.2 of the sXBL specification you have DOM extension for sXBL. This is essential for accessibility.

Benefits to People with Disabilities

Device Independence and Keyboard

Many types of disabilities cannot use pointing devices for changing the state of enabled elements and manipulating controls.  Both Section 508 §1194.21(a) and the W3C User Agent Accessibility Guidelines Checkpoint 1.1 require that users have keyboard access to all the functionalities of a resource and W3C User Agent Accessibility Guidelines Checkpoint 1.2 to event handlers.  There appear to be some features of the SVG specification that allow the author to disable keyboard focus support for some objects and the document seems to be ambiguous on the need to support the keyboard in examples that describe only pointer manipulation of an SVG resource.  Enabled elements of an SVG resource include links, editable text fields and elements with user interface event handlers.

Requested Document Changes

Include Keyboard Examples in the following sections
Section 15.1.3 should also include example of the keyboard moving focus between enabled elements.
Section 15.2 discusses tooltips, a keyboard method should also be available to view tooltips.
Section 11.16.2 should also show keyboard event handlers
Add new section in Section 15 Element focus and navigation and Section 16 Events and Scripting related to accessibility
All enabled elements must have a means to be activated through the keyboard alone.
Proposed directional navigation feature, see Direction Navigation section.
Structured navigation of text elements and elements with text descriptions.
Add a shortcut key feature
xhtml 2 is developing a replacement for the accesskey attribute in html and we encourage SVG to adopt this same model.  The replacement provides for device independent binding as well as a description for accessibility. It also provides for binding of multiple condition types (device mappings). Currently, this is in the form of the <access> tag (is this a element or an attribute). The user agent needs to be able to provide a list of access mappings with descriptions to the user (shortcuts, accelerators, etc.)
Add a mouse-grid navigation requirement
Using the keyboard allow the user navigate geographically related groups of enabled elements in order to activate an enabled element.  Users would be able to successively narrow number of enabled elements in a group by selecting the geographic region of the enabled element the user wants to activate.  For example a 3 x 3 grid of squares could be over laid on top of a SVG object and the user could use the number keys to indicate what grid square the enabled element they wish to activate is in.  The grid they would be applied to the selected grid square and the user would then select the grid square with the enabled element they wish to activate.  This would continue until the element is the only one in the gird square and the element would then be given focus for the user to activate.
Add a directional navigation requirement
The directional navigation feature moves the keyboard focus to the nearest enabled element in the direction of navigation.  The following is a list of the 8 direction and the angles of navigation they encompass.

Benefits to People with Disabilities

Zooming

The user must have a means to zoom (scaling functions) the contents of an SVG resource through the keyboard.

Benefits to People with Disabilities

Accessibility of Animations and Multimedia

The W3C User Agent accessibility guidelines have several requirements related to animations and SMIL implementations.  It is not clear how captions should be added to SVG resources.  Are captions part of the media resource or should SVG be used to generate the captions.  It seems to that SVG would be an excellent technology to implement captions, since the user scan scale the size of the text captioning and with the other enhancements requested in this document the ability to change the color of rendered text.. 

A conforming SVG must be required to implement the following features:

W3C UAAG Requirements for Multimedia

Requested Document Changes

Add new section in Section 12 Media and UAAG checkpoints related to multi-media and animations

Benefits to People with Disabilities