W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2013

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

From: Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
Date: Mon, 9 Sep 2013 00:48:26 +0200
Message-ID: <CABfm+kS1_nW+ErBTw5m0WRFRyrrJGcseoUjU=Xnu_XmSoo4ptw@mail.gmail.com>
To: Dan Scott <dan@coffeecode.net>
Cc: Madeleine Rothberg <madeleine_rothberg@wgbh.org>, Charles McCathie Nevile <chaals@yandex-team.ru>, Andy Heath <andyheath@axelrod.plus.com>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, "<public-vocabs@w3.org>" <public-vocabs@w3.org>, Gerardo Capiel <gerardoc@benetech.org>, Dan Brickley <danbri@google.com>, Alexander Shubin <ajax@yandex-team.ru>, Egor Antonov <elderos@yandex-team.ru>, Liddy Nevile <liddy@sunriseresearch.org>, Charles Myers <charlesm@benetech.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, George Kerscher <kerscher@montana.com>, Jason Johnson <jasjoh@microsoft.com>, Matt Garrish <matt.garrish@bell.net>
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 <dan@coffeecode.net>

> 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=²http://schema.org/Movie²>
> > <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 http://schema.org/Movie, 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="http://schema.org/Movie">
>   <div itemprop="accessDescription" itemscope itemtype="
> http://schema.org/AccessibilityMode">
>     Accessible to sighted users
>     <meta itemprop="accessMode" content="visual"/>
>     <meta itemprop="accessFeature" content="audioDescription"/>
>   </div>
>   <div itemprop="accessDescription" itemscope itemtype="
> http://schema.org/AccessibilityMode">
>     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 a11y-metadata-project+unsubscribe@googlegroups.com.
> To post to this group, send email to
> a11y-metadata-project@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Emmanuelle Gutiérrez y Restrepo
Fundación y Seminario SIDAR
URL: www.sidar.org
email: emmanuelle@sidar.org
Received on Sunday, 8 September 2013 22:48:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:30 UTC