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

Re: Schema.org - identifying accessible documents

From: Christophe Strobbe <strobbe@hdm-stuttgart.de>
Date: Thu, 18 Jun 2015 20:19:33 +0200
Message-ID: <55830BB5.20301@hdm-stuttgart.de>
To: w3c-wai-ig@w3.org
Hi,

On 18/06/2015 15:38, Jutta Treviranus wrote:
> Hi Charles,
> <snip>
>
> (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.  
We have also learned from the Cloud4all project, which contributes to
GPII, that many users don't know how to describe their needs and
preferences (or at best vaguely), except if they are very advanced ICT
users.
This need not be an either/or discussion with individuals on one side
and developers and standards working groups on the other.
It seems perfectly possible to define the vocabulary for describing
accessible content using a combined approach, in which a controlled
vocabulary such as Schema.org's accessibility metadata serves as the
seed for the vocabulary, which can be supplemented by terms submitted by
individuals. Using this approach, the ISO 24751 vocabulary would grow
into a superset of the "starter set" provided by a controlled vocabulary.

> 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. 
Is there an implicit contention that Schema.org's accessibility metadata
should be rejected because they were not created through a process
driven by individuals who experience barriers?

Best regards,

Christophe Strobbe

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


-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

“It is possible to make a living making free software for freedom 
instead of closed-source proprietary malware for cops.” 
Jacob Appelbaum, 
<http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/>
Received on Thursday, 18 June 2015 18:20:12 UTC

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