Re: Schema.org - identifying accessible documents

> On Jun 18, 2015, at 8:02 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> Any universal settings will also need to take into account that a user may need one adaption in one environment but another or none in another environment.  For example, with a certain low resolution setup I want the standard font size in Outlook but in another environment on a high resolution machine I want a little larger fonts in my inbox.  In my example, Outlook seems apply the same setting across environments via Office 365.  

Exactly, this is what I meant by context. It could mean things like “later in the day when I’m tired”, “when my assistant is not with me”, “when I’m in a parent role”, “when I’m in a noisy environment”, “ when I’m studying math not english”, etc.. Each preference can also be session specific and/or globally applicable. 

Jutta

> 
> Jonathan
> 
> -- 
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com
> 
> 703-637-8957 (o) 
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> 
> 
> -----Original Message-----
> From: Jim Tobias [mailto:tobias@inclusive.com] 
> Sent: Thursday, June 18, 2015 11:09 AM
> To: Jutta Treviranus; chaals@yandex-team.ru; WAI Interest Group
> Subject: 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 Friday, 19 June 2015 11:05:56 UTC