W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2015

Re: Schema.org - identifying accessible documents

From: Rachana Iyer <rachanakrishna.iyer@gmail.com>
Date: Thu, 18 Jun 2015 20:51:14 +0530
Message-ID: <CACL2DJSa6rEkCLtcx9xeWw_0rS4M0OWofYoX26SQ-iHMPKrMbw@mail.gmail.com>
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>
Can someone please take me off these emails. I did not subscribe to them
and am clueless about how to stop it.


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

This archive was generated by hypermail 2.3.1 : Thursday, 25 May 2017 01:54:15 UTC