Re: Setting up a conference call on accessibility metadata, especially accessMode/mediaFeature for Thursday, 9/26

On Wed, 25 Sep 2013 18:52:44 +0200, Charles Myers <charlesm@benetech.org>  
wrote:

> I've made enough progress and heard back from enough people that I'd  
> like to propose a call and agenda for tomorrow, Thursday, September 26  
> at 8:00 AM PDT.

Regrets. This time conflicts with the W3C HTML Accessibility group weekly  
teleconference, and as it happens this week with a one-off specific event  
I am committed to at the same time.

> If we need to, I'd like to also set a call for Monday at that same time.

I likewise have a clashing call at that time on Mondays.

> The goal of the call will be a review of the open issues on the w3c wiki  
> and get to closure on these issues.  See  
> issues<http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker>  
> and accessMode/mediaFeature  
> matrix<http://www.w3.org/wiki/WebSchemas/Accessibility#Access_Modes_Media_Features_Framework:_a_tabular_view>.  
> There will also be a discussion of the use of these attributes for  
> search, as shown in the blog article.

I will aim to reply on the wiki, but some notes below.

> I've not accomplished all that I wanted to at this point, but I have  
> enough to have a discussion.
>> From the last email, here's the list and the progress
>
>   *   a recording of the demonstration that Madeleine did on the second  
> day of Moscow, showing accessMode and mediaFeature in action

To be fair, what Madeleine showed was that accessMode isn't really helpful  
as designed, and she instead proposes a new semantic which effectively  
corresponds to the "negative" semantic that I had asssumed it had.


> On 9/16/2013 9:10 PM, Gerardo Capiel wrote:
> 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.

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.

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

How do we describe a narrated animated educational video, where the text  
of the audio is also rendered?

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

In any event, I have proposed a handful of use cases too. Are they  
invalid? If not, I don't see how to meet them, and it is not clear that  
they are in fact met.

> and also relied on significant prior work.

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

cheers

Chaals

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

Received on Wednesday, 25 September 2013 18:32:12 UTC