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

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

From: Liddy Nevile <liddy@sunriseresearch.org>
Date: Tue, 10 Sep 2013 16:27:48 +1000
Cc: Charles Myers <charlesm@benetech.org>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, Alexander Shubin <ajax@yandex-team.ru>, Andy Heath <andyheath@axelrod.plus.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, Dan Scott <dan@coffeecode.net>, Dan Brickley <danbri@google.com>, Egor Antonov <elderos@yandex-team.ru>, Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>, Gerardo Capiel <gerardoc@benetech.org>, Jason Johnson <jasjoh@microsoft.com>, George Kerscher <kerscher@montana.com>, Madeleine Rothberg <madeleine_rothberg@wgbh.org>, Matt Garrish <matt.garrish@bell.net>, "<public-vocabs@w3.org>" <public-vocabs@w3.org>
Message-Id: <17A0513F-77C6-47FA-8BE0-BD3BB596DE1D@sunriseresearch.org>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
mmm

.. the discussion seems again to focus on the name for the set of  
possibilities. My problem is with having this set and the other set. I  
prefer a model where the details are related to the more general ie  
where there is a clear connection between audio and captions etc. I  
will try to show what I mean in a diagram asap, putting all we have  
together into a map...

Liddy


On 09/09/2013, at 11:42 PM, Richard Schwerdtfeger wrote:

> I agree with mediaFeature for extensibility and because we should  
> not limit to accessibility. We should not be limited to  
> accessibility. We could express a media alternative but we need to  
> be able to quickly that it supports certain access features to  
> achieve a match. AccessAlternative on its own is not enough as we  
> would need to know what accessfeatures it supports.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
> <graycol.gif>Charles Myers ---09/09/2013 05:58:40 AM---This property  
> has had three names over the editorial history of the spec.  
> hasFeature was the start (
>
> From:	Charles Myers <charlesm@benetech.org>
> To:	Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>,
> Cc:	Dan Scott <dan@coffeecode.net>, 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 
> >, Richard Schwerdtfeger/Austin/IBM@IBMUS, George Kerscher <kerscher@montana.com 
> >, Jason Johnson <jasjoh@microsoft.com>, Matt Garrish <matt.garrish@bell.net 
> >
> Date:	09/09/2013 05:58 AM
> Subject:	Re: [a11y-metadata-project] Schema.org accessibility  
> proposal Review...
>
>
>
>
> This property has had three names over the editorial history of the  
> spec.
>
> hasFeature was the start (going fro AfA, I believe).  That was too  
> generic to fit into creating work (it would confuse almost anyone)
> accessibilityFeature was next, which at least told the use
> adaptationFeature followed that, which told was it was useful for.
>
> However, there were three items that were neither just for  
> accessibility or adaptations.  These were MathML, ChemML and Latex.
>
> mediaFeature followed that That caused us to say that the features  
> were not limited to just accessibility.  And they are not  
> alternatives.
>
> Now we propose mediaAlternative and AccessAlternative.  Or even  
> AccessFeature.  These all have the same problem.  As someone pointed  
> out, mediaFeature has the advantage of being extensible for  
> expressing semantics beyond just accessibility, which may improve  
> the chance of widespread adoption.
>
>
>
>
> All that history aside, I do like the lumping of accessMode and the  
> features/alternatives (whatever name you use).  But note that many  
> of the features, like tactilegraphic and ChemML defy that a bit.
>
> I'd want to work it out in a chart, much like the practical  
> properties guide https://wiki.benetech.org/display/a11ymetadata/Practical+Properties+Guide 
>  does for the current method.
>
> On Sep 8, 2013, at 3:48 PM, Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org 
> > wrote:
> 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  
> appropriate, 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.
>
> Best,
> Emmanuelle
>
>
> 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 Tuesday, 10 September 2013 06:35:13 UTC

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