Re: Action 2044

Some general comments:

I don't like calling this "Overriding Presentational Roles".  That suggests
that presentational roles are there by default and the author is
intentionally over-riding them.  That's not what we're describing: we're
describing cases where an author-supplied role of presentation/none is
invalid and ignored.

I would change the heading to something like "Conflicts with Other Element
Semantics" or "Incompatible Use of Presentational Roles".  The first
paragraph could then be something like:

"The presentational roles only neutralize implicit semantics from the host
language. There are a number of ways in which author-supplied semantics,
including other WAI-ARIA attributes, can cause an explicit or inherited
presentational role to be invalid and therefore ignored."

I would still prefer that this be a stand-alone section, rather than tucked
into the description of the presentation role.  The section is long
enough.  It may now have a link-able ID, but it doesn't show up in the
table of contents.

It seems to me it is more equivalent to the section on conflicts with host
language semantics, although in this case we are also discussing conflicts
between different types of ARIA semantics.

Does this section also apply to elements that are presentational because of
an ancestor with a "children are presentational" role? If so, it should be
clearly stated.  If not, we need rules elsewhere for what to do if there
are interactive elements as a child of a button, img, or similar role.

Does this section also apply to elements that are presentational because of
host native semantics (e.g., a <span>)? What role gets applied if global
ARIA attributes or interactivity force such an element to be included?

On 26 April 2016 at 14:59, Rich Schwerdtfeger <> wrote:

> I modified the role=“presentation” section to separate out the overriding
> of role “presentation” so that it may be referenced by the SVG and Core
> AAMs:
> Let me know if you have any issues.
> Rich
> Rich Schwerdtfeger
> Round Rock, TX

Received on Wednesday, 4 May 2016 02:15:26 UTC