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

Re: Schema.org - identifying accessible documents

From: <chaals@yandex-team.ru>
Date: Mon, 22 Jun 2015 00:28:53 +0200
To: Jutta Treviranus <jutta.treviranus@utoronto.ca>, WAI Interest Group <w3c-wai-ig@w3.org>
Message-Id: <216131434925733@webcorp01h.yandex-team.ru>
Hi Jutta,

18.06.2015, 15:39, "Jutta Treviranus" <jutta.treviranus@utoronto.ca>:
> 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?

1. The fact that the same search query will also find a silent film, or one which is actually self-descriptive or visually dull enough not to need any description (e.g. me giving a talk).
2. It is apparently easier (having done the thought experiment and worked through a number of examples) to arbitrarily extend the level of granularity, without requiring everyone to update and match the possible granularity in order to successfully use the system.

> In fact your description is much more complex

I'm not sure that's true when you have a formal vocabulary to make the statements. But that's certainly a question we need to explore.

> and also confusing because you would not need to be able to understand english language text

Yeah, that was just a straight-up mistake - it should be "language"

> 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.

Right. Whereas schema.org's goal is very tightly focused on enabling people to select from a large set of resources - often millions - the ones that are most useful to them which may only be a handful, and which will be better or worse in various dimensions.

> 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.

Yes. That is something that we expect schema to enable too - indeed it more or less follows from any workable solution.

> 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:

No, on a general level the question is how to build things that work at the scale of mass-market search engines, will be implemented by millions of developers, and helpful to hundreds of millions of users.

The point of asking my questions is to find what matches the real needs of the end users searching, the developers we are asking to mark up their content, and the software that provides the connections.

If we don't work with all these groups of people, then we run a real risk of missing something important.

> The contention is that we can make it possible for individuals who experience the barriers to drive this process.

Sure. Among the many experts in this list are people who match at leat the first two categories I mentioned above.


>>  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

Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Sunday, 21 June 2015 22:29:26 UTC

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