Re: Adopting the media accessibility requirements

John Foliot wrote:
> Let me be as explicit and blunt as I can be: There are no 'Tradeoffs'
> being discussed here. Period.

I think your response shows that my concern is valid.

> The User Requirements document is a collection of just that: user
> requirements.

Who is a "user"? Are you using the word "user" more broadly than is customary in this WG? That is, does "user" here mean people with disabilities or are you using it more broadly?

I have an *extremely* hard time believing that e.g. copyright metadata is a *user* *accessibility* requirement if "user" means a person with a disability accessing an HTML5 site/app.

> But do not expect the W3C to start
> suggesting that
> certain users with specific disabilities are "more important" than
> others,

Fair enough, but surely you could sort requirements that pertain to a given disability by importance.

> Henri, there is no dichotomy between a list that has all the
> requirements
> and a list that helps prioritize those requirements in terms of
> implementation urgency and work-flow strategies. But make no mistake,
> all of
> the user requirements listed are "needed";

It's extremely hard to believe that all the requirements listed are absolutely needed for accessibility. The easiest proof is that the list contains requirements that clearly aren't accessibility requirements (e.g. copyright metadata, text encoding and codec optimization).

> > As for feedback on the ranking:
> >
> > I think putting the ranking or rationale in a separate document
> > that's
> > not part of the CfC is a bad thing.
> 
> First, go back and verify if this, in fact, a CfC. It isn't. Maciej
> and the
> chairs are asking whether there is consensus around our identification
> of
> user needs.

My mistake. Asking whether there is consensus and issuing a Call for Consensus are indeed distinct things from the Process perspective.

> This is a User Requirements document, and the media sub-team wants to
> be
> sure that everyone understands and agrees that we have captured all of
> the
> requirements that users with various disabilities might have - that we
> have
> consensus on this. 

It's very hard to believe that all requirements and, more to the point, *nothing but* serious, carefully considered *accessibility* requirements have been captured, when the document looks like requirements have been copied and pasted from elsewhere without enough attention to detail to bother to make sure the requirements read as up-to-date ("Unicode 3.2") and as Web-relevant ("user switches to a different program or channel").

> > It seems to me that it's a common
> > WAI (anti-)pattern to make a succinct list of requirements (or
> > "Guidelines") and another document that explains the meaning or the
> > importance of the requirements/guidelines. This way can easily lead
> > to
> > a bait-and-switch situation.
> 
> That's mighty antagonistic language there Henri. 

Pot, meet kettle.

> What exactly are you
> suggesting? That WAI and the Accessibility Community are trying to
> *force*
> you into doing something you don't want to do by using subterfuge and
> trickery? 

I'm not suggesting that any intentional bad things.

I am suggesting that the WAI has a history of writing a binding document and another non-binding companion document and titling the binding document in less committal terms than how the document will be used. (E.g. WCAG comes with a separate non-normative "Understanding" doc and is called "Guidelines" instead of e.g "legislation template".)

Thus, when reviewing the Media Accessibility Requirements, participants of the HTML WG would be well advised not to base their review of the would-be binding document on the companion non-binding document or on how things are titled or introduced.

> Wow... just, Wow.

I could go all "Wow... just, Wow." on copyright metadata and RDFa showing up in an accessibility requirement doc.

> > People are asked to agree to make the
> > first document Official because the content of the second document
> > seems easier to agree to. Then later the second document may be
> > forgotten, since the official record would show that the first
> > document
> > was adopted as Official doctrine.
> 
> So let's look at the first document shall we?

I encourage all HTML WG participants to do so.

> Do you agree or disagree that users with the following
> disabilities/impairments require accessible alternatives to media:
> 
> * Users who are Blind
> * Users with Low vision
> * Users with Atypical color perception
> * Users who are Deaf
> * Users who are Hard of hearing
> * Users who are Deaf-blind
> * Users with Dexterity/mobility impairments
> * Users with Cognitive and neurological disabilities

I agree that users who are blind (or have low vision) or deaf (or are hard of hearing) require alternatives to media. It's not obvious to me that the best way to make media accessible to users with atypical color perception or dexterity/mobility impairments is alternatives to media, so tentatively I don't agree but I'm not sure to disagree, either. I'm not competent to comment on cognitive or neurological disabilities.

> Are there any unanswered questions?

For instance, why is "(DV-13) Allow the user to relocate the description track within the audio field, with the user setting overriding the author setting. The setting should be re-adjustable as the media plays." a "must" *requirement* as opposed to being in a "nice to have" category? For whom would media be inaccessible to if this requirement weren't satisfied?

> At the next level, we have determined that accessibility issues can
> fall
> into 2 categories:
> 
> * Alternative Content Technologies,
> * System Requirements (which further relies on OS + hardware
> configurations, User Agents [aka browsers], and Adaptive Technology).
> 
> Do you agree or disagree with that assessment?

The assessment seems plausible on surface, so I tentatively agree.

> Alternative Content Technologies:
> 
> We have identified the following types of Alternative Content (and
> Technologies) used to accommodate users with a variety of impairments:
> 
> * Described video
> * Text video description
> * Extended video descriptions
> * Clear audio
> * Content navigation by content structure
> * Captioning
> * Enhanced captions/subtitles
> * Sign translation
> * Transcripts
> 
> Do you disagree with any of these alternative content types and
> technologies?
> If so, which and why?

I disagree about the essentiality of "extended" and "enhanced". If you believed that those features were absolutely essential for achieving accessibility, you wouldn't call then "enhanced" or "extended".

> > To me, this feels like the contract negotiating anti-pattern of the
> > contract drafter putting something to the effect of "all your base
> > are
> > belong to us" in a contract and then saying in the negotiations that
> > you shouldn't be worried because *of course* that's not going to
> > *enforced* literally.
> 
> Enforced? By whom?

I'll try to explain the analogy once. (If this explanation doesn't open up the analogy enough, let's drop the analogy--I'm not interested in getting entangled into a debate about the analogy.)

Suppose you are applying for a job as a software engineer. The recruiter gives you a contract that says all copyrightable works you make belong to your employer. You protest and say you are developing a program on your own time at home and the program doesn't compete with your would-be employer's products at all, so you should be permitted to develop the program as a hobby and you should own it. The recruiter says that you shouldn't take the contract so literally and they'd never enforce it. It's just a template the lawyers wrote. This is bogus, of course. If the would-be employer doesn't want to enforce the clause, it should be taken out of the contract before signing. OTOH, if you accept the contract, whatever the recruiter told you won't matter of the lawyers treat the contract as fully binding.

Now, in this thread, the HTML WG is like the recruit, the accessibility requirements are like the contract, Karl and Silvia seem to be acting at least a bit like the recruiter explaining that it's not as strict as it looks and you seem to be like a lawyer ready to treat every last bit as binding as possible. 

> > The reason why I'm drawing the contract
> > negotiation analogy is that it seems to me that based on the WAI
> > track
> > record, one should expect everything to become as binding as
> > possible
> > even if it's presented in non-committal terms. For example, the WAI
> > writes "Guidelines" that aren't Jack Sparrow-style flexible
> > guidelines
> > but stuff that gets included in legislation.
> 
> Once again you seem to want to make this some sort of Accessibility
> Community/WAI conspiracy. For Shame!

I'm not suggesting a conspiracy. I'm suggesting that when e.g. Karl says I'm misunderstanding, clearly I'm not misunderstanding given you response. Thus, I think it would be advisable for all WG participants to read the doc with the assumption that if it is "adopted", you will very likely treat every requirement as something that can't be subject to a tradeoff.

As for the "For Shame!", I'd appreciate it if the concerns I raised in my first email to this thread were addressed instead of trying to shame/intimidate me.

> > Here's a concrete bait and switch about to happen with the CfC being
> > discussed: If the WG is asked to refer to
> > http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist ,
> > it
> > looks like DV-9 is a "may". However, the actual CfC is about another
> > document
> > (http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements)
> > that says DV-9 is a "must".
> 
> Inferring nefarious motives to the language we have used is hardly a
> productive response.

I'm not inferring a motive. I'm inferring a probable outcome.

> In other words, do you have a problem with the language, or do you
> disagree
> that we need to support Described video?

I agree that described video needs to be supported. However, e.g. this feature looks like a "nice to have" feature and not like an essential requirement for making content accessible to users with a certain disability: "(DV-13) Allow the user to relocate the description track within the audio field, with the user setting overriding the author setting. The setting should be re-adjustable as the media plays." And the copyright and usage rights part of this "requirement" doesn't look like an accessibility thing at all: "(DV-14) Support metadata, such as copyright information, usage rights, language, etc."

> NINE WEEKS AGO, when the User Requirements document was released to
> the HTML
> WG, we heard not 1 single comment, not one!

Sorry about that. I've been busy implementing HTML5, and from #whatwg IRC, it seemed that is was too early to review to requirement doc.

> > Second, it seems that at least two people who've participated in the
> > drafting of the Requirements don't have the same understanding of
> > what
> > 'should' and 'may' mean. This tells me that MUST/SHOULD/MAY isn't
> > good
> > enough a ranking for coming to *informed* consensus. I suggest
> > splitting the "requirements" into three lists with labels different
> > from MUST/SHOULD/MAY:
> 
> Henri, again, this is *the list*

Thanks for clarifying that.

> These are real people we are
> talking
> about, not some bits of software features that can be deferred to the
> next
> release.

Chances are that some of them will be "deferred to the next release", so it would be nice to have data from the experts to support the prioritization decisions.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Saturday, 30 October 2010 15:21:51 UTC