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

Re: Schema.org - identifying accessible documents

From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
Date: Thu, 18 Jun 2015 09:55:07 -0400
Cc: chaals@yandex-team.ru
Message-Id: <FADE83F8-7942-406B-8B82-97A73CB1428D@utoronto.ca>
To: lwatson@paciellogroup.com, WAI Interest Group <w3c-wai-ig@w3.org>
Hi Léonie and Charles,

On a practical level, we should also consider the real world scenarios in which this markup will be used. If I happen to be an author who has created content that is inaccessible to certain groups, what is the likelihood that I will take the time to label my resource as requiring a specific skill? More importantly, if I do label the resource as requiring a capability, will I consider this as sufficient to warn off anyone without sight so I do not need to make further efforts to make it accessible?

Jutta

> On Jun 18, 2015, at 9:00 AM, Léonie Watson <lwatson@paciellogroup.com> wrote:
> 
>> From: chaals@yandex-team.ru [mailto:chaals@yandex-team.ru]
>> Sent: 17 June 2015 22:54
>> 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.
> 
> [...]
> 
>> 
>> 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).
> 
> [...]
> 
>> 
>> 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.
> 
> At the risk of re-opening an old debate, I don't think the disability model is relevant in this context. Whether disability is regarded as a medical problem to solve, or a social attitude that needs to change, it doesn't alter the fact that I can't see.
> 
> If anything, this proposal feels like a pragmatic model of disability. The ability to indicate the things I can (or perhaps can't) do, in order to find content that I can use successfully, is about getting on with life in a practical way.
> 
> I waste a horrendous amount of time trying to find content I can use. I'll usually be able to find umpteen sources of the information I'm looking for, but only the 10th will be in a format I can make use of. If we can find a way to match someone's requirements with the accessibility characteristics of a resource, I think it will make life a lot easier for a great many people.
> 
> Returning to the idea itself, I imagine it would be necessary to come up with a common vocabulary of access modes. An immediate thought is that a flat vocabulary wouldn't work - on the basis that disability isn't a binary state. Is a hierarchical taxonomy possible within Schema?
> 
> 
> Léonie.
> 
> -- 
> Léonie Watson - Senior accessibility engineer
> @LeonieWatson @PacielloGroup PacielloGroup.com
> 
> 
> 
> 
Received on Thursday, 18 June 2015 13:55:36 UTC

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