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

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



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