Re: ARIA Proposal

Richard Schwerdtfeger wrote:
> I cannot support aria-role over role:
> 
> I was one of the original creators for role.

   And I'm one of it's major opponents.

> It's purpose is not limited to accessibility.

   No, but it's one of the two primary use cases, the other one being
the roles specified for the XHTML namespace.

> Choosing to limit to accessibility alone will create problems throughout
> the W3C.

   Well, part of the idea was that |aria-role| would be a separate
attribute from |role| that can be mapped to the |role| attribute or
implemented independently, so I don't see why they can't coexist.

   That said, so long a |role| hasn't reached critical mass in the
authoring community, I could care less how it disrupts the W3C. The W3C
is here to create good specifications, and if they have to start over
with some of them because a specific technology falls out of favor, so
be it. Better to break unimplemented specs that to try to fix the ones
already implemented.

> One use case that is not accessibility related: role can take a value of
> "main" which eludes to main content. A cell phone provider can take all
> main content and move it to the first screen when rendering a web page.
> This is not accessibility related. It is also being used, in general,
> for content adaptation.

   The <article> element fulfills this use case. For that matter, a
simple boolean attribute entitled "main" would do the same and allow
attribute minimization:

| <div main>[...]</div>

   How is it that boolean attributes and other markup are not sufficient
 to fulfill the |role| attribute's use case?

   Furthermore, you have yet to explain how to deal with interaction
between multiple roles declared on the same element. How, for example,
do you deal with declarations of "wairole:checkbox" and "wairole:radio"
at the same time? The |aria-role| attribute resolves the problem by
preventing it from happening in the first place.

> We cannot hijack the role attribute for accessibility purposes alone due
> to it's intended scope. As for the aria attributes using the aria-
> preamble I have no problem as these have only been used for
> accessibility. Ian's proposal for the attributes was excellent.

   You seem to be contradicting yourself. The |aria-role| attribute
would have some duplicate functionality, but it would be separate from
|role| and only take a limited range of values. That seems consistent
with the way the "aria-" prefix is used for attributes like
|waistate:checked| and such. In fact, using |aria-role| ensures that
|role| doesn't need to be modified to treat WAI-ARIA roles as if they
were in the same namespace as XHTML roles.

> Google also is against adding unneeded characters which would increase
> the download size. All the major search engine providers are counting
> every character.

   Clarify: You have first-hand knowledge that Google is against my
specific proposal?

> Also, a number of groups are already implementing ARIA which use role:
> Dojo, Yahoo, Google, SAS, SAP, lots of others.

   And yet the vast majority of web sites are HTML and cannot take
advantage of the roles as-implemented because of the lack of support for
namespaces. The |role| attribute you're proposing to add to HTML would
be one limited to roles from only two namespaces with the namespace
prefixes from one namespace removed. The XHTML roles conflict with many
of the proposed new elements in HTML5. Thus, if you remove the XHTML
roles to resolve the conflicts, you are left with only the ARIA roles,
and |role| becomes a mere abbreviation of |aria-role|.

   Not that this would make sense even if you could do namespaces in
HTML, because then you could just take advantage of attribute
minimization and do this:

| <div wairole:checkbox></div>

   That saves seven characters over using the |role| attribute:

| <div role="wairole:checkbox"></div>

   In fact, even if you have an explicit boolean value, you haven't
really saved characters:

| <div wairole:checkbox="true"></div>

   The |role| attribute is an elegant solution to a problem that doesn't
exist. There is nothing the it can express that couldn't be expressed
with elements or simple attributes. It's greatest use case are the ones
that have been specifically tailored to use |role| instead of other
solutions that would be greater extensible, easier validation and
parsing, and more structured markup.

Received on Friday, 28 September 2007 01:51:50 UTC