- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 9 Oct 2008 21:14:13 -0400
- To: Doug Schepers <schepers@w3.org>
- Cc: www-svg <www-svg@w3.org>, "w3c-wai-pf@w3.org PF" <w3c-wai-pf@w3.org>, W3C HTML Mailing List <www-html@w3.org>, Hypertext CG <w3c-html-cg@w3.org>, Shane McCarron <shane@aptest.com>
[distribution note: Cc: to Hypertext CG in case there are other groups interested in this. Cc: to Shane McCarron as IMHO the most knowledgeable editor of [3] in case what I said needs any correction in that regard.] On 9 Oct 2008, at 1:33 AM, Doug Schepers wrote: > Hi, Al- > > Comments inline... > > Al Gilman wrote (on 9/28/08 4:47 PM): >> >> Reference: string-search for all instances of 'aria:' in >> the one-page version of the 15 September 2008 draft >> http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/single-page.html >> >> Repair may be implemented by removing the initial substring >> 'aria:' from >> the indicated symbols. > > I've removed all the offending prefixes. [1] > > This does raise another question, which I think the WAI-ARIA spec > should > address: who "owns" the list of role values? This is worth further discussion. So far, the practice has been that W3C Working Groups contemplating creating predefined values for @role have coordinated their lists. When this was just XHTML2 and PFWG, that's just one conversation. The attribute is artfully constructed so that format-defined and crowd-sourced tokens may coexist. I think that it was the CURIE spec where I read that formats may predefine unprefixed tokens. > Since @role is intended > for general use in addition to use with ARIA (as per the XHTML Role > Attribute Module [2]); there is a list of roles [3] (a compilation, > perhaps?)... is this meant to be a registry of roles? It is meant to be a compilation, with the controlling documents being the Role Module specification and the WAI-ARIA specification. Nothing in the way that this coordinated list has been developed would preclude other Working Groups from joining the conversation. But at present there is no 'registry protocol' for getting new definitions included. The current technique is entirely by 'operational procedures.' That is to say: Someone publishing @role value definitions a) SHOULD not re-use tokens that have been defined already b) MAY put their definitions in a namespace and expect users to identify them by URI/IRI/CURIE, or c) MAY provide that these tokens should appear literally as is, provided that they don't step on the tokens already defined as @role values in existing W3C Recommendations. > > If I specify roles in an SVG spec, and they overlap or conflict with > roles define in some other language, how is that resolved? 1) you should have checked W3C specs for existing definitions for those @role values. 2) the Working Group on whose @role value you are stepping should notice this and object to the advance of your document. >> The WAI-ARIA approach for indicating role values that are defined >> in the WAI-ARIA spec is that they appear without a colon-ized prefix. >> >> <quote cite="http://www.w3.org/TR/wai-aria/#ua_role"> >> >> The rules of the host language are used to detect that an element >> has an >> attribute with attribute name of "role" and to identify the attribute >> value string for that attribute. >> The attribute value string for that attribute is broken into a >> sequence >> of whitespace-free substrings by separating on whitespace. >> The substrings are compared in a case-sensitive comparison with >> all the >> names of concrete ARIA roles as defined above. >> The first such substring in textual order that matches the name of a >> concrete ARIA role is the name of the applicable ARIA role. >> >> </quote> > > Given that the XHTML Role Attribute Module specifies a CURIE for its > value, Note that SVG does not define its @role attribute as only taking CURIEs as values. In fact, we rely on this difference. However, the CURIE syntax provides that host languages may define un-prefixed tokens. http://www.w3.org/TR/curie/#s_syntax > I think it could (evidently) lead to confusion about whether ARIA > role values are prefixed, so I would suggest that > you make it explicit > that they should not be, if that's your firm intent. It is, and we have. That is the only way to read the four-step algorithm for identifying the applicable ARIA role quoted above. > However, there may be a use case for the prefix, if the matter of a > "role registry" isn't cleared up, so maybe it shouldn't be outright > forbidden... It isn't outright forbidden. Anyone can create a namespace into which the ARIA role names are imported and use CURIEs to indicate the points in that space. We even contemplated coining a 'home namespace' for the ARIA attributes for those creating documents in formats that haven't implemented WAI-ARIA. But we concluded that this would sow more confusion among authors who are in host languages that do implement WAI-ARIA, and hence should use the un-prefixed names, than it was worth. Our defense against collisions here is twofold. 1) W3C specifications avoid collisions by the operational procedures outlined above. 2) Third parties coining @role values which step on W3C-defined @role values are defined to be in the wrong; that is, in violation of the WAI-ARIA spec in the case of ARIA roles. ARIA-implementing browsers will process these elements as if having the like-named ARIA role, and ARIA-implementing authoring tools will complain if the ARIA role properties and behavior are not actually present. What this amounts to is that one can mix host-language-defined role values and linked-to-definition-by-CURIE role values without fear of contradiction. When we get to implement WAI-ARIA in SVG we want at least the @role value vocabulary indicated in [3] (as updated as the source specs mature) to be recognized as predefined in the implementing SVG spec. SVG could extend the list, hopefully in consultation with the other groups coining @role values, so long as you don't re-use tokens. Other forms of extension could yet be considered. WAI-ARIA has hopes of allowing and employing role extension in a later version, beyond 1.0. >> [...] > > [1] http://dev.w3.org/SVG/profiles/1.2T/publish/ > [2] http://www.w3.org/TR/xhtml-role/ > [3] http://www.w3.org/1999/xhtml/vocab/ > > Regards- > -Doug Schepers > W3C Team Contact, SVG and WebApps WGs
Received on Friday, 10 October 2008 01:15:05 UTC