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

Re: [a11y-metadata-project] Re: clearing the logic...

From: Liddy Nevile <liddy@sunriseresearch.org>
Date: Thu, 26 Sep 2013 22:43:55 +1000
Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, Charles Myers <charlesm@benetech.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, Alexander Shubin <ajax@yandex-team.ru>, Andy Heath <andyheath@axelrod.plus.com>, Dan Scott <dan@coffeecode.net>, Dan Brickley <danbri@google.com>, Egor Antonov <elderos@yandex-team.ru>, Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.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: <898ED76D-6DF9-419D-8D69-16C8E22453E5@sunriseresearch.org>
To: Gerardo Capiel <gerardoc@benetech.org>
A thought-line from me.

I am not keen to go on working with what we think we have inherited  
because I don't believe it is going to work. I have tried to think out  
what we need again, building on previous experience, and taking into  
account what I have been learning about schema.org.

I think it is worth thinking about what I have here.

I think this might work for schema.org - see below

-----------------------

The requirement is a set of terms with values that allow for the  
description of both a user's needs and a resource's characteristics.

I think that for any resource, we could ask for terms to describe:
* accessHazards
* accessModes and
* accessFeatures.

So a resource description might be:
Resource:
-[Type]-> video
-[accessHazard]-> flashing

-[accessMode]-> audio+visual
-[accessMode]-> visual+text
-[accessMode]-> audio

-[mediaFeature]-> audioDescription
-[mediaFeature]-> captions
-[mediaFeature]-> highContrastCaptions

(or
-[mediaFeature]-> captions
   -[subType]-> highContrastCaptions )

AccessModes list the possible combinations of accessModes that provide  
complete perception of a resource.  A user who for some reason can't  
use audio might be really happy with this resource. They would be  
satisfied with the 'visual + text' version and take advantage of the  
accessFeatures.

A user 'X' who is looking for a suitable resource will need to specify  
their needs.
User X wanting to avoid audio and have highContrastCaptions might say:

accessMode: visual, text
accessFeatures: audioDescription, captions, highContrastCaptions

and it might be inferred that they do not want audio - even though  
this is not stated specifically. This means that the user is not  
necessarily going to not get audio but what they will get is  
sufficient for their perception of the resource.

Another user 'Y' with reasons for not wanting visual might say:

accessHazard: flashing
accessMode: audio

In this case, they do not say they don't want visual but they make it  
clear they want all content to be available to them via audio and to  
not get any flashing hazards....

---------------------------------------
If we have a suitable ontology, when a user states that they want  
captions, and does not state that they want audio, can we assume they  
want a resource in a form that does not have audio as a dependent mode  
for perception? ie they would not want to be given something that has  
accessMode audio + text but they would be happy with a resource that  
has video + text as one form even if it also happens to have some audio.
Received on Thursday, 26 September 2013 14:56:51 UTC

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