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

Hi Joannie,

If you recall, at the face to face a concern was raised over adding those
additional controls in the 1.1 time frame. For full accessibility of video
you would also need to address activating tracks - subtitles, descriptive
video, etc.

IOW this grows very quickly.

Rich


Rich Schwerdtfeger



From:	Joanmarie Diggs <jdiggs@igalia.com>
To:	James Craig <jcraig@apple.com>, Matthew King/Fishkill/IBM@IBMUS
Cc:	Steve Faulkner <faulkner.steve@gmail.com>, W3C WAI Protocols &
            Formats <public-pfwg@w3.org>
Date:	04/02/2014 01:47 AM
Subject:	Re: ISSUE-636 CTION-1398 Provide spec. text for
            aria-roledescription



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

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.

> 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.

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.

--joanie