- From: Chris Lilley <chris@w3.org>
- Date: Thu, 1 Feb 2007 15:22:55 +0100
- To: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Cc: public-cdf@w3.org, wai-liaison@w3.org
Hi Al, I took an action to respond to the comments on WICD Core sections 3,4 5 and 10. Other parts of your message will be replied to in other responses. On Friday, January 19, 2007, 7:58:18 PM, Al wrote: AG> WICD Core 1.0 AG> Section 3.2.1 AG> * No text equivalent in example Would adding <p>Text equivalent here</p> as a child of object respond to your comment? AG> * Clarification of the difference between "static" and "frozen" AG> rendering? The specification says: "The terms static and dynamic have the same meaning as in SVG. The term frozen implies a single conversion to a raster image." These terms are defined here (yes, they should be hyperlinked) http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers Note that static includes hyperlinking http://www.w3.org/TR/SVGMobile12/feature.html#Hyperlinking but not animation. Dynamic includes (as well as hyperlinking) animation, video, audio, discard (for streaming) and so on. The WICD Core specification also says "The term frozen implies a single conversion to a raster image." Therefore, a static rendering has no animation, audio, video but may have hyperlinks; its also zoomable. A frozen rendering is a one-shot, client-side rasterisation. Its almost the same as sending a raster image from the server, except that a) The client will render it at a suitable size (small for small screens, larger for larger ones, depending on the layout of the html page) b) Any system-language preferences will take effect when it is rendered, so if the SVG contains multiple linguistic alternatives, the users first-choice language will be used if available c) Its likely to be faster to download. For a frozen rendering, the client is likely to dispose of the original svg afterwards. The text alternative in the object element (see above) is more likely to be useful as an accessibility helper. Note that the helper application can reliably distinguish frozen, static and dynamic cases because the attributes are right there in the markup. AG> * Why are links in "static" and "frozen" not selectable, this would AG> be very useful to people with disabilities who may need the "static" AG> or "frozen" state to activate the link It sounds like what you are asking for is to pause a dynamic SVG. This is already possible. A static svg has nothing to pause (it has no animation). A frozen SVG is a one-time raster image and has no links to activate. AG> Section 3.2.2 AG> * Need to specify a keyboard model for activating interactive AG> elements in sprites (Assuming you meant 3.2.3 Scalable Overlay Objects (Sprites)) Why would this be different to any other content? Its simply styled differently (CSS relative and absolute positioning, CSS z-order). AG> Section 3.2.3 AG> * The use of transparency can be a problem for people with visual AG> impairments or visual processing disabilities. There needs to be a AG> way for users to configure the user agent to render the objects AG> separately and to restyle content to meet their perceptual needs. AG> For example rendering content separately in document order using a AG> high contrast stylesheet. The WICD Core spec says (in section 3.2.3) "Any transparent areas in the Overlay Object and in the XHTML root document must allow the layer behind to be visible." Are you arguing that it is better to have the overlaid object completely obscure elements underneath? Or are you arguing that there is a need to style the presentation without relative or absolute positioning (which can already be done with a user style sheet)? or are you referring to section 3.3.3 Transparency? AG> Section 4.0 AG> * No requirements for keyboard support for moving keyboard focus in AG> and out of objects (Maybe Section 6??) Section 4 is about child formats. As you note, section 6 is about focus handling. AG> Sections 4.2 and 4.3 AG> * Two separate standards for support for audio and video "pause", AG> "start" and volume control, Yes, XHTML 1 and SVGT 1.2 are separate standards and allow different degrees of control over timed elements. In SVG 1.0 and 1.1, timing was provided by the SMIL timing model. There were no time containers; the entire document had a single timeline. Comments from WAI noted that this did not allow pausing of individual elements. After discussion of the SMIL timing model with WAI, SVG responded that this was a limitation in SVG 1.1 and would be corrected in SVG 1.2 by using time containers. AG> in XHTML the user will have no control Correct. AG> and in SVG there is at least an option for users to have control 'at least an option' is not really correct. "A Conforming SVG Viewer must conform to the Priority 1 accessibility guidelines defined in [UAAG], and should conform also to Priorities 2 and 3." http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers Please see the priority 1 guideline 4.4 Slow multimedia (P1) http://www.w3.org/TR/UAAG10/guidelines.html#tech-slow-multimedia AG> * Users need control over playing AG> * Users should have an option to have a player with the controls AG> play audio XHTML1 should have timing. However, it does not, nor is CDF able to perform the rather substantial modifications to XHTML 1 to add it. Thus, as befits a specification about integrating different formats, CDF says what facilities each format provides. Authors can make use of this information. For example, if it is desired to play some audio, wrapping this up in an SVG rather than linking to it from the HTML allows the audio to be paused and restarted. AG> 4.4 Child content accessibility guidelines AG> * "For accessibility, conforming WICD Core 1.0 user agents must AG> provide the option of pausing, rewinding, or stopping video. See AG> section 3.2 of [User Agent Accessibility Guidelines 1.0]." AG> needs to be changed to AG> "For accessibility, conforming WICD Core 1.0 user agents must provide AG> the option of pausing, rewinding, or stopping audio and video. See AG> Checkpoint 4.5 of [User Agent Accessibility Guidelines 1.0]." Yes. Sorry about the copy-paste error introduced by the editor; we will fix this one (and the other instances where the wrong part of UAAG was referenced) AG> * A section should be included on user control of Volume, see UAAG AG> 1.0 Checkpoints 4.7 and 4.8 Agreed. How about "For accessibility, conforming WICD Core 1.0 user agents must provide the option of global control of volume. See Checkpoint 4.7 of [User Agent Accessibility Guidelines 1.0]. For audio in SVG, they must also provide the option of independent volume control of different audio sources. See Checkpoint 4.8 of [User Agent Accessibility Guidelines 1.0]" The second part is already required by SVGT1.2, but it does no harm to echo that requirement (and test for it) here. AG> Section 5 Hyperlinking AG> * Again support text equivalents in code examples The code example links to an SVG which consists entirely of an svg:text element. Why would this need a 'text equivalent'? AG> * Expected behavior or user agents in providing the alternatives for AG> selecting links We did not understand this point, can you rephrase? Links in both XHTML 1 and SVGT1.2 are inline, simple links with only a single target. There is no inline, compound link functionality (although SVG Full 1.2 plans to add this). AG> * Moving keyboard focus into and out of OBJECT elements (Section 6) (Assuming this is a reminder that this is covered in section 6) AG> Section 6 Focus Handling AG> * Keyboard support is very important for accessibility Yes, we agree (at least, for those devices that have them). Is that a general statement, or a specific comment? The WICD Core spec says "WICD compliant user agents must provide the ability for users with a keyboard or joystick input device (and without a pointing device), to navigate to any focusable element in the root document and all of its descendants." AG> * Need to make sure there is keyboard support for ARIA techniques for AG> interactive elements The CDF WG would like more detail on ARIA to be able to understand this comment. AG> * When authors set "focusable" to "skip" can the user interact with AG> any of the skipped content, like with a pointing device? Yes, a pointing device allows random access to any focussable content, while keyboard access is sequential (and thus, troubled by long lists). So if we expand the example in the spec to <p><a href="whatever">Link one</a></p> <object data="static-icon.svg" type="image/svg+xml" width="50%" > <param name="focusable" value="skip" /> </object> <p><a href="whatever">Link two</a></p> then the markup allows the user to move from link one to link two in a single step. This might be useful if static-icon.svg had, for example, a few hundred links. Without skipping, the user would ned to get past all of them, one at a time. AG> NOTE: If users can still interact with pointing devices or some other AG> interface then the user must have the ability to override author AG> setting to use the keyboard to navigate content. The WICD Core specification says: "In some situations, a user agent may still allow the user to focus on a child element which was removed from focus traversal. For instance, a user agent may allow a user to focus on a static SVG image for the purpose of saving it or interacting with it in other ways." AG> * Need concepts of "headers" or "sections" within compound documents AG> with support for keyboard navigation The CDF WG was unable to understand this comment. Given the following three svg children, where would the headers and sections be? a) An icon of a sun with a happy smiling face b) A map of all the ATMs in Tokyo c) An image showing the front covers of the three books you were about to buy, with the text "Your current selection" AG> Section 10 AG> * Support for users supply their own style sheet for rendering AG> content is not addresses. For example someone with a visual AG> impairment or visual processing disability could define their own AG> style sheet for rendering content and would want disable author AG> styling and use their own style sheet. How is this important issue AG> addressed in the specification? Its not addressed, no, as it does not add any other conformance criteria beyond those of CSS (unlike the three parts of section 10, which do add additional requirements). CSS already provides for user style sheets. CDF does not alter that. Thanks for your comments, please get back to us where clarification was requested and also let us know if our suggested text was ok, or if we have not fully responded to your points. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Thursday, 1 February 2007 14:23:14 UTC