- From: Matt Garrish <matt.garrish@bell.net>
- Date: Thu, 31 Oct 2013 15:18:19 -0400
- To: "'Matt Garrish'" <matt.garrish@bell.net>, "'Andy Heath'" <andyheath@axelrod.plus.com>, "'Liddy Nevile'" <liddy@sunriseresearch.org>
- CC: "'Madeleine Rothberg'" <madeleine_rothberg@wgbh.org>, "'Charles Myers'" <charlesm@benetech.org>, <a11y-metadata-project@googlegroups.com>, <public-vocabs@w3.org>
And a final thought, but even if accessMode were to change to some other form in the future to express multiple concepts in one property, it doesn't seem like it would invalidate starting with the definition we have now, as it would simply be more expansive in terms of coverage. Matt -----Original Message----- From: Matt Garrish [mailto:matt.garrish@bell.net] Sent: October-31-13 15:02 To: 'Andy Heath'; 'Liddy Nevile' Cc: 'Madeleine Rothberg'; 'Charles Myers'; a11y-metadata-project@googlegroups.com; public-vocabs@w3.org Subject: RE: [a11y-metadata-project] Reminder of accessibility metadata call coming up in an hour (9:00 AM PDT) To jump in from a slightly different angle, I'm not convinced it's realistic to expect these combinations in an online ebook store, for example, or that they would have any value. Legally it's questionable whether you could market your work as something it's not, as access to these modes being discussed is, more often than not, not intrinsic in the author's presentation, but may depend entirely on support in the user's reading system to gain access to. Someone using a mainstream device may not realize what they are getting, or what has happened to their expected access mode until after the purchase, so not only would publishers be hesitant to go near this, but I expect ebookstores would just filter it out and ignore it even if we were to put it in. accessMode and mediaFeature as they were defined in the original proposal make for simple facet searching in such an interface, and don't prescribe what is useful to the reader, on the other hand. I'd feel more comfortable allowing ebookstores, at least, to come up with the shorthands as real need arises, that they can document to their users, removing the opaqueness of what any given author was thinking when they set them. I'm not against the quest for web simplicity being expressed here, but from where I sit I'm still worried that we're losing sight of what we'd set out to achieve, namely to move ahead with what we know and look at these kinds of specializations and shorthands later as we could more objectively analyze the need and requirements. Can we not extricate accessMode as it was defined for the primary way in which the author conveyed information from the discussion and keep moving with it as originally defined? If a combinatory shorthand has value, it shouldn't clobber either of the properties that feed into it. It seems like we don't need to rush this piece for a 1.0, either, since the information is carried by the existing two properties. And, since it's new and untested, I'd prefer we didn't rush into just to make a first release, but gave ourselves time to figure out all the ramifications. Matt -----Original Message----- From: Andy Heath [mailto:andyheathaxelrod@googlemail.com] On Behalf Of Andy Heath Sent: October-31-13 06:41 To: Liddy Nevile Cc: Madeleine Rothberg; Charles Myers; a11y-metadata-project@googlegroups.com; public-vocabs@w3.org Subject: Re: [a11y-metadata-project] Reminder of accessibility metadata call coming up in an hour (9:00 AM PDT) Liddy - this is "Access for All" not "Access for Disabled People". You are NOT entitled to say what is accessible to me (and I get angry when people try to do so). Its *my* choice as to what I can use - that has always been a tenet of our work. andy > 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+M eeting+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_th is_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. > > andy andyheath@axelrod.plus.com -- __________________ Andy Heath http://axelafa.com
Received on Thursday, 31 October 2013 19:18:51 UTC