Re: Significant ambiguities in aria-roledescription

Separate from any discussion of what *should* happen, there is an important
interaction with another section of the specification.

aria-roledescription is a global attribute (it applies on any role).
Therefore, it should trigger the rule that global ARIA attributes make an
author-supplied role of presentation/none invalid, so that the default
semantics apply.  Similarly, if the element does not have default semantics
that would normally map to a role, a global ARIA attribute should force it
to be exposed as an accessible object anyway.

So as the spec currently stands, for the first set of Matt's examples, the
role of none would be ignored, the default img or table roles would apply,
but then the (unhelpful) role descriptions would be used to describe the
objects:

<img role=”none” aria-roledescription=”Gotch ya”>

<table role=”none” aria-roledescription=”layout table”>


This seems to conflict with the guidance in the section on
aria-roledescription itself.

If I understand Matt's second example correctly, the list elements are
being mapped to the list-item role as normal, but most screen readers would
not bother to announce each individual list item in such a short, unordered
list?  I'm not sure we would want to override that explicitly.  Maybe a
screen reader would decide to read it out as "Unordered list, containing 3
fruit: apple, banana, orange" instead of "Unordered list, 3 items: fruit 1,
apple; fruit 2, banana; fruit 3, orange".

Regardless, if people are concerned of aria-roledescription being misused,
would it make sense to restrict it to a limited number of roles?  That
would automatically cancel out the global attribute override behavior I
described above.  I think the use case for "region" is very clear, to be
able to describe the component in the same wording (card, panel, slide,
whatever) that would be used in help text for the web site.  I'm not sure
what other sensible use cases exist.

~Amelia