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

And I'll point out two things from the call.

1) That our overall goal is to make simple things easy and the difficult 
possible. That's a good W3C perspective.
and then
2) Andy suggested  that the most important thing was to agree on a 
common data model. There may be multiple paths (different sets of 
metadata) to that model for different levels of complexity, but they all 
work towards the same data model with clear paths.

I still believe that the issue is that we're looking at is that access 
modes mean multiple things to multiple people.
But, now that we're in agreement on mediaFeature as much as we can, it's 
now time to consider accessMode. I'll create my writeup and get it up on 
the wiki soon. Hopefully, this can achieve a common data model and some 
use cases against it. I believe that this can express access modes in 
ways that work for all, from implied to explicit to after augmentation 
(the "desitnation" access modes).


On 10/29/2013 9: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.