- From: John Foliot <jfoliot@stanford.edu>
- Date: Fri, 29 Oct 2010 16:07:47 -0700 (PDT)
- To: "'Henri Sivonen'" <hsivonen@iki.fi>, "'HTML WG'" <public-html@w3.org>
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