W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Idea for new element to support automatic rendering of descriptive content for people with disabilities

From: Joshue O Connor <joshue.oconnor@cfit.ie>
Date: Mon, 02 Jul 2007 10:28:24 +0100
Message-ID: <4688C538.8000001@cfit.ie>
Cc: public-html@w3.org

Joshue O Connor wrote:
> I was thinking along the lines of a behind the scenes move where the
> screen reader maybe pre-loads the @longdesc content into its virtual
> buffer when the image has focus and reads it out after the @alt content
> (if @longdesc is present). Gregory mentioned [1]  that he would prefer
> it to be a user activated choice, which is also fine but is at the
> moment rather inelegant.Also  I think there could be value in this
> method by reducing the cognitive load on the user and the complexity of
> interrogating the element content by automating the process.

I have a couple more ideas for this, to support its usage (on planet
Josh with no support/vendor barriers issues obviously ;-)

How about a <dwell> element which could inform the UA (screen reader)
that there is more content to come when an element has focus
(image/table), and that it will to be (possibly) preloaded behind the
scenes and read out in an author defined sequence, so the user should
not skip to more content on another part of the page and therefore miss
it? For an image you could have:

<dwell id="suitable_complex_image_declaration">
<img src="/home/img.jpeg alt="Brief overview of complex image"

When the UA (screen reader) comes across the <dwell> element it could
inform the user that this image has extra content associated with it
(this output could be author defined using a suitable attribute) that
will automatically follow in a set sequence such as @alt followed by

This _could_ be useful for users with limited mobility by automating the
output so they don't _have_ to trigger it  as well as users with visual
impairments with the extra descriptive content rendered as required.
What the screen reader outputs when the <dwell> element has focus could
be author defined. <dwell> could be used with any element that needs
alternate content to describe it in more detail for people with
disabilities and would also be an explicit reminder to authors that they
have to author their content for users of AT and cater for specific
needs such as vision impairment.

<dwell quality="This image contains a longer richer description">

The <dwell> element could have particular 'quality' properties which
could be set in a separate file such as timing information to trigger
@longdesc, or the approximate length of the rich description, or about
the length of time the extra content will take to render or be outputted

Just for the record, I don't see automation of these kind of processes
as removing choice from the user, but rather as making use of existing
attributes that contain useful information and making the process of
accessing that information easier.

As I have no idea how to make this work in the real world or get vendors
to support it, if it is a good idea, please feel free to shoot down in
flames, ignore or ridicule /select at will/

Received on Monday, 2 July 2007 09:28:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:23 UTC