Charles,
Chuck is following up directly with you requesting times that you can join a call, since you are key to this effort being adopted by Schema.org<http://Schema.org>. Comments below to your comments :-)
Chaals,
I agree that mediaFeature is the most important property here and I think you're right that we need to be thinking about how we can make implementation easy for developers of search software. Your point on accessMode is also particularly strong when we consider that many times users have already filtered out a lot of content by the type of resource they have chosen to search for. For example, if a user is doing a video search on Google on Yandex, they have already narrowed the accessMode possibilities to visual and auditory combined. If they are deaf, they are most likely only looking to filter their video search by mediaFeature equal to captions or transcript.
Or silent movies, or movies where the audio isn't actually important to them.
A teacher looking for silent movies or captioned movies is a case where they would combine mediaFeature contains captions and accessMode does not contain auditory (-videoobject-accessMode:auditory in Google CSE syntax). I'm curious what properties you would propose to address this use case.
And if they are a teacher looking for a resource for the class that includes one blind and one deaf student, then we haven't done anything useful.
Then they would looking for mediaFeature=captions and mediaFeature=audioDescription.
And if they are blind, they are most likely only looking to filter on mediaFeature equal to audioDescription or transcript. The transcript choice is a fallback choice for both cases.
If they are instead looking for resources on a *topic*, they haven't done any qualification. It may be that they prefer to see what is available, instead of assuming that a specific set of adaptations they happen to know of is the only way to specify things that work for them.
I agree and they can choose to not filter by any accessibility properties, but see what features have been included in the search results, similar to the demo that Madeleine did.
How do we describe a narrated animated educational video, where the text of the audio is also rendered?
Isn't that just mediaFeature=captions? Are you talking about closed versus open captions?
During the development of the proposal we did a lot of work on use cases
The use cases are really important. But I have missed the reference to them.
Chuck is following up on this. We did have some documentation at https://wiki.benetech.org/display/a11ymetadata/User+Stories
Yes. One of the things I have consistently heard from the people who *did* the prior work is that only some parts of it are useful in practice. I also have some concerns about whether the assumptions underlying the work included dealing with large open-ended data sets - which is a basic requirement for search engines (the primary schema.org<http://schema.org> use case).
For example, marking resources that have an accessHazard is sensible. But it seems likely that most resources won't be marked up - schema.org<http://schema.org> may reach something on the order of 10% of websites. Assuming that increases, and 20% of websites are marked up completely, and that X% have an accessHazard, that suggests that choosing a website that is not marked as having an accessHazard gives you a 20% chance of avoiding the problem, unless you restrict your search to sites known to have been marked up *accurately* (i.e. the fact that there is some accessibility metadata doesn't tell us anything about whether the person who created the metadata even checked for accessHazard).
So while I unequivocally support adding accessHazard as soon as possible to schema.org<http://schema.org>, I also believe that it would be far more useful to consider a "doesNotContainProblem" property. I am sure that there would be a certain amount of inaccuracy in such claims, but I would be surprised if the proportion of explicitly made incorrect statements would approach the 80% that I explained above as an optimistic minimum risk level.
I think this is very good feedback and agree that this accessHazard property should use negative values.
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru<mailto:chaals@yandex-team.ru> Find more at http://yandex.com