RE: Significant ambiguities in aria-roledescription

Amelia,

 

Thank you! I forgot all about the effect of global properties on the presentation role. I wonder how it was even possible for me to forget something so basic … wow.

 

Now that you cleared up that issue, I reread all the proposed text. I don’t see the language you suggested is in conflict with that feature of global properties.

 

It is not clear to me that limiting the applicability is beneficial. It is extremely difficult to anticipate the spectrum of worthwhile utility for a property like this. We should probably not limit it unless we can identify roles where applying the property is guaranteed to be problematic regardless of author intentions.

 

Matt

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Thursday, July 7, 2016 8:18 AM
To: ARIA Working Group <public-aria@w3.org>; Matt King <a11ythinker@gmail.com>
Cc: Schnabel, Stefan <stefan.schnabel@sap.com>; Léonie Watson <tink@tink.uk>; Richard Schwerdtfeger <richschwer@gmail.com>; White, Jason J <jjwhite@ets.org>
Subject: 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