Starting with the "Recommended ARIA usage" table:

> dl

Please note that there is no direct ARIA role match for description lists, so it's in appropriate to override the native role in this case unless the author is retrofitting an improper use of the DL element.

> hgroup

Probably need to remove this.

> iframe

Probably need to add another row for iframe[seamless], where it is okay to override with any general grouping role.

> input type=checkbox

This note is no longer relevant for ARIA 1.0: "it is required that an explicitrole=checkbox is declared "
The host language implicit role is enough without the redundant role attribute.

> input type=number
> input type=range

Should add that it's okay to use aria-valuetext on these, with or without an explicit role.

> math

Why is it recommended to use the ARIA role here? The ARIA role is mainly useful for math that is not marked up in such a way as to be programmatically determinable. MathML on the other hand, provides enough structure and metadata to determine much more information about the math content. I would say that it is not necessary or recommended to explicitly use a math role on MathML.

> meter

This one is listed as N/A, but I think progressbar is the equivalent role here. I would still list this as NO, though.

> ol

Add "group" to the role list.

> output

Not YES. I'd say it DEPENDS. If you add role="status", it will force this to be a broadcasting live region. In some cases, this is fine, but if this is an element whose value changes constantly due to scripted updates rather than explicit user action (like a progressbar), it'd be more appropriate to set aria-live="off". Otherwise some AT users are going to find this very distracting, even impossible to use. Even "polite" live regions can be annoying if they are overused.

> progress

Should add that it's okay to use aria-valuetext on this (e.g. "Step 2 of 10"), with or without an explicit role.

> tbody, thead, tfoot

Change "NONE" to "role=rowgroup"
Change "N/A" to "NO"
Change "these elements" to "these unrendered elements."

> Text level elements not listed elsewhere

Out of curiousity, why weren't INS and DEL listed here instead of on their own row?

> Element with an inert attribute

Change "aria-disabled" to "aria-hidden"
Change "NO" to either "YES" or "DEPENDS."

Remove the note about disabled content and add a new note indicating that inert content is used for things like the background contents while showing a modal dialog. In this case, it would be appropriate and recommended to use aria-hidden="true"… If there are cases where inert is being used to deactivate foreground content that is still intended for consumption, @inert should be combined with an explicit aria-hidden="false" to override the default rendering engine behavior.

> Element is focusable

I think you should split this into a couple rows.

1. Focusable elements that are natively focusable (links, buttons, etc.) NO, don't override.
2. Focusable elements that are not natively focusable (li, span, div, etc.) YES, override with any widget role.

For example, <span tabindex="0"> is focusable but has no role in most rendering engines. The document has "NONE" in the role column, but I think it needs a role here in a lot of cases.

> Element that is a candidate for constraint validation but…

The note column should be updated to link to what HTML defines what constitutes the user has interacted with the control "significantly." Also ARIA defines aria-invalid="grammar" and aria-invalid="spelling" which are not mentioned here.

---

That's all I noticed. Great document! Thanks for publishing it.