SVGT 1.2 Comments

[notes on resend:
-  to SVG WG: forwarded without PF group discussion but for your 
consideration.  Will has
worked on access to diagrams and contributed to the review of the 
previous go-around.
- to Will and XTECH list: we've run through comment period and one 
extension.  I need the
meeting time to deal with other issues.  Will have to ask SVG group 
to do the collate/compare
with other input at this point.
- Al ]

-- original from Will

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.

Received on Saturday, 28 May 2005 15:40:18 UTC