Re: Schema.org accessibility proposal Review...

On Thu, 05 Sep 2013 17:52:21 -0000, Gerardo Capiel <gerardoc@benetech.org>  
wrote:

> Responses below:

And mine. I have snipped stuff, and there are some things I think are less  
urgent than others ...

>> chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>

>> I'd like to discuss this on a publicly archived email list. I'm not  
>> sure if ti should be public-vocabs, or an accessibility-oriented one,  
>> or what.
>
> I've added the public accessibility metadata project email list and  
> public-vocabs list to this thread.

OK, thanks...

>> = accessMode =
>
>> It should be possible for a "single resource" to be available with more  
>> than one *set* of accessModes.
>
> I agree and this is the design.  A single resource can require one or  
> more accessMode(s).

Yes, but...

> … the accessMode property describes "Human sensory perceptual system
> or cognitive faculty through which a person may process or perceive
> information." […]
> We have also published a best practices and an implementation guide on  
> the use of accessMode at:
> <http://www.a11ymetadata.org/wp-content/uploads/2013/04/A11yMetadataProjectBestPracticesGuide_V.6.pdf>
> <https://wiki.benetech.org/display/a11ymetadata/Practical+Properties+Guide>

Yep. But that has an example which I'll use:

A movie with captions and extended audio description would be encoded as  
follows
<div itemscope=”” itemtype=”http://schema.org/Movie”>
<meta itemprop=”accessMode” content=”visual”/>
<meta itemprop=”accessMode” content=”auditory”/>
<meta itemprop=”mediaFeature” content=”audioDescription”/>
<meta itemprop=”mediaFeature” content=”captions”/>
</div>

My first impression is that if the video has good audio description, then  
claiming it has accessMode "visual" seems wrong, since you don't need to  
see it. Likewise, since it is captioned, it seems you don't need to hear  
it.

So it doesn't have a single *required* accessMode. On the other hand, you  
need to *either* see (clearly enough) or hear, in order to get the content.

> accessMode is derived from the Access For All (AfA) specification...

> We chose to leverage this prior work because  
> Schema.org<http://Schema.org> is meant to address search use cases,

Yes, and I think that was the right choice. (Right now I am in an ISO  
meeting on this very topic).

>> Essentially, it is unclear what accessMode really means. At least for  
>> the search use case where a user needs to find a suitable resource, I  
>> think the only way this can really work is if an accessMode is a set of  
>> one or more *required user capabilities*.
>
> Yes, I think that is what we are saying too.  In fact, it seems like  
> what others have understood on the public vocabs list as evidenced by:
> http://lists.w3.org/Archives/Public/public-vocabs/2013May/0092.html

Not quite. The example there suggests (based on the documentation of what  
accessMode means) that you need both visual and tactile interactivity to  
work with the resource.

But I agree that what people understand in the examples quoted is that  
there are multiple ways to access some things.

> http://lists.w3.org/Archives/Public/public-schemabibex/2013Aug/0049.html

I'll leave Karen to answer on that one…

>> To pick some examples:
>
>> Alice In Wonderland is available as a resource which only *requires*  
>> the ability to read text.
>
> We happen to have a few versions of Alice in Wonderland in Bookshare

Yep.

> If you inspect one of those titles using Yandex's webmaster tools or  
> Google's rich snippets tool that lets me just plug in a URL parameter,  
> we can see the accessibility microdata on that page:
> http://www.google.com/webmasters/tools/richsnippets?q=https%3A%2F%2Fwww.bookshare.org%2Fbrowse%2Fbook%2F18041<http://www.google.com/webmasters/tools/richsnippets?q=https://www.bookshare.org/browse/book/18041>

I looked at https://www.bookshare.org/browse/book/268061 with  
http://webmaster.yandex.ru/microtest.xml

> As you can see we offer 4 different adaptations of that title, which we  
> originally adapted from a physical book that we scanned.  For each  
> adaptation we describe the accessModes that are used.

Yes. But  
<https://www.bookshare.org/download/book?titleInstanceId=268061&downloadFormat=DAISY_WITH_IMAGES>  
doesn't actually *require* visual capability, does it?

[...]
>> If there is a movie of Alice In Wonderland available with captions,
>> then there are two sets of requirements. One is to be able to watch a
>> movie and listen to the audio, and the second set is to be able to
>> watch a movie and read the captions. (If it had descriptive audio, a
>> third would be being able to hear the descriptive audio and the main
>> audio…)

(See also the movie example mentioned earlier)

> That is the purpose of mediaFeature.  A movie typically has accessModes  
> of visual and auditory.  If it has captions, we simply add a  
> mediaFeature of captions and/or a mediaFeature of audioDescription.  You  
> can find an example in our Practical Properties Guide:
>
> https://wiki.benetech.org/display/a11ymetadata/Practical+Properties+Guide#PracticalPropertiesGuide-Video

Yes, but I don't think that is actually correct. If the movie has  
captions, you *don't* necessarily need auditory capacity anymore. However,  
in order to watch the movie without auditory capability, you may need the  
ability to read images of text (this also depends on the format used for  
captioning...)

>> It might be that this assumption is already made in the proposal,

It certainly seems to be an assumption.

>> but it is not explicit, and the proposal doesn't explain how to deal
>> with a single version that can be used with different sets of
>> capabilities (whereas it includes a way to point to other versions)

> Schema.org<http://Schema.org> allows for multiple values for the same  
> property.  For example, take a look at the example properties for  
> ingredients at the bottom of this page: http://schema.org/Recipe

Sure. But while the data about Alice in Wonderland shows how to include  
multiple alternative books, each with a *set* or properties, I am not sure  
the accessMode definition works for including different combinations that  
are "mutually exclusive".

To continue the captioned, audio described movie example, I think we  
should be saying it has an accessMode which requires the ability to see  
and hear, a different accessMode that requires the ability to hear, and a  
third one that requires the ability to see and to read text on images.

Any *one* of these is sufficient for a user to successfully use the video  
resource, no?

>> == details in accessMode ==
>
>> the top-level accessMode is only useful for "most" cases. Knowing that  
>> I am physically capable of watching and listening to a video is great,  
>> unless it is only available in a format I cannot use such as "flash for  
>> my iPhone 3", "ogg theora/vorbis"….
>
> Schema.org<http://Schema.org> already has a properties for formats  
> (e.g., http://schema.org/encodingFormat ,  
> http://schema.org/BookFormatType )

Yep. So we should be expecting those to be used, right?

>> Similarly if I have more detailed requirements. For example although I  
>> can watch and hear a video tutorial, being red-green colourblind or  
>> requiring very high contrast may mean I can't actually understand it in  
>> practice.
>
> For those use cases, we have accessMode = colorDependent

Yes. But this assumes that users who require white-on-black, users who use  
a common high-contrast mode, and users who are unable to distinguish light  
blue from white have the same requirements.

> and mediaFeature =

Something missing here.

> = accessFeature =

>> Are these just cataloguing information, similar to noting that a  
>> physical book has 5 pages of color photographs, or a guarantee that  
>> e.g. each image has alternative text, or a longer description is  
>> provided as necessary?
>
> We thought that implementing AfA or ISO 24751 verbatim for the purposes  
> of web search and for use by web masters would be too complicated: it  
> needed to be a small set of properties that a user could deal with.

Hmmm. It needs to be as simple as possible - and no simpler...

> We decided to combine various ideas into mediaFeature.

Which I think makes sense.

> mediaFeature simply states that the author/publisher or someone who
> modified that book, tried to take advantage the stated accessibility
> features.

Right.

> For example we make no promise that every image was described
> appropriately,

But is best practice to use mediaFeature: textAlternative when there is at  
least one image with an alternative, or when all the images have one?

(We can't guarantee that everyone does everything perfectly, but it is  
important to explain what we think people should be trying to do as well  
as they can).

>> It isn't clear, for example, how to classify a resource that assumes
>> the ability to touch several points of a screen at once, which is now
>> a common feature on devices but poses an obvious potential problem to
>> some users such as those who don't have very many fingers.
>
> In this use case, the resource that needs to be described is an  
> application, not the content.

Hmm. I don't understand the difference between applications and content. I  
can see there are some things I would call one, and some that I would call  
the other, but resources identified by schema.org seem hard to classify  
into one or the other.

For example, is an interactive map an application or content? What about a  
document that allows structured navigation, a la DAISY?

I don't know of a clear way to determine the difference. But then, I am  
not convinced that we need one.

> If the accessibility API of this application supports multi-touch with
> the user’s AT, then the proposed ATCompatible and accessAPI properties
> should be relevant. Furthermore, we also have a property called
> controlFlexibility, which also should provide information about whether
> the application can be fully controlled either via audio, mouse,
> keyboard, touch or video/gestures.

Yes.

>> = adaptations, other versions, ... =
>>
>> Liddy has pointed out that the concept of "the original" is only  
>> sometimes interesting, and that it isn't an accessibility concept but a  
>> more general one related to creative works.
>
> Actually to a teacher, the “original” is important if they are trying to  
> find a resource for a disabled student that is an adaptation of the  
> “original” resource used by the rest of the students in the classroom  
> who don’t have a disability.

I don't think so, I believe they are happy to know that two things are  
versions of each other without caring which was the original.

> Similarly a publisher or book seller wants to make it easy for consumers
> with specialized needs to find resources that have been adapted or “made
> accessible.”

But again, the publisher doesn't really care which is the "original" - and  
in the case of modern electronic works, the concept may not have a real  
meaning.

> These adaptations properties are also derived from AfA and
> ISO 24751 and I think it’s worthwhile reading their specifications to
> understand their reasoning. We did simplify the terms (removing partial
> adaptation and the like) to simplify this for search purposes.

There is a lot of literature, and there are a number of standards,  
describing how instances of a CreativeWork relate to each other. I don't  
think we *need*, for accessibility, anything more than the super-simple  
"this is a version of that". If people need to describe the relationship  
for other reasons, they should use something that can support the things  
they may need - i.e. the stuff that got removed (and probably stuff that  
was never in AfA but is in Bibex, or FRBR…)

>> This isn't high priority, except that I think we should quickly decide  
>> we want to avoid dealing with defining stuff that others have spent  
>> decades on, and instead try to use their work...

This isn't high priority, except that I think we should quickly decide we  
want to avoid dealing with defining stuff that others have spent decades  
on, and instead try to use their work...

>> = ATCompatible =
>
>> being a boolean seems a bit naive. I can think of lots of resources  
>> that work with specific assistive technologies, but fail with others  
>> (my instant example is http://cookiecrook.com/longdesc/iframe/ which  
>> works great on VoiceOver but as far as I can tell does nothing to work  
>> effectively with the built-in MacOS magnifier - two assistive  
>> technologies I have readily available…).
>
> In the case of content, we once again, we tried to simplify the work for  
> web masters and searchers. Since we can always expand the vocabulary,

This is why I think fixing this bit is not the first priority.

> we decided to err on simplicity, and to just have the focus on whether  
> accessible technology was considered;

Yes, but

> enumerating WCAG sections would be overly daunting in a search.

Well, it would be a fairly unfriendly way to define things.

> In the case of applications, we did provide greater granularity with the
> accessAPI property, which would differentiate what accessibility API,
> such as VoiceOver, the application is compatible with.

Yes. Because for an actual user, it doesn't matter that the developer  
considered assistive technology in general, only whether they can use a  
resource with their particular setup. This is analagous to the reason why  
knowing the format of a resource is important.

> I don't think ATCompatible is the first priority for fixing. But I do  
> think it should be replaced with something because I don't think it is  
> very useful.
>
>> = Evolution =
>
>> Who looks after the terms, and how do they get extended?
>
> This is probably the problem with any Schema.org<http://Schema.org>  
> proposal.

Sure. Which is why I ask the question in this particular case :)

>  By basing this proposal on existing standards, such as AfA and ISO  
> 24751, it will be easier to evolve these terms as more people and  
> organizations (e.g., IMS, GPII, IDPF) will be invested in keeping these  
> terms synchronized with other standards and technologies.

My experience suggests that this will actually make it harderif the  
different standards aren't already evolving in lock-step, unless we have a  
clear story for what triggers changes in the schema.org version.

> We believe that there are some efforts with 24751 to have a registry
> to assist in this process.

There are efforts in 24751 to have a registry, but I am not sure that its  
purpose is to facilitate keeping schema.org as useful as possible in the  
face of the evolving world.

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Saturday, 7 September 2013 12:32:21 UTC