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

> 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<>  
> and accessMode/mediaFeature  
> matrix<>.  
> 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  

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  

>  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  

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 use case).

For example, marking resources that have an accessHazard is sensible. But  
it seems likely that most resources won't be marked up - 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, 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.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex         Find more at

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