- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 27 May 2005 16:36:32 -0400
- To: www-svg@w3.org
- Cc: wai-liaison@w3.org
<note class="inTransmittal"> Please accept the comments in this message as reflecting the rough consensus of the Protocols and Formats Working Group on behalf of the Web Accessibility Initiative. We don't claim to have understood all the details or prospective uses of the format, nor do we claim that all these comments are ready for a justDoIt instruction to the editor. We look forward to the opportunity to working with you including real-time dialog to resolve these issues, whether that winds up clarifying a problem or a non-problem. Al /chair, Protocols and Formats WG </note> Baseline: SVG tiny 1.2, url http://www.w3.org/TR/SVGMobile12/ <section> <title>Some outdated language survives in the prose discussion of WAI docs.</title> <quote cite= "http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers"> "The Web Accessibility Initiative [WAI] is defining "User Agent Accessibility Guidelines 1.0" [UAAG]. Viewers are encouraged to conform to the Priority 1 accessibility guidelines defined in this document, and preferably also Priorities 2 and 3. Once the guidelines are completed, a future version of this specification is likely to require conformance to the Priority 1 guidelines in Conforming SVG Viewers." </quote> <comment> This statement seems to indicate that UAAG guidelines are still under development. It is not clear what "Once the guidelines are completed, a future version of this specification" is refering to UAAG or SVG. </comment> </section> <section> <title>Inline references to key UAAG sections.</title> <topic> While the blanket references in Appendix D are necessary for completeness, the readers of this document will understand what you mean in various inline remarks about what processors should do if the pertinent sections of the UAAG10 are directly referenced at key points in the text. A few examples follow. </topic> <quote class="changeFrom" cite= "http://www.w3.org/TR/SVGMobile12/struct.html#DescriptionAndTitleElements"> For reasons of accessibility, user agents should always make the content of the 'title' child element to the 'svg' element available to users. </quote> <draft class="changeTo"> For reasons of accessibility, user agents should always make the content of the 'title' child element to the 'svg' element available at user option [UAAG10]. </draft> <note class="linking"> The putative link target would here be the Conditional Content Checkpoint and not the root of the document. http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content </note> </section> <section> <title>Exemplify accessible use</title> <comment class="general"> We are not satisfied that this document yet meets the requirement to demonstrate accessible usage in its examples. The following few examples show roughly the kind of improvements that should be made. They are neither exhaustive nor for that matter sufficient. We would be glad to work with you on upgrading the examples in response to this comment. </section> <comment cite="http://www.w3.org/TR/SVGMobile12/intro.html#defining"> The entity.svg example needs <title>Smiley Face</title> ... within the 'g' element (excluding the background square). Excluding because of the prevalence of this icon as a physical, pin-on button. This 'g' would be a good home for a <meta> reference using the SKOS vocabulary to associate this drawing with the Unicode smiley &x263A; Since this is an icon with a common connotation, SKOS-ifying it with some sort of a linkage to another representation of the same concept in widespread use would be of benefit in serving symbol language users and those with learning disabilities in general. It would be reasonable to give the outer 'svg' a 'title' and lose its 'desc' if you are concerned to be chewing up space. The smiley face is too clearly an idiom, a symbolic entity appealing to a stable colloquial connotation, to pass up annotating the face itself. </comment> <comment> Could not find where in the document it discusses user disabling play of audios and videos. No matter, this provision where mentioned should apply to the inhibition of animation as well and cite UAAG10 Checkpoint 3.2 at: http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-multimedia </comment> <comment> Examples in general use mouse-specific events. This should be upgraded in line with the intent-based event philosophy developed by the HTML WG. </comment> <example> <cite> 5.5 The 'desc' and 'title' elements </cite> <quote> >From example 5_12. <svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"> <desc xmlns:mydoc="http://example.org/mydoc"> <mydoc:title>This is an example SVG file</mydoc:title> <mydoc:para>The global description uses markup from the <mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para> </desc> <g> <!-- the picture goes here --> </g> </svg> </quote> <remark> Examples use an artifical arbitrary namespace. While the point is there to be made that SVG does not limit the markup used here, the preponderance of example should use realistic namespaces such as the mobile profile of XHTML. </remark> </example> </section> <section> <quote cite= "http://www.w3.org/TR/SVGMobile12/intro.html"> 1.1 For accessibility reasons, if there is an original source document containing higher-level structure and semantics, it is recommended that the higher-level information be made available somehow, either by making the original source document available, or making an alternative version available in a format which conveys the higher-level information, or by using SVG's facilities to include the higher-level information within the SVG content. </quote> <comment> <link rel="xhtml2:seeAlso" href="http://www.w3.org/TR/xag#cp2_11"> Good. Thank you. </comment> </section> <section> <quote> App D.4.2. Additionally, a Conforming SVG Authoring Tool must conform to all of the Priority 1 accessibility guidelines from the document "Authoring Tool Accessibility Guidelines 1.0" [ATAG] that are relevant to generators of SVG content. (Priorities 2 and 3 are encouraged, but not required for conformance.) </quote> <comment> Good, this is the sort of explicit inclusion in the conformance requirements that we have been asking for. </comment>. </section> <section> <quote class="changeFrom"> 1.6 shape. A graphics element that is defined by some combination of straight lines and curves. Specifically: 'path', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'. </quote> <draft class="changeTo" > 1.6 shape. A graphics element that comprises a defined combination of straight lines and curves. Specifically any instance of the element types: 'path', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'. </draft> <rationale class="forChange clarity"> The antecedent for 'specifically' is ambiguous without the change. It could be interpreted as "specifically a combination of 'path', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon' elements." </rationale> </section> <section> <quote> 1.6 User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers, and assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software. </quote> <comment> suggest <draft class="changeTo"> 1.6 User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers; used alone or in conjunction with assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software [UAAG10]. </draft> The citation of UAAG10 is linked. </comment> <rationale class="forChange"> The Home Page Reader browser notwithstanding, many readers will be confused if we use language that makes it sound as though we think that an Assistive Technology (by itself) is a user agent. It is much more of an OS extension and is part of the platform on which the mass-market browser is used. </rationale> </section> <quote> 6.4 ... An !important declaration within a presentation attribute definition is an error. </quote> <comment> Nice to see. </comment> <comment class="new add"> 8.3 path data For semantic entities such as flowlines in flowcharts, how should user information such as 'title' and 'desc' be associated with complex paths? How would you suggest that we get authors to observe this practice? </comment> <section> <title>Relating text to structure</title> <cite> 10.1 Introduction (text) </cite> <comment> It is not clear how a User Agent or Assistive Technology is to associate text that it finds with the structure of the scene in the graphic depiction. Diagrams often embed labels, but how is this semantic relationship (of the label text to the conceptual object labeled) to be recognized from the SVG representation? </comment> <cite> 10.11.2 The 'textArea' element </cite> <comment> At last! </comment> <section> <title>Media and alternatives</title> How would authors use this notation to identify alternatives for audio and video objects (as you see this notation being used)? <comment focusNext and focusPrev attributes. See the example in 13.9.1 where it is possible to do this. A nice feature to encourage would be a graphical means of setting this within an authoring environment. This is a job for a person, not a computer. Adobe would be a good starting point for this. <cite> 13.9.2 Specifying navigation </cite> <comment> This is a real step forward for accessibility! </comment> <comment> The examples read as if all delivery contexts support pointer events. The provision of alternatives to pointer events should be illustrated in the examples. To what extent does this specification support a two-step identification of user event handling with an intent-based event defined first and then bound in an over-rideable way to a device-specific UI event? </comment> <comment> <cite> Section 16. </cite> If an element is animated, is there a way to provide a static alternative other than the inital state of the animation? How can an AT perceive that a given animated whatever is in the state of ongoing animation? </comment> <comment class="inPassing"> http://www.w3.org/TR/SVGMobile12/changes.html provides the change list but only from the previous draft. A comparison with the incumbent full language might be more to the point for current users wanting to use this version to go mobile. </comment> <history class="originalPreparedBy"> -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk </history>
Received on Friday, 27 May 2005 21:00:17 UTC