Re: [a11y-metadata-project] Re: accessibility proposal Review...

Hi all,

What about "mediaAlternative", or "accesAlternative"?

Because, for me, the captions or audiodescription, etc. are not a "feature"
of the media nor a description.

In the example given by Dan, appears "accesFeature" which also seems
to me. I get the feeling that he did not mean to write it that way, but in
that case it's a happy accident.


2013/9/9 Dan Scott <>

> On Sun, Sep 08, 2013 at 02:36:22PM +0000, Madeleine Rothberg wrote:
> > (Gerardo's reply, which arrived when I was almost done writing this,
> > covers some of the same issues, but I will send this anyway in case a
> > differently worded explanation is helpful to anyone.)
> >
> > The solution to knowing which of the accessModes listed for a given
> > resource are required for understanding the resource and which are not
> has
> > traditionally (in Access for All usage) been that the matching system
> > analyzes several pieces of metadata together to draw a conclusion. Here's
> > the example of a video with captions and audio description, which Charles
> > McN correctly marks up as:
> >
> > <div itemscope=²² itemtype=²²>
> > <meta itemprop=²accessMode² content=²visual²/>
> > <meta itemprop=²accessMode² content=²auditory²/>
> > <meta itemprop=²mediaFeature² content=²audioDescription²/>
> > <meta itemprop=²mediaFeature² content=²captions²/>
> > </div>
> >
> >
> > We have resources like this in Teachers' Domain. And the solution there
> to
> > deciding which resources are well-suited a particular user's requirements
> > is to analyze the whole of the metadata in comparison to the user's
> > preferences. If a user cannot see, then if a resource contains "visual"
> > media we look to see if there is a mediaFeature that can substitute for
> > visual. "audioDescription" is an auditory substitute for visual material,
> > so this resource taken as a whole meets this user's needs.
> Perhaps, instead of having repeated accessMode and mediaFeature
> properties repeating directly under, which (if I
> understand correctly) makes it hard to correlate accessMode=visual with
> mediaFeature=audioDescription, these properties should be subsumed under
> a new Type.
> For example, let's call this new type AccessibilityMode and propose that
> the associated property name be accessDescription, just as a placeholder:
> <div itemscope itemtype="">
>   <div itemprop="accessDescription" itemscope itemtype="
>     Accessible to sighted users
>     <meta itemprop="accessMode" content="visual"/>
>     <meta itemprop="accessFeature" content="audioDescription"/>
>   </div>
>   <div itemprop="accessDescription" itemscope itemtype="
>     Accessible to hearing users
>     <meta itemprop="accessMode" content="auditory"/>
>     <meta itemprop="mediaFeature" content="captions"/>
>   </div>
> </div>
> This would enable you to keep the mode & feature meaningfully connected,
> which is I think what you're looking for. And now that we're
> distinguishing the accessibility mode as a separate Type, all of the
> standard Thing properties are available to us without being associated
> with the Movie itself, so you could go also use the "description"
> property to note any particular restrictions, etc, for each access mode.
> --
> You received this message because you are subscribed to the Google Groups
> "Accessibility Metadata Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> To post to this group, send email to
> For more options, visit

Emmanuelle Gutiérrez y Restrepo
Fundación y Seminario SIDAR

Received on Sunday, 8 September 2013 22:48:53 UTC