Re: Adopting the media accessibility requirements

On Thu, Oct 28, 2010 at 7:38 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
> Maciej Stachowiak wrote:
>> Some weeks ago, the HTML Accessibility Task Force presented a
>> requirements document for media accessibility:
>>
>> http://lists.w3.org/Archives/Public/public-html/2010Aug/0327.html
>>
>> Since then, there has been some discussion and revisions in the Task
>> Force, and not much discussion on the full WG list. At this point, if
>> there are no further comments, the Chairs are prepared to call for
>> consensus on this document and adopt it as the requirements document
>> for media accessibility.
>
> I think it could be useful to check how well proposed solutions address the suggested "requirements", but I object to adopting the requirement list as "the requirements document" that, presumably, media accessibility solutions would have to satisfy. The reasons for my objection are:
>
>  1) Having a list of requirements that has been adopted through an Official Process makes it harder to make reasonable design tradeoffs. When a list of requirement is handed down without enough background data about the rationale of each requirement and the relative importance of the requirements, it's easy to arrive at a situation where the requirements become treated as non-negotiable rules that are absolute and axiomatically right instead of something that can be subject to tradeoffs. The lack of specific rationale is particularly troubling when the requirements are very specific in a way where it's hard to guess why the requirement says exactly what it say. For example, where does 1/12 come from in "1/12 of the total screen height"?
>
>  2) The list of requirements has requirements that are obviously bogus in the sense that it's obvious that the requirements aren't technically necessary to achieve accessibility. I think it's not credible to suggest that metadata for copyright information or usage rights is a "must" level technical requirement for *accessibility*. I think it's also not credible to require voice-optimized codec availability on the 'must' level, since it should be blatantly obvious that accessibility would be achievable using a general-purpose audio codec. Likewise, the accessibility would obviously be achievable by supporting at least one character encoding that can represent all of Unicode (e.g. UTF-8), so support for arbitrary character encodings can't be a hard *accessibility* requirement.
>
>  3) The requirements look like they have been copied and pasted from somewhere else without proper review. For example, the requirement to support languages representable by Unicode 3.2 looks like a requirement copied and pasted from a legacy source. Why 3.2? Why not a newer version? Or an older version if the intent is to avoid requiring recent additions to Unicode? The requirements talk a lot about "screen" instead of the CSS box for the <video> element. It's unclear if the requirements really mean to require things relative to the *screen* (which would be rather radical given that often even the browser *view port* doesn't cover the entire screen) or whether the requirements have just been copied and pasted from a list of requirements originally written for a system where a video is by default rendered full-screen (e.g. TV).
>
>  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.

Cheers,
Silvia.

Received on Thursday, 28 October 2010 10:41:33 UTC