- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jan 2010 13:15:54 -0800
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
- Message-ID: <63df84f1001071315n56827d4ag391311ea5c38b0bd@mail.gmail.com>
It seems to me that the semantics of the <iframe> element more closely matches the functionality of what you are looking for. The <source> element currently provides alternative values for the @src attribute of the parent element. However <canvas> has no @src attribute. / Jonas On Thu, Jan 7, 2010 at 12:08 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote: > 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/Austin/IBM@IBMUS* > Sent by: public-canvas-api-request@w3.org > > 12/15/2009 04:18 PM > > > To > > "public-canvas-api@w3.org" <public-canvas-api@w3.org> > cc > > Frank Olivier <franko@microsoft.com>, jcraig@apple.com, 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 >
Attachments
- image/gif attachment: ecblank.gif
Received on Thursday, 7 January 2010 21:16:51 UTC