- From: Andy Heath <andyheath@axelrod.plus.com>
- Date: Wed, 30 Oct 2013 10:05:01 +0000
- To: Liddy Nevile <liddy@sunriseresearch.org>, Madeleine Rothberg <madeleine_rothberg@wgbh.org>
- CC: Charles Myers <charlesm@benetech.org>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
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
Received on Wednesday, 30 October 2013 10:05:34 UTC