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

Common use cases we have not really discussed much are based on what happens in integrated classrooms where teachers are trying to serve both students with no disabilities and student(s) with different disabilities.  Below are some use cases based on my experiences with users of our Bookshare web library and it's related applications:

1) A teacher, student or parent of a dyslexic student needs to find an adaptation of or different format for a particular textbook ISBN that has been assigned to a regular class that fits the disability of the student.  It could be they are just looking for the DAISY version of the book, which may or may not have described images.  If the textbook contains mathematical expressions, they would prefer textbooks that had the math encoded in MathML, but would be satisfied enough to know that the textbook can at least be used with a product like Read2Go, which only supports DAISY 3 full-text books and has synchronized word-level highlighting.

2) A teacher is looking for different learning resources across a range of media types that can be used in an integrated classroom that has students with and without disabilities.  He/she would prefer to find resources that natively do not require any special accessibility related adaptations, but would be ok if they did.  He or she wants to be able to read through the search results and make a determination based on the formats used (e.g. video, audio), whether they have been adapted and the quality/ relevance of the resources.  They would prefer to get as much information as possible about the resources from the search results and make their own determination, not a determination made by an algorithm.

3) A use case that we will see more and more is similar to #2, but related to an EPUB 3 textbook or an online course that mixes lots of different forms of media in one package.

4) A teacher might be looking for a book, which doesn't have any textual content, but purely human narration of the text and image descriptions.

Some of these use cases indicate a need for the user to know about the combination of access modes the resource uses and what adaptations exist within the resource to support the assistive technology used by the end user.  I believe that merging accessMode and mediaFeature into one property makes it harder for users to make those determinations themselves.

Gerardo

Gerardo Capiel
VP of Engineering
benetech

650-644-3405
Twitter: @gcapiel
Fork, Code, Do Social Good: http://benetech.github.com/



On Sep 9, 2013, at 11:27 PM, Liddy Nevile <liddy@sunriseresearch.org> wrote:

> 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
>