Re: New @roles for media descriptions, etc. (was RE: Agenda: HTML-A11Y Media Subteam on 25 May at 21:30Z for 90 Minutes)

Hi John,

So, what happens today is that the descriptions are glued together to form
a single description when presented to a screen reader.

If we would like to separate them semantically as you are suggesting we
would need to separate them in the accessibility API. Right now we make no
distinction about what the object is describing it if we are glueing them
together and we would need to make the AT aware that the describing object
has semantic meaning. ... All doable of course it just requires us to
provide AT vendor education.

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	"John Foliot" <jfoliot@stanford.edu>
To:	"'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc:	"'HTML Accessibility Task Force'" <public-html-a11y@w3.org>,
            "'James Craig'" <jcraig@apple.com>
Date:	05/26/2011 12:42 AM
Subject:	New @roles for media descriptions, etc.  (was RE: Agenda:
            HTML-A11Y Media Subteam on 25 May at 21:30Z for 90 Minutes)
Sent by:	public-html-a11y-request@w3.org



Silvia Pfeiffer wrote:
>
> As for the roles, I wonder what the use case would be. Why would they
> be required?

The principle issue is one of semantics and association.  Consider the
following code sample:

		 <video
		 		 src="media.webm"

poster="http://art110.wikispaces.com/file/view/u2-stage.jpg/34175307/u2-st
age.jpg"
		 		 aria-describedby="This That">
		   <p id="This">U2 live on stage</p>
		   <p id="That">Pride (In The Name Of Love)</p>
		 <video>


This is perfectly valid and legitimate code, but could be potentially
confusing to the non-sighted user if read aloud: we *presumed* in our
previous code examples to date that authors would order the text as
media/image, but we cannot guarantee it, and both paragraphs above, while
accurate, are also somewhat ambiguous (so yes, this is also an authoring
issue).

Those 2 paragraphs (This, That) however are "special" in that they
represent text for specific reasons, yet in the code above the reasons
(the roles) are not specifically clear. ID's do not convey semantics
(which is why we first saw landmark roles emerge: <div id="nav"
role="navigation">), they can be any non-empty text string, as illustrated
above.

Consider the same code with aria-roles applied:

		 <video
		 		 src="media.webm"
		 		 poster="
http://art110.wikispaces.com/file/view/u2-stage.jpg/34175307/u2-stage.jpg"

		 		 aria-describedby="This That">
		   <p id="This" role="imagedescription">U2 live on stage</p>
		   <p id="That" role="videodescription">Pride (In The Name Of
Love)</p>
		 <video>

Now it is crystal clear (programmatically) what is what, which is
important in supporting the goals of POUR (Perceivable, Operable,
Understandable and Robust) - and specifically Understandable.

As well, there could very well be a scenario where *some* users might not
want to know about the first-frame image (ya, I know... but honestly, some
will, some won't, it's a coin toss). As it stands now, one of the minor
flaws with describedby is that it is 'forced' on the end user, there is no
switching mechanism to consume or not consume (this circles back to the
longdesc issue/discussion*).

If a paragraph (or collection of paragraphs) had a role of
imagedescription or some such, it might also be usable as a filter: in the
future a screen reader or other user-agent could be configured by the
end-user to provide the media description but filter out the image
description:

		 Read mediadescription = true
		 Read imagedescription = false
(this could be a user-agent setting)

(Again here, using ID wouldn't work, as ID's can be randomly set by the
author, so there is no consistency for the client side filtering; this
would also fail on pages where there were more than 1 <video>, as IDs need
to be unique to a page.)

I am a very big proponent of fine-grained semantics (where semantics =
meaning/understanding), and @role was expressly designed to apply those
kinds of specific semantics, so...

Thoughts?

JF

* This issue has already been captured by the ARIA WG (AFAIK), and most
likely will be dealt with in ARIA.next (where there is already discussion
around a possible aria-longdescription (sic) attribute), but for now this
is what we have.