- From: John Foliot <jfoliot@stanford.edu>
- Date: Wed, 25 May 2011 22:40:21 -0700 (PDT)
- To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
- Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'James Craig'" <jcraig@apple.com>
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.
Received on Thursday, 26 May 2011 05:40:49 UTC