Fw: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

Ian, others,

In addition to employing a shadow DOM to produce an accessible canvas
solution there may be situations where that approach will not be
appropriate depending on the heavy graphics nature of canvas. In those
scenarios it will be necessary to provide alternative content. So, we are
investigating building off Dave Singer's media query approach to
accessibility for the video tag.

In this scenario we would need to introduce a visual media type to provide
alternative visualization in the HTML markup whose selection would be based
on properties defined in the Access For All standards effort. The caveat
being the following:

The HTML 5 specification defines a source element which specifies, although
not implicitly stated, a complete file. Today much of the visual content is
delivered as fragments and, like a mashup, we will need to pull in
fragments for alternative content that can be used in the markup in place
of canvas. A concrete use case would be a grid which replaces a pie chart.
An entire page is not required for that.

If it is visual content we would need to decide whether to store it in an
IFrame in some instances:

- Full pages
- Fragments where there may be id conflicts or where security will be a
concern

Do you see any issues/concerns with:

-  Introducing a visual media type to HTML 5
-  expanding the specification to ensure that source fragments, for visual
modalities, are allowed and allowing the author to specify whether the they
be stored in an IFrame.

Thanks,

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 01/07/2010 11:53 AM
-----
                                                                           
             Richard                                                       
             Schwerdtfeger/Aus                                             
             tin/IBM@IBMUS                                              To 
             Sent by:                  "public-canvas-api@w3.org"          
             public-canvas-api         <public-canvas-api@w3.org>          
             -request@w3.org                                            cc 
                                       Frank Olivier                       
                                       <franko@microsoft.com>,             
             12/15/2009 04:18          jcraig@apple.com,                   
             PM                        janina@rednote.net                  
                                                                   Subject 
                                       Proposal: Canvas accessibility and  
                                       a media querries approach for       
                                       alternative content                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Based on feedback from David Singer and James Craig I am modifying my
previous proposal (this is not spec. ready) to see if we can get on a
similar page to what is being proposed for accessible media:

<source media="accessibility(caption:no, audio-description:yes)"
src="A">

Here are some challenges:

1. The existing CSS 3 media queries does not support the accessibility
properties provided. A suggestion would be to make an exception to allow
the user agent to provide the information either internal to the browser or
via HTML 5 local data storage. The current HTML 5 specification requires a
direct match.

2. The source element require a source file vs. a local fragment. Should we
consider integrating code fragment vs. entire files? If we are going to
pull in files then they should be embedded in an IFrame in the browser for
security reasons.

3. We need a strategy for best fit of CSS media queries for accessibility.
We may not get a perfect match but if we can get close we should try to.

With these caviats in mind here is a draft of what I am proposing that I
would like to discuss Thursday this week:

1. The canvas element shall support zero or more child elements
representative of the default accessible rendering (if possible) for the
visual canvas modality and alternative modal renderings based on media
types and accessibility properties. The media types should be based on
those currently specified in the HTML 5 specification in addition to a
subset of those provided in the the IMS Global Consortium Access for All
Meta Data V3 default model. The default mode would be representative of the
shadow DOM. In many instances a more usable solution may require an
alternative.
2. Create new media elements for canvas that support different modalities
applicable for accessibility.

Define new media elements that may be contained in canvas: called visual

- default - represents a shadow DOM alternative for the default media type.
The intent is to allow the script author to bind accessibility information
using standard HTML elements, with ARIA semantics, to the visual rendering
in canvas. The default element would be a child of canvas but would in no
way be rendered by the browser. All rendering would be on the canvas
through the use of Script provided by the author. canvas should be
considered a form of visual media element.

- visual - this is an alternative visual rendering for canvas that would be
used if the default visual view is inaccessible based on the accessibility
requirements requirements submitted by the author,

Both default and visual support aria-activedescendant where the id refers
to a valid id in the child DOM.

In the future, and as the web expands in its capability provide other media
types such as <tactile> and <olfactory>.

3. Allow canvas to provide an audio media type as a child if the the user
prefers an audio alternative - such as a self voicing application for a
visually impaired user.

4. Modify the source attribute for the media attribute (included with the
source element) as follows as defined in the Access For All version 3
specification:

4a. adaptationtype - Provide one or more of the following adaptation types:

audiodescription
caption
signlanguage
highcontrast
transcript
alternativeText
longDescription
haptic
e-book

4b. ATInteroperable - A boolean that content support interoperability with
operating system platforms through the use of strong host language
semantics or the use of WAI-ARIA for web content. If a plug-in is provided
(say a Java applet) the application must support interoperability through
the use of a recognized Accessibility API.

4c. languageOfAdaptation - value determined by [ISO 639-2:1998]

4d. EducationLevelOfAdaptiaon - Define a range based on the adapation
(Integer)

4e. ControlFlexibility: Provide one or more of fullKeyboardControl,
fullMouseControl

5e. DisplayTranformability:One or more of the following:

fontSize
fontFace
fontWeight
letterSpacing
wordSpacing
lineHeight
foregroundColour
backgroundColour
cursorPresentation
highlightPresentation
layout
structurePresentation

6e. Harzard: One ore more of the following:


flashing, sound, olfactory, motionSimulation


We can use a subset of these.

5. View Selection should be based on a user preference in the browser based
on the mode and type preference supported in HTML 5. If nothing is set, the
shadow DOM is used for the accessibility mapping when provided. The user
agent should select the first view that fits the user's request. Platform
accessibility API may also be used to configure the view selection. Note:
is no alternative view is provided to meet the preferences the view reverts
back to the canvas + shadow DOM view. The shadow DOM is also optional.

6. The canvas tag shall include a script method to set the bounding
rectangle for a given valid id in the shadow DOM. This would allow
the browser to provide the bounding rectangle for the id in the shadow DOM
when it receives focus. The rectangle should be relative to the location of
the canvas element and would be converted to screen coordinates in the
accessibility API and would allow the canvas to move without changing the
location of the shadow DOM element. This will allow screen magnifiers to
determine the visible focus. (Ideally it would be nice to also do this via
XPath statements vs. id)
7. All allowable HTML elements in the shadow DOM shall support the tabindex
content attribute and ARIA attributes.
8. The shadow DOM should include all renderable HTML elements save standard
input controls. The reasoning being is these
controls are user agent managed in terms of the keyboard and would likely
conflict with canvas keyboard management.


The format would look something along the following lines:
<canvas>
  <default aria-activedescendant="foo">  /*Since canvas is visual this is
the default mode. It contains the shadow DOM*/
     <div role="toolbar">
        <div role="tab" tabindex="-1" id="foo">
        </div>
     </div>
  </access>
  <visual type="text"> /*Here we could place a long description or an
alternative aria-enabled widget*/
  </access>
  <audio>
  </access>
  <tactile> /*This is in access for all and we could lose it for now for
obvious reasons*/
  </access>
  <olfactory> /*This is in access for all and we could lose it for now for
obvious reasons*/
  </access>
  <visual type="signlanguage">
  </access>
</canvas>


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist