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

On Sun, 07 Oct 2007 05:31:33 +0200, Doug Schepers <schepers@w3.org> wrote:

> 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?).

Indeed, it was a mistake on my part.


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

    http://www.w3.org/mid/OF1613FDFB.F9D50E53-ON8525735D.0053C2ED-8525735D.00547662@us.ibm.com


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

I've tried my best to make it compatible under the constraints outlined in:

    http://www.w3.org/mid/op.ty9tb104idj3kv@hp-a0a83fcd39d2.belkin


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

I'm not sure I understand this part.


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

Ok.


> But the other issue here is, what is the nature and status of your  
> proposal?  Is the scope only HTML5?

Not necessarily...


> When the proposal is done, what was the next step... to whom would you  
> submit the proposal?

I guess it depends on what the proposal says when it is "done".


> 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)?

The proposal didn't talk about SVG specifically, until after the SVG WG  
found out about it. It was updated in response to comments on www-svg:

    http://lists.w3.org/Archives/Public/www-svg/2007Oct/0018.html


> 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;

Agreed.


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

Namespaced attributes wouldn't validate against any current SVG DTD or  
schema, either.


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

Ok.


> 2) The patent policy on your work is unclear... are vendors subjecting  
> themselves to possible legal issues by implementating it?

How should I know? :-)

Seriously though, I don't see how it's any different from any other  
proposal that are sent to different WGs.


> This may not matter to Opera, since you work for them, but it certainly  
> matters to Microsoft.

Both are part of the HTML WG to which the proposal was sent.


> Can W3C publish it (it would seems that's your intent, but how are we to  
> know)?

Sure (as far as I'm concerned, anyway).


> 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 have the spec in local subversion repo. I guess I could move the repo to  
somewhere accessible (suggestions?); meanwhile an earlier version is  
available at:

    http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0106/aria-proposal.html


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

Can you suggest some text to include?


> 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;

Indeed, the algorithm that does accessibility mapping shouldn't look at  
roles that aren't related to accessibility.


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

Multiple roles are allowed, or at least that was the intent. Changed the  
quoted text to "For accessibility-related roles, the first supported role  
will be used; subsequent roles act as fallback roles.".


> By focusing only on your use case, ARIA (certainly a good one to focus  
> on), you seem to have inadvertently excluded other use cases.

On the contrary, I've went out of my way to make sure that the algorithm  
is compatible with processing of other roles later on.


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

Great!


> Thanks for your high-level perspective laid out in your proposal, I  
> think it will be valuable input.

Thanks for your comments.

-- 
Simon Pieters
Opera Software

Received on Sunday, 7 October 2007 22:51:05 UTC