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

Re: [a11y-metadata-project] Reminder of accessibility metadata call coming up in an hour (9:00 AM PDT)

From: Liddy Nevile <liddy@sunriseresearch.org>
Date: Thu, 31 Oct 2013 21:11:25 +1100
Cc: Madeleine Rothberg <madeleine_rothberg@wgbh.org>, Charles Myers <charlesm@benetech.org>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
Message-Id: <66C8C775-B414-4B05-8680-42B783856D7A@sunriseresearch.org>
To: Andy Heath <andyheath@axelrod.plus.com>
mmm... now I think you have misunderstood or misread me, Andy.

The particular video being described is only accessible with the  
declared combinations - so audio alone will simply not cut it - it  
does not have what that requires... so ????


On 30/10/2013, at 9:05 PM, Andy Heath wrote:

> Liddy,
>
> I think your example is a good one to explain exactly why it *won't*  
> work like that.  The problem is it gives too much weight to the  
> author and not the context.  For example, for a video with captions  
> your example gives the metadata
>
> visual + auditory
> visual
> visual + text
>
> as describing the modalities that "is required to be able to
> comprehend and use a resource."
>
> This is *as the author sees it*.
> So what other ways are there to see it ?
>
> Well what about using the auditory mode alone ? (I do this very  
> often with the kind of videos that are just talking heads - the bbc  
> don't think of that usage but I still do it - I even turn the  
> brightness down to black to save battery while doing that).   
> Similarly for text.  So the full set of accessModes required to  
> understand it here would need to include
>
> auditory
> text
>
> But authors don't think of these things - only users do. And in  
> general we won't think of all the ways people might want to use the  
> content. Expanding all the accessModes exhaustively would be  
> pointless as an algorithm could do that trivially.  And even now, I  
> just went back and re-read it and realised I didn't think of  
> "auditory + text". This seems to me has been a central point of our  
> work over the years - to NOT project onto users how they should use  
> things but instead to give users control.  Author ideas of how to  
> use stuff is not giving users control in my view.
>
> Charles (Myers) - the point ascribed to me as the need for a common  
> data model in the other email - I'm afraid I haven't expressed  
> myself clearly enough - my point was subtly different to what its  
> reported as. My point was that we need a common data model yes, but  
> we should use different fields for the physical access modes present  
> and the author's view of how that resource "should be used".  For  
> example, if we *do* decide to provide author-deteremined-usage info  
> (which I don't support but ..) then using this same example of  
> Liddy's the metadata might be something like
>
> accessMode = visual
> accessMode = auditory
> accessMode = text
>
> accessModeUsage = visual + auditory
> accessModeUsage = visual
> accessModeUsage = visual + text
>
> This is repetitious and has redundant information and doesn't look  
> good - there may be more economical ways to express it but mixing  
> the accessMode usage and the physical accessModes in the same fields  
> will lead people towards the mixed model - i.e. we will have to  
> explain the "+" calculus of values relating to accessMode and this  
> will overcomplicate the simple description. So my point was, even  
> though the two different ways to use accessMode *could* use the same  
> fields i.e. they could just be alternative ways to use those fields,  
> we should still separate them.  The fact is that the meaning of say  
> "visual" is different in each case - in one case it means  
> "physically present" and in the other it means "how I think you  
> might use it".  There is no case in my mind to use the same fields  
> for these very different uses.
>
> andy
>
>> Madeleine,
>> you seem to have misunderstood me.
>>
>> I am saying, as Charles Nevile also understands it, I believe, that  
>> when
>> stating the accessMode, one states what is required to be able to
>> comprehend and use a resource.
>>
>> If there are a range of things available, say video (incl audio) and
>> captions, some users will use the audio and some the captions -  
>> correct?
>> In this case, the video could have assessModes:
>>
>> visual + auditory
>> visual
>> visual + text
>>
>> A user who wants captions would probably have visual + captions in  
>> their
>> profile. It is easy to infer that they want the video with the  
>> captions
>> on the screen (however they get there) - they might also get the  
>> sound
>> but as they have not included it, that is not an accessMode they are
>> asking for. Clearly they will want this resource - no?
>>
>> A person who does not have vision might also be interested in this
>> resource. They will probably say their accessModes are text and  
>> auditory
>> and so they are not likely to want this resource - they have not
>> included visual and the resource is, apparently, incomplete without  
>> it.
>>
>> What is different about this?  I think I was just adding, in my  
>> email,
>> that this can be done so the resource description and user needs
>> statements of accessModes must not get concatenated, which would make
>> them useless, and that this prohibition is possible - contrary to  
>> what
>> normally happens with metadata.
>>
>> Liddy
>>
>> On 30/10/2013, at 3:32 AM, Madeleine Rothberg wrote:
>>
>>> Liddy,
>>>
>>> I can't write a full response because I am in another meeting, but I
>>> want to stress that the idea you have raised of a minimum complete  
>>> set
>>> of accessModes is useful but should not replace access mode as
>>> previously defined. I believe we must retain the access mode field
>>> that lists the access modes a resource uses to communicate. When
>>> alternatives are added or linked then more access mode combos become
>>> viable and that can feed into the list of various minimum complete
>>> sets of accessModes.
>>>
>>> Madeleine
>>>
>>> On 2013-10-29, at 12:04 PM, "Liddy Nevile" <liddy@sunriseresearch.org 
>>> >
>>> wrote:
>>>
>>>> My comments...
>>>>
>>>> Charles Nevile ...
>>>> Charles raised the question of whether these attributes are a
>>>> declaration of conformance (as in alternativeText means that "all  
>>>> of
>>>> the photographs and other media have alternate text") or just  
>>>> whether
>>>> the author of the content (or adapted version of the content) used
>>>> alternate text on the significant parts of the content to the  
>>>> best of
>>>> their abilities. The intent of these are the latter. Since this
>>>> metadata is being added by people who care about accessibility, we
>>>> have to trust that they will apply their best efforts before they'd
>>>> add the attribute.
>>>>
>>>> It has long been a tradition in the DC world of metadata to assume
>>>> that people have good intentions - they don't always, but those who
>>>> do make it worthwhile trusting...
>>>>
>>>> then there is a discussion about mediaFeature.... I am developing
>>>> some fairly strong feelings baout this. First, I don't think
>>>> 'mediaFeature' is anything like as good a name as accessFeature '
>>>> given that we are mostly describing things that are done to  
>>>> increase
>>>> accessibility - and we have accessMode...  Then Jutta wanted us to
>>>> add in 'adaptation' or the equivalnet. I think that a feature  
>>>> implies
>>>> something special but taking Jutta's position it might be better to
>>>> have them called accessAdaptation - ie for things like captions
>>>> etc??? Certainly I would not want both feature and adaptation in a
>>>> single name - that would be introducing redundancy, I think...
>>>>
>>>> Next, I think the idea that we should label things because someone
>>>> tried to fix it is absurd - to be honest. We are asking people to
>>>> make assertions about the resource, or their needs, not to tell us
>>>> how nice they are. An assertion, made in good faith, should mean  
>>>> that
>>>> something has been achieved - eg alt tags for all images, etc ....
>>>>
>>>> Next, I want us to be clear about accessMode. As Charles Nevile  
>>>> and I
>>>> understand it, this will be a set of assertions that tell us what  
>>>> is
>>>> the minimum complete set of accessModes that will convey all the
>>>> content of a resource. So we might get visual + text, visual +  
>>>> audio,
>>>> text, etc ... ie more than one statement. This can be done and it
>>>> involves a trick - generally the value of RDF means that if I  
>>>> make an
>>>> assertion and then you add another, both bits of info can be put
>>>> together to make a richer statement. In this case, we certainly do
>>>> not want that to happen! In RDF the merging of statements can be
>>>> avoided by using what is known as a 'blank node'.
>>>> I am writing all this because I think  both being clear about the  
>>>> use
>>>> of accessMode and knowing that it will work is really important :-)
>>>>
>>>>
>>>> On 23/10/2013, at 1:53 AM, Charles Myers wrote:
>>>>
>>>>> I'm back and caught up on accessibility metadata from the calls of
>>>>> two weeks ago.  The eganda for today's meeting cal be seen below  
>>>>> and
>>>>> at
>>>>> https://wiki.benetech.org/display/a11ymetadata/Next+Accessibility+Metadata+Meeting+Agenda
>>>>>
>>>>>
>>>>> I also wrote our minutes from the last two meetings at
>>>>> https://wiki.benetech.org/pages/viewpage.action?pageId=58853548  
>>>>> and
>>>>> the issue tracker has been updated on the mediaFeature
>>>>> issue.http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#What_is_the_goal_of_mediaFeature.3F_.28conforming_or_informational.29_Do_we_have_this_right.3F
>>>>>
>>>>>
>>>>> Note that we have a new conference call number this week.  And we
>>>>> will be back on a regular weekly schedule from this point on.
>>>>> October 22, 2013 Accessibility Metadata working group call
>>>>> Weekly Meeting
>>>>> Schedule: The next call will be Tuesday, October 22, 9:00am PDT
>>>>> (California), 12:00am EDT (Ontario, New York), 5:00PM in London  
>>>>> and
>>>>> 6:00 PM on the continent, 3:00 AM in Australia
>>>>> Conference call: +1-866-906-9888 (US toll free), +1-857-288-2555
>>>>> (international), Participant Code: 1850396#
>>>>> Etherpad: (10/22/2013)
>>>>> IRC: Freenode.net #a11ymetadata (although more of the collab seems
>>>>> to happen in the etherpad)
>>>>> The goal of the call will be a review of the open issues on the  
>>>>> w3c
>>>>> wiki and get to closure on these issues and work these with
>>>>> schema.org representatives.  See issues and accessMode/ 
>>>>> mediaFeature
>>>>> matrix. There will also be a discussion of the use of these
>>>>> attributes for search, as shown in the blog article.
>>>>>
>>>>> The next call will be October 22 and then will settle into weekly
>>>>> meetings as required.
>>>>>
>>>>> The public site is http://www.a11ymetadata.org/ and our twitter
>>>>> hashtag is #a11ymetadata.
>>>>>
>>>>> Overall Agenda
>>>>> New Business - We will start discussing this promptly at the top  
>>>>> of
>>>>> the hour.
>>>>>
>>>>>   mediaFeature - our goal is to get agreement on the mediaFeature
>>>>> properties, as noted in the issue list.  As noted in the last  
>>>>> call's
>>>>> minutes, we did a deep dive into visual and textual transform
>>>>> features last time. I've editted the list down to reflect both new
>>>>> properties that we decided on last time and some of the
>>>>> simplifications that come with the extension mechanism. I'd like  
>>>>> to
>>>>> reach a conclusion on those, both for the specific names but also
>>>>> for the general framework, so that one can see the extension
>>>>> mechanism.  I'd like to propose even that we segment this  
>>>>> discussion
>>>>> into two parts... agreement on the current properties and then
>>>>> consideration of new properties (I want to see the discussion make
>>>>> progress)
>>>>>       transformFeature - do we mike that name (against the
>>>>> "content feature")
>>>>>           Finish discussion on visualTransformFeature and
>>>>> textualTransformFeature
>>>>>           Consider auditoryTransformFeature (structural  
>>>>> Navigation
>>>>> will be covered in textualTransform) and tactileTransform
>>>>>       Review contentFeature side of the mediaFeatures starting
>>>>> from the proposed table in the issues list
>>>>>           textual (note the removal of desacribedMath) -
>>>>> alternativeText, captions, chemML, laTex, longDescription, mathML,
>>>>> transcript
>>>>>           tactile (note the simplication of braille to be the
>>>>> extended form) - braille, tactileGraphic, tactileObject
>>>>>           auditory - audiDescription
>>>>>           visual - signLanguage, captions/open
>>>>>   ATCompatible
>>>>>   ControlFlexibility and accessAPI (we'll be lucky if we get to
>>>>> this point)
>>>>>   accessMode and the three proposals for the available access
>>>>> modes (this is a topic for a future call)
>>>>>   is/hasAdaptation
>>>>> --
>>>>> 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.
>>>>
>>>> --
>>>> 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.
>>>
>>> --
>>> 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.
>>
>
>
>
>
> andy
> andyheath@axelrod.plus.com
> -- 
> __________________
> Andy Heath
> http://axelafa.com
>
> -- 
> 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.
Received on Thursday, 31 October 2013 10:12:04 UTC

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