I have an example document with the per-element ARIA info added here:

http://people.w3.org/mike/drafts/aria-html/

Given that ARIA is really intended to be a rarely-used feature for advanced authors in cases where they can't quite get the right thing from straight HTML, I think this draws far too much attention to the feature.

I've actually been considering more of a move in the other direction, namely moving ARIA information out of HTML altogether and into a dedicated document (possibly ARIA itself).

(In reply to comment #2)
> Given that ARIA is really intended to be a rarely-used feature for advanced
> authors in cases where they can't quite get the right thing from straight
> HTML,

I'm not sure I'd agree at all with that characterization of ARIA, and I suspect a lot of other people wouldn't agree with it either.

But lacking ARIA attribute information at point of use in the HTML spec is certainly not going to help much in getting more authors to actually use ARIA. So if the goal were to be to ensure that ARIA attributes are only rarely used by authors, omitting information about that ARIA attributes from the places in the spec where all the existing attributes are documented would be a good way to help make sure that ARIA attributes are only rarely used by authors

> I think this draws far too much attention to the feature.

I think the ARIA feature has far less attention than it deserves, so doing things that draw less attention to it is not a good thin.

> I've actually been considering more of a move in the other direction, namely
> moving ARIA information out of HTML altogether and into a dedicated document
> (possibly ARIA itself).

If you do that I think it would cause some authors and writers of HTML guides (books and online references and such ) to quit consulting the HTML spec for guidance about which attributes to use on which elements, and instead use some other resource that actually does attempt to provide complete information about allowed attributes in a user-friendly way.

Why do you think ARIA shouldn't be used rarely?

I don't really understand why ARIA should be used at all, outside custom components, and those are pretty rare.

(In reply to comment #4)
> Why do you think ARIA shouldn't be used rarely?
> 
> I don't really understand why ARIA should be used at all, outside custom
> components, and those are pretty rare.

Custom components aren't rare and are likely to become more popular with the introduction of custom elements. 

some examples:
http://www.sencha.com/products/extjs/examples/
http://jqueryui.com/demos/

I would go so far as to say they are commonplace. 

ARIA fills gaps in native feature support in browsers and AT, gaps in feature support are common.

ARIA usage is higher than for some other new features in HTML[1]


[1] https://docs.google.com/spreadsheet/ccc?key=0AlVP5_A996c5dFhMQ3R2SG1uZFNZVEsxUURQN213VVE#gid=0

(In reply to comment #4)
> Why do you think ARIA shouldn't be used rarely?
> 
> I don't really understand why ARIA should be used at all, outside custom
> components, and those are pretty rare.

As Steve notes in comment 5, things like the jQuery UI demos use ARIA markup all over the place; e.g.:

<div role="dialog" aria-describedby="dialog" aria-labelledby="ui-id-1"...>

I think the role attribute at least seems to already be used in enough content on the Web that it's not that rare at all, relatively. So authors would benefit from clear guidance on which role values are allowed on particular elements.

(In reply to comment #6)
> (In reply to comment #4)
> > Why do you think ARIA shouldn't be used rarely?
> > 
> > I don't really understand why ARIA should be used at all, outside custom
> > components, and those are pretty rare.
> 
> As Steve notes in comment 5, things like the jQuery UI demos use ARIA markup
> all over the place; e.g.:
> 
> <div role="dialog" aria-describedby="dialog" aria-labelledby="ui-id-1"...>

btw that markup is from the source for http://jqueryui.com/dialog/

I'm all for documenting it in detail in the context of Web components. What I'm talking about is listing roles and ARIA state attributes in the element definitions of elements like <ins> or <cite> or whatever. I don't understand the value of having the <cite> element explicitly say that you can mark it as "aria-invalid", for example. Nor do I see much point in having the "p" element say that it accepts role=heading, and that if you specify that, that you can also specify aria-level, or whatever. (Then again, maybe we should just not allow that.) I also don't think there's much point being backwards-looking and going to great depths to document how to make <div> soup accessible, when we are going to have to spend a ton of time already just documenting the best practices in the new Web Components world.

Maybe we could do something more subdued, though, like just exploding the current WAI-ARIA table out to the various element definitions the same way we do with content models, rather than having big tables in each definition. This _would_ allow us to more easily review how sane the current restrictions are. I'll have to examine the idea more closely. I definitely don't think we should do something like what ends up here, though; I don't think that helps most authors in practice (indeed that section is bad enough as it is, without the ARIA mess):
   http://people.w3.org/mike/drafts/aria-html/the-input-element.html#the-input-element

(In reply to comment #8)
> I'm all for documenting it in detail in the context of Web components. What
> I'm talking about is listing roles and ARIA state attributes in the element
> definitions of elements like <ins> or <cite> or whatever. I don't understand
> the value of having the <cite> element explicitly say that you can mark it
> as "aria-invalid", for example. Nor do I see much point in having the "p"
> element say that it accepts role=heading, and that if you specify that, that
> you can also specify aria-level, or whatever. (Then again, maybe we should
> just not allow that.) I also don't think there's much point being
> backwards-looking and going to great depths to document how to make <div>
> soup accessible, when we are going to have to spend a ton of time already
> just documenting the best practices in the new Web Components world.
> 
> Maybe we could do something more subdued, though, like just exploding the
> current WAI-ARIA table out to the various element definitions the same way
> we do with content models, rather than having big tables in each definition.
> This _would_ allow us to more easily review how sane the current
> restrictions are. I'll have to examine the idea more closely. I definitely
> don't think we should do something like what ends up here, though; I don't
> think that helps most authors in practice (indeed that section is bad enough
> as it is, without the ARIA mess):
>   
> http://people.w3.org/mike/drafts/aria-html/the-input-element.html#the-input-
> element

While i don't disagree with you in regards to the use of ARIA on some elements (see using ARIA in HTML http://rawgithub.com/w3c/aria-in-html/master/index.html for my collected wisdom :-))

" don't understand
> the value of having the <cite> element explicitly say that you can mark it
> as "aria-invalid", for example."

Given that any element can be made content editable having the ability to indicate to users that user input is incorrect seems reasonable.

>Nor do I see much point in having the "p" element say that it accepts role=heading

I don't see much point in any elements to have role=heading apart from headings, but others have argued otherwise and if someone uses a p as a heading then its better to allow them to expose the appropriate semantics than not.

as in the cited ARIA doc the advice is use div/span.

but note p is hardly a strong semantic in acc layer terms. 

I have had an informal request to update the ARIA tables in the spec to include all elements, am looking at that.

Checked in as WHATWG revision r8020.
Check-in comment: Make it clearer that 'global attributes' includes the ARIA attributes
http://html5.org/tools/web-apps-tracker?from=8019&to=8020

I don't feel strongly about this to keep it open. I (or somebody) can re-raise it at github if we want to re-pursue it in the future.