From @jasonkiss on June 15, 2016 6:14

The HTML-AAM has the following statement in its Introduction:

Where an HTML element or attribute has default Accessible Rich Internet Applications (WAI-ARIA) 1.1 [WAI-ARIA] semantics, it must be exposed to the platform accessibility APIs according to the relevant WAI-ARIA mappings defined in the Core Accessibility API Mappings specification. Where an HTML element or attribute does not have default WAI-ARIA semantics, the applicable mapping for each platform accessibility API is defined by this specification.

It's got a similar note in the Notes section preceding the two mapping tables.

However, and with good reason, the mappings of at least 11 elements differ from the mappings of their default ARIA roles in one or more APIs. These are aside, footer, header, input type=email, input type=number, input type=telephone, various inputs with suggestion lists, input type=url, output, section, and tr.

The SVG-AAM has language like this at the end of its Introduction:

This guide relies heavily on the accessibility API mappings defined in the [CORE-AAM] and [ACCNAME-AAM] specifications but defines changes in mappings due to features in the [SVG] host language. Key areas of difference stem from the intrinsic host language semantics of SVG:

The language in the HTML-AAM is too strong. We should clarify that an element with a default ARIA role RFC-MUST be mapped according to the CORE-AAM mapping of for that element's default ARIA role, unless otherwise indicated. We should also add some language similar to that in the SVG-AAM.

Any thoughts?

Copied from original issue: w3c/aria#402