Fw: SVGT 1.2 Comments

[Reference:
http://lists.w3.org/Archives/Public/www-svg/2005Dec/0021.html   ]

Hi Al,

The SVG WG have commented on my comments regarding SVG accessibility. 
There's a couple of issues that Jon and UAAG need to be alerted to. 
Additionally, they didn't feel it was the place of SVG to include 
meta data regarding the link between color, fonts and semantics. 
This could possibly be a useful extension for the role tag, as the 
semantics for shapes within SVG are covered by title and desc, 
therefore the role tag would be duplication for this information.

Will
----- Original Message ----- From: "Robin Berjon" <robin.berjon@expway.fr>
To: <www-svg@w3.org>
Cc: <will-pearson@tiscali.co.uk>
Sent: Friday, December 02, 2005 7:05 PM
Subject: Re: SVGT 1.2 Comments

>[This message is forwarded from Scott Hayman (representing the SVG 
>WG), who is having problems posting to the list]
>
>Hi Will,
>
>Thanks very much for your thorough review of the SVG Tiny 1.2 document
>and the comments that you have sent in.
>
>>Section 5 - 5.5
>>1. The USE element should have a desc and title attribute that can
>>override those associated with the container element referenced by the
>>
>USE element.
>
>>Semantics are very much context dependant, and accordingly, whilst the
>>
>
>
>>same shape may be used in different areas of a diagram, the semantic
>>meaning it represents may change.
>>
>
>It was never our intention to prohibit the use of desc and title
>elements as children of the use element.  (Please note that these are
>elements, not attributes).  The spec has been clarified, not only in the
>prose, but also in the elements table, to say that the desc and title
>elements may be children of the use element.
>
>>Section 8 - 8.2
>>1. The PATH element needs to implement the title and desc attributes.
>>
>
>
>>As paths can be used to draw shapes, they can be used to convey
>>semantic meaning for which text equivalents are needed in order to
>>convey the full document semantics in non-visual renderings.
>>
>
>As for the use element, it was never our intention to prohibit the use
>of desc and title elements as children of the path element.  The spec
>has been clarified to say that the desc and title elements may be
>children of the use element.
>
>>Section 12 - 12.2, 12.3, 12.4
>>1. It would be useful to include an attribute, in the form of a URI,
>>that could be used to specify alternative content as a replacement for
>>
>
>
>>audio, video and animation content.  Not only would this allow those
>>with a sensory impairment, who cannot access a particular media form,
>>access to the semantic content conveyed by the multimedia, but it
>>would also be useful for those users who have limited bandwidth
>>connections, such as users of mobile devices using a cell phone
>>supporting a CDMA, GPS or GPRS connection, as their means of an
>>
>internet connection.
>
>While we agree that this would be a useful feature, it is not something
>that we think we can address adequately in the SVG Tiny 1.2 timeframe.
>We will be sure to capture it as a requirement for a future version of
>the spec.
>
>>Section 13 - No specific sub section
>>1. There needs to be some keyboard events defined.  Currently section
>>13 only mentions pointer events, and as pointers rely on parallel
>>presentation of interface elements to function, there's no keyboard
>>equivalent to pointers in serial output modalities, such as speech or
>>Braille.  Therefore, keyboard events need to be defined that effect
>>the currently focused element.  At a minimum these need to be:
>>1. an equivalent keyboard action to a mouse button double click 2. An
>>equivalent action to a mouse button single click 3. An equivalent
>>action to selecting a text element to insert text 4. An equivalent
>>action to exiting out of text insertion mode for a text element
>>
>
>The fact that there was no sub-section covering keyboard events in this
>section of the spec was an oversight on our part.  We have added such a
>section, which you will be able to review in the next working draft of
>the spec.  Thanks very much for catching this.
>
>Regarding your comment on the standardization of the equivalence of
>keyboard events, we feel that this is something that different user
>agents will need to map differently - i.e., it should be user agent
>dependent.  As such, we don't feel that it should be standardized,
>particularly in the SVG Tiny 1.2 spec.
>
>>Section 13 - 13.9
>>1. User agents need to be allowed to override the default tab sequence
>>
>
>
>>contained in an SVG doc.  I can foresee a situation arising which is
>>similar to the problems encountered with HTML user agents in the past,
>>
>
>
>>where focus is limited to actionable elements.  This could occur if a
>>doc author is only thinking about keyboard access in terms of
>>situations such as data entry, and falsely assuming that all users
>>will not need to use focus for purposes of document exploration.  In
>>these sort of situations I think it's fair to assume that only anchor
>>
>and text elements will be marked as focusable.
>
>While the working group feels that it is important for content
>interoperability that the default focus ring is fully specified, there
>is nothing in the spec that would prevent a user agent from implementing
>additional modes of navigation.
>
>>Section 13 - 13.9
>>2. The flat focus model could lead to inefficient navigation and a
>>loss of context.  Context could be gained by reviewing the
>>relationships between container elements and their child elements, and
>>
>
>
>>this could also speed up navigation by allowing keyboard users to
>>change focus between container elements at differing levels of
>>granularity, thereby skipping navigation between all the child
>>
>elements contained within those container elements.
>
>>Therefore, a suggestion would be to include navigational operations to
>>
>
>
>>adjust the hierarchical level at which the focus is currently set,
>>e.g. between nested G elements, and that directional or serial focus
>>operations then traverse elements at that level of the document
>>
>hierarchy.
>
>While the working group has spent much time trying to sort out this
>thorny issue, we were unable to come to any consensus as to how to do
>so.  As such, it is out of scope for SVG Tiny 1.2, but will be taken
>into consideration for a future version of the spec.
>
>>Appendix F - F.2
>>1. It mentions a text equivalent, but I feel this should be more
>>specific, and go as far as stating that it should be the semantic
>>meaning actually conveyed by the shape or shape component.
>>
>
>Unfortunately, this is not something that is covered in the User Agent
>Accessibility Guidelines 1.0 [1], the document we used to develop our
>accessibility guidelines and a document that we don't feel that we
>should go beyond.  Perhaps this is something that you can bring up with
>the working group responsible for that document.
>
>>Appendix F - F.2
>>2. I'm going to stick my head above the parapet here, and say I don't
>>mind the use of color to convey semantic information.  Color doesn't
>>convey semantic meaning in itself, but serves as a modifier that
>>modifies the semantic meaning conveyed by the shape that has been
>>colored.  Therefore, the semantic modifiers should already be taken
>>into account in the textual alternative.
>>
>
>Thanks very much for the comment.
>
>>Appendix F - F.2
>>3. It states that provision should be made for eight way navigation,
>>but the semantics of this clause seem to read as though they're only
>>directed at document authors.  I think this needs to be reworded to
>>cover not only doc authors, but also authoring tools and user agents,
>>unless something specifically goes into ATAG and UAAG.
>>
>
>While this section is specifically aimed at how to create accessible
>documents, your point is well taken.  As such, in F.1 we have added
>navigation to the list of accessibility issues that need to be taken
>into consideration when designing authoring tools.  As well, we've added
>a section to F.3 to cover user agent accessibility guidelines for rich
>navigation.
>
>>4. There needs to be a statement regarding text equivalents that
>>represent any semantics conveyed by animation should be included in an
>>
>SVG doc.
>
>As per our response to your first comment in the section, this is not
>something that is covered in the User Agent Accessibility Guidelines 1.0
>[1], and is a document that we don't feel comfortable going beyond.
>Perhaps this is something that you can bring up with the working group
>responsible for that document.
>
>>Ideas not related to any particular section 1. To enhance access to
>>the semantics conveyed by color, there could be some sort of array
>>contained within an SVG doc.  Each array element would contain two sub
>>
>
>
>>elements that represented a specific color and it's associated
>>semantics.  This would allow user agents the ability to look up
>>semantics related to a specific color, and could be extended beyond
>>SVG to XHTML and other mark-up languages.  This assumes that the
>>relationships between color and semantic meaning will remain constant
>>throughout the scope of a document, but should they change within the
>>scope of a document then there's various techniques that could be used
>>
>
>
>>to convey this change, the simplest of which would just be to replace
>>
>the associated semantic meaning in the array.
>
>We believe that the semantics of colours for a particular document is
>something that content authors would need to specify in the content
>itself - e.g., a legend on a map.  In many SVG documents, colours are
>not tied to any semantics and can change over time with the use of
>animations.  As such, we don't believe that this is something that
>should be addressed in a general purpose graphics language like SVG.
>
>>Ideas not related to any particular section 2. As above, except for
>>differing fonts.
>>
>
>Much like colour, we believe that the semantics of fonts is something
>that content authors would need to specify in the content itself.  As
>such, we don't believe that this is something that should be addressed
>in a general purpose graphics language like SVG.
>
>Please let us know within 2 weeks if these responses don't address your
>concerns.
>
>Best regards,
>Scott Hayman
>on behalf of the SVG WG
>
>[1] http://www.w3.org/TR/UAAG10/
>
>
>
>---------------------------------------------------------------------
>This transmission (including any attachments) may contain 
>confidential information, privileged material (including material 
>protected by the solicitor-client or other applicable privileges), 
>or  constitute non-public information. Any use of this information 
>by  anyone other than the intended recipient is prohibited. If you 
>have  received this transmission in error, please immediately reply 
>to the  sender and delete this information from your system. Use, 
>dissemination, distribution, or reproduction of this transmission by 
>unintended recipients is not authorized and may be unlawful.

Received on Saturday, 3 December 2005 20:11:07 UTC