[Access Module LC] Review Comments from SVG WG

Hi, XHTML2 WG-

This is a formal review by the SVG WG of the XHTML Access Module draft 
dated 26 May 2008 [1].  The SVG WG has reviewed the earlier comments [2] 
by Doug Schepers (hey, that's me!), and concurs with the comments.  We 
would like them to be considered as comments from the SVG WG. 
Additionally, we have a few more comments that we hope will improve the 
specification, and make it more suitable for use with SVG.


-------------
Host Language Integration

"The element defined in this specification MAY be incorporated into the 
namespace of the host language, or it MAY remain in the XHTML namespace."

Just as a note, this is a critical statement in the Host Language 
Conformance section, in order for SVG to effectively use this 
specification; we intend to incorporate it directly into our language. 
Please keep this section intact, and use the same or similar wording in 
all such specifications intended for possible integration with a host 
language.


-------------
Dependency on Core Attribute Collection

"Finally, XHTML Access requires the availability of the XHTML Role 
Attribute Module ... and of the Core Attribute Collection as defined in 
XHTML Modularization."

This is a problem for SVG, since the Core Attribute Collection [3] lists:
  xml:space ("default"* | "preserve"), class (NMTOKENS), id (ID), title 
(CDATA)

SVG doesn't have a 'title' attribute, and in fact, that is a less 
accessible option than what SVG does have: the <title> element.


-------------
Title and Description for <access> Element

The Access spec doesn't provide any means for the author to provide a 
title for the 'access' element itself, other than the implicit 'title' 
attribute in XHTML modularization.  The ability for an author to give an 
explicit explanation of the use of the element seems to be rather 
important for accessibility.

At the very least, SVG should be allowed to provide a child <title>, 
<desc>, and <tip> element.  It's not clear if this is allowed by the 
DTD/Schema you provide, but if there is a conflict, it should be relaxed.

I would go so far as to say that the 'access' element should explicitly 
allow child content elements, and that the host language should be able 
to specify their nature.  It would be even better if <title> and <desc> 
were part of the model.


-------------
Order of @targetrole and @targetid Values

It doesn't seem intuitive that the targetrole and targetid lists are 
unordered, but rely solely on document order.  For SVG in particular, 
document order is of a different nature than in XHTML; it determines the 
stacking order, not the sequential order.  We do understand that both 
unordered and ordered lists have use cases; therefore, we suggest that 
you introduce a way for the author to control the 'tabbing' order.

One way to accomplish this is to add an additional, optional attribute, 
  such as
   attribute 'order' = "document* | list"
where "list" sets the tabbing order to a strict sequence determined by 
the order of the values in targetrole and targetid.


-------------
Multiple Keys for Same Target Element

We believe that it would be useful for the author to be able to provide 
multiple @key values for triggering the same target element.  We 
understand that this could be accomplished by having multiple <access> 
elements with the same targets and different keys, but we believe that 
it would be more convenient for the 'key' attribute to take a 
space-separated list of values, with very little implementation 
overhead.  This may be better for i18n, where each key value could have 
localized options.


-------------
External Document Use

We believe there is a use case for referencing elements in another 
document, such as in a scenario where multiple frames are loaded. 
Please consider if an IDREF is the appropriate value for the targetid 
attribute, given this scenario.


-------------
Relax-NG Schema

Please provide a Relax-NG schema, as it makes integration much easier. 
This statement applies to all XHTML Modularization specs.


[1] http://www.w3.org/TR/2008/WD-xhtml-access-20080526/
[2] http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0052.html
[3] 
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_core_collection

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Received on Thursday, 10 July 2008 10:45:25 UTC