Re: @role in SVG

as I previously mentioned it appears that there has been no response  
from any naive users.

It's my opinion, already expressed that this change has not been  
presented in a means presentable to such an audience.

I am for instance not able to ask non-expert audiences for their  
opinion to feed back into discussions.

I do not consider it sufficient that the WG is excited by this  
possibility.

Rather than imagining the pros and cons.
Please take the opportunity to ask.

regards

Jonathan Chetwynd
Accessibility Consultant on Media Literacy and the Internet



On 10 Oct 2007, at 01:59, Doug Schepers wrote:


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

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
<svg
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:xhtml="http://www.w3.org/1999/xhtml"
   xmlns:aaa="http://www.w3.org/2005/07/aaa">
   <g xhtml:role="checkbox" aaa:checked="true">...</g>
</svg>

Pros:
* 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]

Cons:
* 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
<svg
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:aaa="http://www.w3.org/2005/07/aaa">
   <g role="checkbox" aaa:checked="true">...</g>
</svg>


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

Cons:
* 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 changed)

Neutral:
* 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 community.

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.


[1] http://www.w3.org/TR/xhtml-role/
[2] http://www.w3.org/TR/2006/WD-xhtml-role-20060725/#docconf

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