RE: Adopting the media accessibility requirements

Henri Sivonen wrote:
<edit>
> Furthermore, the document should explicitly say that features on the
> second and third list may be left out as tradeoffs in the design
> process.
</edit>

Henri,

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

The User Requirements document is a collection of just that: user 
requirements. We cannot then proceed to say that the needs of deaf users is 
more important than those of mobility impaired users, or that addressing the 
needs of the deaf/blind is "too complicated" and so let's defer it to the 
next round.

If a browser implementer wants to make those decisions, then that is a 
business and risk-management decision which they should make in consultation 
with their legal counsel. But do not expect the W3C to start suggesting that 
certain users with specific disabilities are "more important" than others, 
or that we can tradeoff the needs of one user group to benefit either the 
implementers schedules or because the work-effort required is complex. It 
doesn't work that way, and until you and others can wrap your heads around 
this important concept, you are chasing after the wrong problems.



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

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";  however in an attempt to be 
practical and pragmatic some guidance for implementation is also being 
suggested. Assuming that a 'should' or a 'may' is akin to 'not needed' 
however is a leap of judgment that you need to be very careful in making, 
and to be crystal clear, the media sub-team is not making that assumption of 
judgment. If this confusion continues to persist, we can happily remove that 
column from the checklist.



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

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. The document (and its companion checklist) are 
specifically technology neutral and are actually pretty devoid of specific 
solutions at this time: at best it points to prior examples of the type of 
functionalities required, but specifically and implicitly leaves the door 
open for discussion moving forward. If that is unclear, or if some of the 
language needs to be massaged to better convey this then please offer 
suggested replacement text or point to the areas which require 
clarification.



> 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. 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? Wow... just, Wow.


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

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

Have we missed any?
Are there any questions or other feedback on this list (that we have 
identified) of Users impacted by this topic?
Is there any disagreement in the associated prose that further defines these 
different user groups and the challenges they face?
Is there dispute of the challenges these users face?
Is there a need for clarification of that prose?
Are there any unanswered questions?



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?
Have we missed something?
Is there something here that is unclear, vague or ambiguous?


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?
Do any of these require further explanation or examples to clarify the needs 
and how they meet such needs?
Have we adequately explained how any one of these content types or 
technologies solves the needs of any of the various user-groups previously 
identified?


System Requirements:

We have identified a number of requirements that are System level 
requirements (where 'system' is the entire eco-structure of OS/hardware + 
browsers + adaptive technology) used to accommodate users with a variety of 
impairments. They include:

  * Access to interactive controls / menus
  * Granularity level control for structural navigation
  * Time-scale modification
  * Production practice and resulting requirements
  * Discovery and activation/deactivation of available alternative content 
by the user
  * Requirements on making properties available to the accessibility 
interface
  * Requirements on the use of the viewport
  * Requirements on the parallel use of alternate content on potentially 
multiple devices in parallel

Do you disagree with any of these system requirements?
If so, which and why?
Do any of these require further explanation or examples to clarify the 
needs?
Have we adequately explained how any one of these system requirements solves 
the needs of any of the various user-groups previously identified?



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

Again, here, your understanding and comprehension of what we are discussing 
is seemingly flawed.

The list is *the list*, it's not a collection of lists; it is one, 
(hopefully) complete collection of all user requirements that need to be met 
to ensure Universal Access. We are asking whether people agree that the list 
is complete, accurate and reflective of all needs. We are also asking if it 
has been clearly defined, explained and reviewed, because frankly it will 
then become the bench mark for assessing all other solutions, potential 
solutions and technology strategies for accessible media moving forward. It 
is (will be) the baseline upon which all other decisions will hopefully 
trace from, including the complex and difficult decisions implementers will 
face of which piece of the elephant they eat first (if it were up to me, I 
would assign multiple engineers working as a team on various aspects of the 
whole, but it's not up to me is it?)



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

Henri, if you want to build a browser that ignores all of this, please feel 
free to do so - live long and prosper.

However if you choose to ignore the needs of people with disabilities you do 
so at your own peril. This is not about 'enforcing' anything (we can leave 
that to regional governments around the world), this is about ensuring that 
we have an interoperable technology strategy that can address all of the 
needs we have identified, so that browsers can enact/react to those needs 
and provide solutions in a standardized, interoperable way. In terms of 
business process, the browsers will meet none, some or all of these 
strategies/solutions as they choose, and the W3C can do very little about 
that fact. This does not remove the need however for us to at least 
prescribe the best methodology and technologies should a browser implementer 
choose to support all - *THAT* is our responsibility.

Then of course there are the content creators: they need a clear, 
interoperable means of ensuring that they can make their content accessible 
to their user-base for a multitude of reasons: social, economic, political 
or other. HTML5 is not just about browser implementers, it's about content 
creators as well - even more so. So when content creators are mandated or 
simply desire to meet the needs of people with disabilities, we owe it to 
them to have an appropriate answer: we can't respond "Oh that? We traded 
that off because we couldn’t figure it out in time..."


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

(Note as well that the Web Content Accessibility Guidelines (WCAG) 2.0 is in 
fact a W3C Recommendation, which equates to a Standard in the world of the 
W3C, but that being a non-governmental organization, it's Standards are 
non-binding on any one entity or collection of people.)

What National and Regional governments do with W3C recommendations however 
is beyond the reach of the W3C - although clearly they are looking to us (as 
the appointed Standards organization) to give them the best data and 
recommendations we can. It should be a clear clue to the engineers however 
that what we keep trying to explain to you *is* complex, political and 
covers more than just 1's and zero's.  Welcome to the real world, in all of 
its complexities.



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

Would it make it more palpable to you if instead of saying:
 "Systems supporting described video that are not open descriptions must:"

...it said:
 "Systems supporting described video that are not open descriptions require 
the ability to:"

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

Note as well that those sentences both have an implied IF proposition in 
them: "Systems supporting..." - systems that do not support skip right past 
this section; again this is not an avocation that systems not do so, in fact 
they *should* support Described video, but it also acknowledges that not all 
systems may be able to meet this requirement for a variety of reasons, and 
so we have also taken pains to ensure that we do not insist that "pigs can 
fly".



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

NINE WEEKS AGO, when the User Requirements document was released to the HTML 
WG, we heard not 1 single comment, not one! At that time, the checklist had 
not even been begun; I started that work in September as the sub-team 
continues to try and solve these complex problems. If the collective desire 
of the Working Group is to merge the two documents into one, I personally[*] 
do not have any problem with that, as the checklist derived directly from 
the User Requirements. Perhaps the Chairs want to pose that question to the 
Working Group?
[* I do not speak here on behalf of my team members]

>
> 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* - these are the requirements we have 
determined to ensure Universal Access. These are real people we are talking 
about, not some bits of software features that can be deferred to the next 
release.

The Must/Should/May classifications were added to help assist in 
strategizing work-flow, and not to diminish in any way the need of the 
requirements to be met. Once again, if the confusion continues to exist, I 
will poll the sub-team and we can remove that confusion completely so that 
it is clear: These are the User Requirements.

JF

Received on Friday, 29 October 2010 23:08:25 UTC