SVGT 1.2 Comments

Hi,

Apologies for taking a while to get around to this, but since moving from accessibility to haptechs and collaborative virtual environments, any accessibility work now has to be done in my spare time where there's usually 101 competing things.

On the whole, I was quite pleased with SVGT 1.2.  It's nice to see that the SVG WG took on board a lot of what we had to say about SVG 1.2 Full.  As a result, not only do I not have a lot of comments, but I'm hopeful that diagrams stand a chance of becoming accessible, and very soon.

I've put my comments below, grouped by section.  There's a couple at the end, that whilst being useful for SVG, and diagrams in general, could be useful in any doc format where color and fonts are used to modify the semantic meaning of the content using that formatting, e.g. XHTML, etc.

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.

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.

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.

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

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.
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.

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.
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.
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.
4. There needs to be a statement regarding text equivalents that represent any semantics conveyed by animation should be included in an SVG doc.

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.
2. As above, except for differing fonts.