Re: role cardinality [was: Re: ARIA Proposal ]

On Thu, 27 Sep 2007 18:55:16 +0200, Al Gilman <Alfred.S.Gilman@ieee.org>  
wrote:

> I used the latter URI; sampled with an HTTP response quoting a  
> last-changed date of
> 20070926T12:58:08
>
> * only one role value is a problem
>
> The processing of only one 'role' value together with the definitive  
> "this is how
> these attributes are to be processed" present a problem.
>
> Yes, the WAI-ARIA 1.0 proposition has in it the design guideline that
> only one of the ARIA roles will be present in the role attribute for
> any given element.
>
> a) this has been regarded as a temporary limitation that could be
> relaxed in the future.

This is also true in the proposal.


> b) this specifically allowed for there to be both an ARIA 'menu' role
> and an XHTML 'navigation' role on the same element. In other words,
> there are use cases for mixing and matching the roles from the two
> vocabularies. Dumping the XHTML role values into the ARIA namespace
> and then limiting to one is not the same functionality.

The reason the proposal says to only use the first value is because it is  
unclear what browsers are to do with multiple values at this point.  
Firefox 2 only looks at the first value, and unless someone can explain  
exactly how to implement multiple values, Firefox 3 and Opera 9.5 will  
likely do the same.


> * forward reference to HTML5 for the definition of 'token' in the
> list-of-tokens value for the role attribute is a problem.

(This doesn't make sense in context and is duplicated below; I'll ignore  
it here.)


> * possible way out of the problem
>
> Make the specification a little more of a selector-based rule. That
> is to say, define the space of attributes (as now) and the
> 'first-found from [limited range of sources, maybe only the ARIA
> roles]' query and then say that values so found are to be processed
> as described here.

Ok, that might make sense. It makes it slightly more complicated since we  
want to pass along something also when there are no matches, but it's  
certainly doable.


> Don't say "other attributes are not to be processed in this way."

I'll probably drop those notes in due course; they are there currently  
because of what was implemented in Firefox 2 or what the existing specs  
seem to suggest.


> Do
> say "the processing of other attributes, and subsequent tokens found
> in these attributes, is not given, not constrained by this proposal."
>
> Can the browsers live with this?

I wanted to pin down exactly what browsers are to implement right now. The  
intention is not to limit what can be implemented in the future or by  
other apps.


> In addition..
>
> * forward reference to HTML5 for the definition of 'token' in the
> list-of-tokens value for the role attribute is a problem.

Why?


> Provide
> a syntax and state your intention to track the development of
> this syntax in HTML5 should it change.

I guess I could copy those definitions into the proposal, although I'd  
rather concentrate on working on the remaining big issues before making  
the spec self-contained. :-) Using the micro-syntax definitions from HTML5  
seemed convenient.


> A note/link to explain why
> an established token syntax is not sufficient would help, too.

Which established token syntax?


Cheers,
-- 
Simon Pieters
Opera Software

Received on Thursday, 27 September 2007 18:08:26 UTC