Re: direct link to latest version of S. Pieters' ARIA Proposal

Hi, Simon-

I'd going to focus the discussion on the 'role' attribute for the time 
being, just to tackle one thing at a time.  I realize that the larger 
conversation needs to integrate both 'role' and the ARIA stuff in order 
to solve the whole issue your proposal attempts to tackle.

Believe me, I'm sensitive to the issue of getting it implemented under 
deadlines, but we also want a solid foundation to build on, and I don't 
think the gulf is so wide that we can't resolve this quickly.

Simon Pieters wrote (on 10/6/2007 11:54 AM):
> 
> The reasons why I started writing this spec are threefold:
> 
>   1. I wanted to write test cases for ARIA but couldn't because the specs
>      didn't have sufficient conformance criteria for UAs:
>         
> http://lists.w3.org/Archives/Public/public-pfwg-comments/2007JulSep/0000.html 

Your comments about the 'role' attribute should have been directed to 
the XHTML2 WG, where 'role' is being specified, rather than just to WAI 
(perhaps you also sent something to XHTML2?).


>   2. What was implemented in Firefox 2 didn't seem to match the
>      specifications and there was content that relied on it (in particular
>      the role attribute in the http://www.w3.org/TR/xhtml2 [sic]
>      namespace, which isn't defined anywhere).

Can you direct us to a thread that describes the differences 
(particularly on the matter of 'role'), and to the content?  It would be 
good to know the background.


>   3. The proposal of simplifying the ARIA syntax had to be specced
>      somewhere in order to get interoperable implementations.

Agreed.  That's the whole point of W3C.  And that you are helping 
promote and develop this work is very valuable.  At the same time, you 
should be cognizant that if it's specced differently in 2 different 
places, that only further confuses implementors and authors, and 
promotes friction in groups that should be finding ways to work 
together.  (I don't think you'll deny that your work derives from that 
of the XHTML2 WG for 'role' and from WAI for the ARIA stuff.)


> If SVG wants to support role, it seems that there are two options:
> 
>   1. Use the role attribute in no namespace on SVG elements.
> 
>   2. Use the role attribute in the http://www.w3.org/1999/xhtml
>      namespace on SVG elements.
> 
> The proposal previously defined the latter and now instead defines the 
> former.

I personally prefer the latter, but there may be technical challenges to 
it.

We all agree that chameleon namespaces are bad, and while there are not 
currently any specific interfaces defined for @role (thus causing no 
conflicts between X/HTML and SVG), I can easily imagine there could be, 
especially because the value is not a simple string, but a microformat 
comprising both list and namespaced sting structures.  As long as all 
languages support the same interfaces, all is good, but we should think 
about that carefully before endorsing the null-ns approach (for SVG).

In any case, were SVG to add 'role', namespaced or not, it would be 
referencing the XHTML2 Role Attribute Module, and would adhere to the 
functionality described therein.

But the other issue here is, what is the nature and status of your 
proposal?  Is the scope only HTML5?  When the proposal is done, what was 
the next step... to whom would you submit the proposal?

The proposal itself is not in W3C space, but published (in its current 
state) only on the html5.org site.  This isn't a turf war issue... it's 
a logistical one:

1) Only because it came up in the context of a larger discussion did the 
SVG WG find out about your proposal, but it specifically talks about how 
role should be treated in SVG... why didn't you ask the SVG WG to review 
it and comment (it would be easy; Opera is very active on the SVG WG)? 
I've raised one potential issue, but there are likely some others, and 
if we'd had a heads-up earlier, there would be more time before 
implementation-crunch and code freeze.  The SVG WG should be involved in 
all discussions of how SVG should behave; in the newest version of your 
proposal, you're essentially adding an attribute to all SVG elements 
(without the built-in XML namespace extensibility mechanism); content 
that conforms to that will not validate against any current SVG DTD or 
schema.  If you were working in W3C space, with a staff contact 
reviewing and publishing your spec, that staffer could (should) notify 
other relevant groups so they can review the spec (or at the very least, 
it could be searched for).

2) The patent policy on your work is unclear... are vendors subjecting 
themselves to possible legal issues by implementating it?  This may not 
matter to Opera, since you work for them, but it certainly matters to 
Microsoft.  Can W3C publish it (it would seems that's your intent, but 
how are we to know)?

3) Where is the history of the document, such that we can see the 
differences?  It would be nice to compare the 2 very different ways that 
you envision using @role in SVG.

I may seem like I'm being a stickler, but it's for pragmatic reasons, 
not just to follow mindless rules.


>> The second issue is probably to do with the values that the attribute
>> contains. These values are specified as CURIEs, as opposed to QNames,
> 
> I've updated the spec to allow CURIEs instead of prefixed names.

That's good to see.


>> The forthcoming version of the @role document will be more inline with
>> this approach, and perhaps when that has been made available (next
>> week) we can discuss what tweaks are needed to allow it to be
>> incorporated into Simon's document.
> 
> Is the new text ok?

I don't think it's a matter of the new text, but of how it is reference. 
  There are some differences in the details of your proposal versus the 
Role Attribute spec, and I think the editors of that spec would much 
prefer you simply reference that spec, rather than rewrite it.  I think 
some summary text would be appropriate, to give context to the other 
material.

A couple of differences between your proposal for 'role' and the Role 
spec jumped out at me (and there are probably more):

1) Your role identifier algorithm only allows for extraction of 
accessibility keywords, while the Role spec allows for an indefinite 
variety of keywords;

2) Both specs use space-separated lists of values, but yours only allows 
for one role ("The first supported role will be used; subsequent roles 
act as fallback roles."); the Role spec allows multiple roles to be 
defined in the same attribute (which stands to reason... one role may be 
accessibility oriented, while another may add other information to be 
processed by the UA, such as identifying it as a "search" input).

By focusing only on your use case, ARIA (certainly a good one to focus 
on), you seem to have inadvertently excluded other use cases.  Including 
the 'role' attribute by reference would eliminate that problem.

I'm not trying to discourage you: I think the energy and skill you're 
bringing to this work is great, and that it's important that you're 
promoting ARIA (and 'role'); you're acting as an integrationist, 
bringing different specs together to solve real-world problems, which is 
a vital and often-overlooked role.  But the fact that you have 
incompatibilities in your proposal as regards the individual specs you 
pulled together shows that it is better to work more closely with the 
authors of those disparate specs, so there's a clear communication of 
the use cases and requirements.

As I said before, the SVG WG will be talking about this next Tuesday, 
and we'll communicate with interested parties (including the XHTML WG 
and you) to address how best to bring in 'role'.  Thanks for your 
high-level perspective laid out in your proposal, I think it will be 
valuable input.

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

Received on Sunday, 7 October 2007 03:31:51 UTC