Request for Feedback: @role in SVG


I'm forwarding this from the SVG, CDF, and XHTML2 mailing list, where we 
have been discussing this issue.  We would like to reach some sort of 
concordance with HTML 5 on this issue, so please send your feedback to (not this list, where I think it's off-topic).

Many Thanks-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

-------- Original Message --------
Subject: @role in SVG
Date: Tue, 09 Oct 2007 20:59:43 -0400

Hi, SVG community-

The SVG WG likes the functionality and extensibility that the 'role
attribute affords, and the potential for increased accessibility, so we
do want to include it in SVG (and to see it implemented as soon as
possible, so authors can use it right away).  We've talked about how
best to do so, and we'd like to solicit opinions from interested
parties, including the other Working Groups involved, implementors, and

To summarize the options, we can include the 'role' attribute in the
XHTML namespace, or as a native null-namespace attribute.  Each approach
has benefits and problems.

1) XHTML Namespace
   <g xhtml:role="checkbox" aaa:checked="true">...</g>

* does not require any changes to SVG syntax... automatically available
via XML's innate extensibility mechanism
* conforms to current version of the Role spec [1]

* is slightly harder to author (requires working knowledge of
namespaces, or good voodoo skills)
* differs in syntax from how it would work in XHTML and HTML5 (so may be
harder to learn, and possibly to implement)
* more verbose

2) Native Non-Namespaced Attribute
   <g role="checkbox" aaa:checked="true">...</g>

* more similar in syntax to XHTML and HTML5 (easier to use and maybe
* less verbose
* maybe less error-prone for authoring, mash-ups, compound documents

* would require a change to SVG (see details below)
* would require change to Role spec to allow "host language" (SVG) to
incorporate it into its own language (note that there is precedent for
this in the previous version of the Role spec [2], not sure why it was

* still requires knowledge of namespaces, but only for including ARIA

Changes Required to SVG Specifications

As mentioned, including 'role' via the XHTML namespace requires no
changes to SVG (though would benefit from a Note on the details), but I
understand that some might not find it the cleanest or most
author-friendly solution.  So, the SVG WG is open to include it directly
in the SVG language, if that's the solution the community feels is best
(and if it is allowed by the Role spec).

If we are to include it in the language, just how we do so depends on
which version of SVG.  We can't add it as a feature to SVG 1.1 or before
(adding features that change conformance to a past version is not
allowed in the W3C Process), but we could do so for SVG 1.2 Full with
few or no problems.  There is a chance we could do it for SVG 1.2 Tiny,
because it's not yet in PR, but adding features at this late stage might
not sit well with the standards community (though the implementors on
the WG assure us that merely adding an attribute is trivial).  We would
like to do it, but not if it's seen as unacceptable by the standards

Another factor is that we don't want to be dependent upon the Role
Attribute  and the CURIE specs for our Rec-Track exit criteria.  But
neither do we want to specify it separately (or differently) than that
spec.  A possible solution is that, for SVG 1.2 Tiny, we would include
it as an attribute whose value is a space-separated list of strings, and
when the Role and CURIE specs are more mature, in the SVG 1.2 Full
timeframe, we would change the specification of 'role' to refer to those
specs.  This is not a very clean solution, but it would get the 'role'
attribute out there, and let authors create content now in as easy a
manner as possible.

Changes Required to Role Attribute Specification

As mentioned before, for this to happen, the Role Attribute spec would
need to explicitly allow SVG to do it.  We'd like feedback from the
XHTML2 WG on this.  It would be ideal, perhaps, if the Role spec
optionally allowed the values to be strings instead of CURIEs (as
specified in a host language), but that may be a bridge too far.

Prompt feedback on this issue would be greatly appreciated.


-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI


Received on Wednesday, 10 October 2007 13:19:22 UTC