[Accessibility-ia2] next changes to IAccessible2

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Thu Jun 16 19:06:11 PDT 2011


On Fri, Jun 17, 2011 at 8:34 AM, James Teh <jamie at nvaccess.org> wrote:
> On 9/06/2011 9:50 PM, Alexander Surkov wrote:
>> However specialized interfaces allows to provide a common
>> way to deal with different objects and can be used to fix web page
>> accessibility errors. In the case of media interface screen reader can
>> provide unified way to play or pause the media for example. This can
>> be really be a good idea when web page authors didn't provided UI to
>> control the playback but added keyboard shortcuts and mouse gestures.
> This is a very slippery slope. By that logic, we should provide
> interfaces to fix all sorts of accessibility defects due to bad
> authoring; e.g. inaccessible drop down menus, inaccessible Flash, etc.
> Admittedly, these are poor examples, but the point stands. In any case,
> you could achieve the same result by exposing fake, off-screen UI
> controls for the video.
>
>> I considered the idea of live regions usage, it's really good until
>> the media shouldn't be stopped until screen reader finishes the
>> reading. To handle this we should introduce new approach that's isn't
>> connected with aria live regions.
> Why? It can be generalised to a live region which requires client
> notification when read. For example, we could use @aria-live="polite"
> @aria-liveNotifyWhenDone="true", the latter meaning that the AT must
> notify the browser via some call that it has finished handling the
> region. This would still require one method, but it's better than
> implementing a whole new concept. (Note that I'm still not convinced
> this is ideal for an a11y API, but I think if we're going to do it, it
> should be as general as possible.)
>
>> On the another hand since extended text is supposed to be
>> visible by screen readers only
> Maybe there are sighted users who might want to see it as well? Making
> this screen reader specific defeats inclusive design. I agree that most
> sighted users won't want it, but that doesn't mean that none will. I
> guess it could be off-screen or similar when not visually available.

To clarify how this currently works in HTML5:
The way in which it is specified, text descriptions are not exposed
visually by browsers, but only exposed to Web developers through a
JavaScript API. The text is not available on the page's DOM. If a Web
developer decides to also expose text descriptions visually, they have
to create a visual display themselves. I've seen developers do this,
but it's a custom solution and not something that Web browsers are
expected to implement, since text descriptions are particularly
targeted at being read out by a screen reader type application.

BTW, it is explicitly mentioned that eyes-off applications (something
like watching a video while cooking) could make use of text
descriptions, too. In this case, the user would require some voicing
application installed - something that is similar to a screen reader.
In the future we may see such functionality being natively integrated
into browsers. But I guess we have to deal with this situation now.

Cheers,
Silvia.


More information about the Accessibility-ia2 mailing list