Comments on the March 2nd draft. Some of this is editorial. Some is substantive. Please let me know if you'd prefer I enter individual items in Bugzilla. — James

The quoted bits are verbatim from the document, followed by my comments.

> For example if using role=button the element must be able to recieve focus and a user must be able to activate the action associated with the element using both the enter and the space key.

Enter and Return are not entirely interchangeable. The appropriate key on Mac is Return. I think you can just change "enter" to "enter/return" here, but you might want to note the platform difference. Also "receive" is misspelled.

> Note: Any elements that are not required children of the element with a role=presentation keep their semantics. This includes other elements with required children.

Suggest appending: …such as nested lists or nested tables.

> Currently aria-labelledby and aria-describedby are more robustly supported for associating text content to a subset of interactive content elements, they do not work correctly on links, support on embedded content is unknown, but can be safely used on form controls including the many input types.

W3C docs should never state something "does not work" as the expectation is that this will change. Instead say something like, at the time of this writing, and then ideally have a list of blocking bug links. A reader can then cross-reference the links to know if the restriction is still relevant.

> In Internet Explorer, if you use aria-labelledby with multiple id references or aria-describedby with single or multiple id references, the referenced elements must be what Microsoft terms as accessible HTML elements.

This is another place to list a blocking bug number if one is available.

> You do not use it if a set of controls only contains these widgets…

Pronoun-itis: Consider changing to, "You do not use role="application" if a set of controls only contains these widgets…"

> This also applies if you mark them up and create an interaction model using WAI-ARIA roles instead of standard HTML widgets:
>
>       • text box.

There should probably be a note somewhere in the document that indicates it's not recommended that authors develop custom text input widgets. It's almost always best to use the native inputs for these.

> dialog and alertdialog. These cause screen readers to go into a sort of application mode implicitly once focus moves to a control inside them.


Please note that this is *some* screen readers, not all.

There should probably also be a note in the document that indicates how one should be able to include static non-interactive content in a dialog by using the document role to counteract the application mode. To my knowledge, static dialog content can only be accessed in Safari with VoiceOver. I believe the Windows screen readers disallow access to any static content in dialogs, whether or not the application mode is used. I consider this to be a bug, though not everyone agrees.

> You only want to use role=application if the content you’re providing consists of only interactive controls,

"only interactive controls" should probably be "only focusable, interactive controls"

> be it FaceBook posts and comments

s/FaceBook/Facebook/

> We primarily still deal with documents on the web, even though they may have a desktop-ish feel to them on the surface.

While I appreciate you not overcapitalizing when "web" is used as an adjective ("web page", "web browser"), this is actually one of the only places "web" should be capitalized, because it's used as a proper noun: "the Web"

Note: Same goes for "internet." You would not capitalize "internet domain" but you would capitalize "domain on the Internet."

> NEVER put it on a widely containing element such as body if…

Pronoun-itis: Consider changing to, "NEVER put role="application" on a widely containing element such as body if …"

> Recommended ARIA usage by HTML language feature

This table would be more useful printed with a "thead" (Note: I print when I edit.)