RE: Schema.org - identifying accessible documents

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:09:49 UTC