- From: Liddy Nevile <liddy@sunriseresearch.org>
- Date: Thu, 31 Oct 2013 21:11:25 +1100
- To: Andy Heath <andyheath@axelrod.plus.com>
- 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>
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