- From: Rachana Iyer <rachanakrishna.iyer@gmail.com>
- Date: Thu, 18 Jun 2015 20:51:14 +0530
- To: Jim Tobias <tobias@inclusive.com>
- Cc: Jutta Treviranus <jutta.treviranus@utoronto.ca>, "chaals@yandex-team.ru" <chaals@yandex-team.ru>, WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <CACL2DJSa6rEkCLtcx9xeWw_0rS4M0OWofYoX26SQ-iHMPKrMbw@mail.gmail.com>
Can someone please take me off these emails. I did not subscribe to them and am clueless about how to stop it. Thanks! On Thu, Jun 18, 2015 at 8:39 PM, Jim Tobias <tobias@inclusive.com> wrote: > Thanks, Jutta, for your excellent contribution to a fascinating discussion. > > A corollary to using the affirmative names of accessibility features > (e.g., 'captions') to index resources is that consumers would have to know > the names of the features they need or prefer, and be active in seeking > them out. While this is true for advanced consumers -- in fact, it could be > the definition of 'advanced consumer' -- it is probably not true for large > majorities of consumers, with or without disabilities. I'm not saying this > to argue that experts rather than consumers should be in charge of naming > the features. I'm saying that the eventual success of the whole enterprise > might depend more on improvements in demand than in supply. This would > require a pretty big cultural shift -- a culture of usability, or of > universal personalization, beginning with mass awareness of the very > existence of interfaces. > > *** > Jim Tobias > Inclusive Technologies > +1.908.907.2387 v/sms > skype jimtobias > > > > -----Original Message----- > > From: Jutta Treviranus [mailto:jutta.treviranus@utoronto.ca] > > Sent: Thursday, June 18, 2015 9:38 AM > > To: chaals@yandex-team.ru; WAI Interest Group > > Subject: Re: Schema.org - identifying accessible documents > > > > Hi Charles, > > Thank you for bringing this important topic to a larger group for input. > > > > As to the specific example of markup you have asked us to consider: > > > "you need to be able to understand english-language text and to hear, > OR to be able to understand english language text > > and see, in order to effectively use this site". (The underlying use > case is a video which has both audio descriptions, and > > captions, available as an option in the player, but making these things > up is easy and there are lots of variations). > > > > What does your description add that simply stating that this resource or > document "has captions," "has descriptions", and > > that the language "is english" doesn’t achieve? In fact your description > is much more complex and also confusing because > > you would not need to be able to understand english language text if you > can hear, you could listen to the speech audio > > and understand spoken english. (I have left your message below my reply > in its entirety for easier reference.) > > > > (Written as my personal point of view and not as a representative of any > of the organizations mentioned:) > > As you know this is linked to the discussion within the ISO JTC1 SC36 > working group regarding the ISO 24751 and IMS > > AccessForAll standard which seeded the schema.org accessibility > metadata effort. Although the ISO standard is intended to > > support more than finding documents. It is intended to enable a number > of processes used to match an individual’s > > personal accessibility needs. This includes things like adjusting > display preferences or style preferences, and adjusting > > system preferences to match an individual’s needs, all the way to > issuing a request from a service to fill a gap e.g., missing > > or poorly authored captions. This also supports efforts such as the GPII > and FLOE (http://gpii.net and > > http://floeproject.org). Attached to this is an extensible set of > utilities that support the discovery and exploration of what > > works best for you as an individual. The intention is that a personal > preference file that you create becomes portable and > > can be used to invoke the required settings and resources wherever the > individual may need them without the need to > > negotiate, explain or justify requirements; for "one-size-fits-one" > accessibility. > > > > On a general level, the debate boils down to who gets to come up with > the labels and the categories that describe > > individual needs and preferences: is it collectively the individuals who > are experiencing the barriers to access or is it the > > developers and the arbitrary group of individuals that happen to be part > of the standards working groups, many of whom > > know nothing about the barriers. The contention is that we can make it > possible for individuals who experience the > > barriers to drive this process. That it is possible to create an open > and transparent process for negotiating a common > > understanding of the labels or metadata terms for an extensible set of > needs and preferences, that supports the > > participation of individuals that experience the barriers, and that > these can then be codified into machine-readable > > metadata of various forms (and also used in other matching processes). > The implicit alternative view is that the categories > > and labels are formulated by a standards body with no representation by > people with disabilities, and to extend these > > labels and categories requires participation in these standards bodies. > Associated with this is the contention that the > > process does not need to be accessible, thereby ensuring that many > people with disabilities will not be able to participate. > > > > Lastly, if we include the ISO discussions, I think the argument is also > about how we approach this important challenge: can > > we make this an exercise about what emerging technical capabilities we > can use to match and address the individual needs > > and preferences of real people who face barriers on real people’s terms > (and thereby potentially advance the process of > > individualized customization or personalization for all people), or is > this an exercise in the concessions that can be made by > > metadata authors in labelling documents or resources for people who are > "not capable" of using the resources? > > > > I would invite us to rise to the challenge of empowering real people to > decide how they want to describe and categorize > > their real needs and preferences. > > > > thanks > > Jutta > > > > > > > > > On Jun 17, 2015, at 5:53 PM, chaals@yandex-team.ru wrote: > > > > > > Hi folks, > > > > > > TL;DR: I am looking for opinions on how to identify resources so it is > easier for a given person to find content accessible to > > them. > > > > > > Details… > > > > > > you may know http://schema.org - it is now used on about 1/3 of the > web that search engines index. Its purpose is to > > provide information that lets search engines understand better what > there is in a page or site. Yes, we are implementing > > proposals from the mid-1990s. > > > > > > One of the things we have started at schema.org is adding information > to content so people can find stuff that is > > accessible to *them*. This is a complementary approach to getting people > to do a better job of producing content that is > > more generally accessible, not a replacement. But the point still stands > that a game totally unusable for a blind person may > > be fine for a given person with autism spectrum issues, and a site that > cannot be used by a deaf person may nevertheless > > be quite useful for someone with a certain level of visual disability. > > > > > > Right now in schema.org we have a few ways to talk about some > characteristics of web resources > > http://schema.org/accessibilityHazard and > http://schema.org/accessibilityControl are fairly straightforward - > although I will > > work on better documentation for them, and probably explain them further. > > > > > > One is that a web page can state whether it has an accessibility > hazard, such as flashing - so people who are sensitive to > > flashing content, such as those with photosensitive epilepsy, some > people with autism spectrum issues, and some people > > who just find it hard to concentrate, can avoid that content. > > > > > > accessibilityControl is to make it clear that a site can be used e.g. > with keyboard-only, or with voice control systems. > > > > > > We also have http://schema.org/accessibilityFeature which can be used > to note that a page has some feature useful for > > improving accessibiity, such as captions for audio or video, > descriptions for images, simple text, etc. There are also features > > of schema.org that can be used to describe the language of a resource, > relationships between various parts, and so on. > > > > > > The problem is we don't have a good mechanism for describing how you > can interact with a resource. Asking for content > > where the images have descriptions is fine, but irrelevant where there > are no images in the first place. And asking > > developers to explicitly state all the cases that are irrelevant to > their content strikes me as unscalable (and not very bright in > > the first place). > > > > > > My initial thinking is that we should describe "accessModes" for > content, such as "you need to be able to understand > > english-language text and to hear, OR to be able to understand english > language text and see, in order to effectively use > > this site". (The underlying use case is a video which has both audio > descriptions, and captions, available as an option in the > > player, but making these things up is easy and there are lots of > variations). > > > > > > This would enable us to later refine statements, such as "you need to > understand written english to a senior high school > > level and be able to read 24pt yellow text with black outlines on a > changing background at about 80 words per minute, OR > > you need to understand spoken english at a junior high school level and > be able to discern it against a low level of > > background noise" - but would still make it possible for people to > meaningfully work with the statements at the first level > > of detail., and not fail because most developers didn't provide > sufficient detail about their content. At the same time, there > > is an incentive for being more accurate. > > > > > > Two arguments have been raised against this approach. > > > > > > The first is that it is enforcing a "medical model" of disability, > rather than allowing people to state their own preferences > > and needs. As far as I can see this logic is false. The model here > allows people to state, in as much or little detail as they > > want for a given situation, what capabilities they have, and enables > search systems to match resources against the > > particular capabilities or preferences of a particular individual in > real time. > > > > > > The second is that not all capabilities can easily be expressed > linearly. This I believe may be true. But as an initial approach > > it seems that we can describe a lot of things usefully in this way, and > that will at least enable us to learn a lot and provide a > > lot of incentives for a minimal amount of description to be added to > resources that will in turn enable real people to find > > real resources that meet their real needs, rather than letting perfect > be the enemy of good. > > > > > > I am wondering what I have missed, what people think about these > approaches, whether from the perspective of a user, > > a content producer, or a toolmaker (or all of the above, as some are), > and what people would like to know more about > > regarding this aspect of the work done in schema.org > > > > > > We are aware that we are not very advanced yet. While some schema > properties are used on millions or tens of millions > > of domains, the accessibiltiy properties we have are used on tens or > hundreds of domains. Improving awareness and > > improving what we do might help to raise that substantially, in turn > making it easier to find material that work for *you*… > > > > > > so comments are welcome. Please feel free to forward this message. If > replies are not going to come back here (at least > > in summary), feel free to cc me directly. I'll also make some more space > on the relevant wiki pages for further discussion of > > these issues. > > > > > > cheers > > > > > > Chaals > > > > > > -- > > > Charles McCathie Nevile - web standards - CTO Office, Yandex > > > chaals@yandex-team.ru - - - Find more at http://yandex.com > > > > > > >
Received on Thursday, 18 June 2015 15:21:43 UTC