RE: SVGT 1.2 Comments

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.




---------------------------------------------------------------------
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 19:25:36 UTC