Re: Adopting the media accessibility requirements

Silvia Pfeiffer:
> >  4) The requirements are presented as equally important when it's
> >  clear that there are at least three categories of requirements: 1)
> >  requirements for achieving feature parity with systems already
> >  deployed and in wide use (e.g. broadcast TV or DVDs), 2)
> >  requirements that try use HTML5 as an opportunity to elevate the
> >  state of the art above and beyond what deployed systems provide and
> >  3) blatantly unproven and of questionable UI feasibility (such as
> >  the requirement to allow captions or subtitles to be marked up
> >  using RDFa or Microdata in order to improve jargon
> >  comprehensibility). What may not be clear to all readers is which
> >  requirements belong in which category. I think requirements for
> >  achieving feature parity with *successful* (as in *actually
> >  routinely used* by authors and users) features of existing systems
> >  should have top priority. Requirements about Semantic Webby
> >  features should have the bottom priority--likely to the point of
> >  not even being "accessibility" requirement
> >  s.
> 
> 
> BTW it may not be known, but there is actually a separate document
> that is providing the prioritization that you mention is necessary,
> see http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist .
> There it is stated which requirements are more important to achieve
> than others with must/should/may statements. Feedback on the ranking
> is encouraged.

It seems that John Foliot disagrees with you on what the ranking means:
> It is important to underscore here that requirements currently noted
> as
> 'shoulds' and 'mays' are so noted as it is understood that certain
> configurations of hardware/software may result in the inability to
> support
> a specific feature (for example, we've oft pointed to low-end mobile
> devices that will likely not support multiple concurrent audio
> streams).
> These 'shoulds' and 'mays' however should not be considered any less
> important in serving accessibility needs and requirements.

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

Consider what would have happened if John hadn't spoken up at this point: People might have thought that they are strictly agreeing to making the spec satisfy the MUST requirements from the checklist doc, but they'd have accidentally agreed to making the spec satisfy the SHOULDs and MAYs, too.

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

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". If the CfC passed, the record would show the WG consensus was on the "must" even if participants had persuaded to accepting it by showing them the "may".

So how to fix?

First, if it seem that the document subject to a CfC needs some additional exegesis to get wider WG buy-in, that additional information should become part of the document subject to the CfC. That is, either the "checklist" document should become the document subject to CfC or the content of the Checklist document should replace the requirement points in the Requirements 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:

 * "Requirements for achieving accessibility parity with successfully deployed features of other systems": This list would only contain the requirements that describe functionality that is already deployed and in wide use in existing widely-used systems, such as broadcast TV and DVDs. Ideally, each requirement would come with note saying which existing system(s) already satisfy the requirement (e.g. "DVD" or "North American broadcast TV"). For example, the requirement "(CC-2) Allow the author to specify erasures, i.e., times when no text is displayed on the screen (no text cues are active)." would belong on this list. Note that unsuccessful features of successful systems don't belong on this list. For example if DVDs supported a captioning subfeature that was virtually never used in DVD captions, that feature wouldn't belong on this list.

 * "Accessibility wishlist": This list would contain features that are strictly about accessibility but that aren't already commonly deployed and in wide use in other systems. Ideally, each feature would come with a note pointing to information about experimental implementations. I'm not quite sure what would be a good example of a feature belonging on this list (That's part of the problem I have with the requirement list!), but I *think* this might qualify, since I *think* at least European broadcast TV doesn't support this: "(DV-6) Allow the user to independently adjust the volumes of the audio description and original soundtracks, with the user's settings overriding the author's."

 * "Other stuff we thought about": This list would contain features that aren't strictly about accessibility but that came up in the drafting of the document. An example of a feature belonging on this list would be: "(DV-9) Allow the author to use a codec which is optimised for voice only, rather than requiring the same codec as the original soundtrack."

It would be even better if those three lists were sorted by importance where "importance" is defined thus: "If one person were implementing these features over time, what order would you like the person to implement them if you didn't know when the person is going to stop?"

Furthermore, the document should explicitly say that features on the second and third list may be left out as tradeoffs in the design process.

Karl Dubost wrote:
> The word requirements might lead to misunderstanding as we have
> already seen in [Henri's email][2] (Henry is making good points). It
> has to be clear that
> 
> "user requirements" differs from "implementation requirements"

The introductory email isn't subject to the CfC. I think my reading comprehension skills aren't at fault when I read these as pretty specific implementation/spec requirements and not as user stories:
"Systems supporting described video that are not open descriptions must: -- --
    (DV-8) Allow the author to provide fade and pan controls to be accurately synchronised with the original soundtrack.
-- --
    (DV-9) Allow the author to use a codec which is optimised for voice only, rather than requiring the same codec as the original soundtrack."

I encourage people responding to the CfC to actually read the document subject to the CfC without getting distracted by how it is introduced. That is, I suggest paying attention to the parts introduced by "Systems supporting foo *must*" (emphasis mine). If the CfC passes, six months from now, the record that people will appeal to will show what the doc subject to the CfC *says*--not what it's claimed to *mean*.

- -

A couple of additional observations:

It's hard to tell what exactly this requires: "(CN-3) Support both global navigation by the larger structural elements of a media work, and also the most localized atomic structures of that work, even though authors may not have marked-up all levels of navigational granularity."

Also, this requirement "(MD-4) If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (UAAG 2.0 2.1.4) This assumes the video element will write to the DOM." may be interpreted to require browsers to expose the DOM interfaces to AT. If, it's overly specific. As I understand the situation with Gecko, it preferable to talk to ATs via accessibility APIs these days instead of having AT come in to poke the DOM.

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

Received on Friday, 29 October 2010 08:21:12 UTC