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

At 8:08 PM +0200 27 09 2007, Simon Pieters wrote:
>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.

Good.

On the other hand, I didn't get that.

The intent is good; the devil is in the details.

We have the same problem, in fact.

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

Place in DOM, for starters.

>Firefox 2 only looks at the first value,

Let's check that with Aaron.  I thought that it looks at the first 
ARIA role it finds, for the purposes
of binding to the accessibility APIs.  It doesn't interfere with 
loading all the tokens into the DOM
as the value of the attribute.  And I didn't think it looked at only 
the lexically first token in the
attribute 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.)

Duh!  Thanks.

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

Worth working on.  We're not done until we have more people on board. 
Good luck.

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

Good.  I managed to read your language as more restrictive on the latter.

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

Unnecessary ambiguity in the definition of the proposal.

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

Please give us a link to a definition.  That's probably better
than forking definitions with a copy.  Sorry I suggested that.
But a bald reference to 'HTML5' by a bare string w/o URI
backup is in this case best avoided.

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

Any established token syntax.  from HTML, HTTP, ECMAScript, ...

I assume that the people drafting proposals for HTML5 have done
something novel for a reason. Otherwise one would use a
definition from HTML 4.01. It would help to know the reason.

Al

>Cheers,
>--
>Simon Pieters
>Opera Software

Received on Thursday, 27 September 2007 19:34:43 UTC