Re: ISSUE-636 ACTION-1398 Provide spec. text for aria-roledescription

For what it's worth, I think we should *eventually* add roles for all of these that we've mentioned. Absolutely we should.

That doesn't preclude the usefulness of a localized role description though. It allows authors to make these reasonably understandable immediately, even if it takes us years to codify the entire role taxonomy, and even the RDF and DCMI diehards in the group readily admit that we'll *never* have an entirely complete taxonomy in ARIA.

More comments inline.

On Apr 1, 2014, at 11:46 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> On 04/01/2014 02:47 PM, James Craig wrote:
> 
>> What about the rest of the examples I mentioned?
>> 
>> 1. <video> in HTML might default to <video role="group" aria-roledescription="video">
> 
> This one strikes me as best solved by an accessible "video" role on the
> grounds that the components and user interactions of a video are largely
> predictable and distinct from other, more generic widget groups. The
> usual suspects include:
> 
> * Video display
> * Buttons for Play, Pause, Stop, Rewind, Fast Forward
> * Volume controls
> * Full screen / embedded toggle
> * An adjustable progress slider

I'm only talking about the non-interactive container that contains all the interactive children. For example, in WebKit, the <video> element just ends up being a group with a special role description, and the interactive elements like the play button are contained as shadow DOM descendants.

> If an AT knows that a given container is a video player, and is able to
> identify the components above, that AT can provide an experience which
> is better tailored to the medium and to the access method -- and
> potentially one which is consistent regardless of site, browser, or
> platform versus desktop. But doing so requires that the AT know what the
> specific nature of the container is; this one is not merely a matter of
> passing the role along unexamined and unmodified to be spoken.

Absolutely we should add a video role. That's on the list for 2.0 and that work is intended to include the additional control mechanisms and relationships. The 1.1 inclusion of role description would just allow authors to make the generic group understandable in the meantime. E.g. "Ninja kitty, video" rather than "Ninja kitty, group"

>> 4. Slides in web versions of Keynote/PowerPoint could use <section aria-roledescription="slide">
> 
> This is another one in which I think an AT might wish to know the role
> in order to make decisions about what to present to the end user.

I'm not as sure about this one needed a "slide" role, but in either case, role description allows this to be made reasonably understandable in the meantime while the working group debate specifics of ARIA.Next roles. If and when a role is provided and supported, the custom role description can be phased out.

> My favorite example is the accidental resizing of layout areas during
> non-visual slide creation and editing. For those of you who haven't had
> the pleasure, it goes something like: You thought you were *in* the
> layout area whose text you wanted to edit, but you were only *on* that
> layout area. Thus when you pressed the arrow keys to navigate within the
> text you wished to edit, you instead moved the entire container
> somewhere you didn't want it. :-/
> 
> Given an object the screen reader knows is a slide, if the bounds of a
> focused object on that slide have suddenly changed, this event is
> probably worth passing along to the end user. But, at least in my
> experience, the slide situation is the exception and not the rule:
> Bounds change often but those changes are often of no interest to the
> user and should thus be filtered out by the screen reader.

I agree that sounds useful, though slightly off-topic.

Received on Wednesday, 2 April 2014 07:25:58 UTC