Re: Adopting the media accessibility requirements

On Sat, Oct 30, 2010 at 10:07 AM, John Foliot <jfoliot@stanford.edu> wrote:
> 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


Just to reconfirm: these are USER requirements.

Henri: if somebody told you they need a table element and they need to
be able to have a header text that flies in from the left, makes some
circles while turning the text orientation 360 degrees and is placed
into its spot after that, continuing to blink, would you also tell
them that that cannot be a "must" requirement? You would accept that
that's their requirement, but tell them the limit of what is doable -
then discussing what about this requirement would be the most
important functionality to get right and work on that fist. E.g. agree
that in HTML4/CSS2 that would be the table header functionality and
blinking text as "must" and the other features are a "may". So, that
give you a means to address the overall challenge more easily and you
go off and make sure that this base functionality is technically
available first. And later - now with HTML5/CSS3 - you continue to
develop the other features - animated text - and make your user
increasingly more happy that his original "must" requirement can now
finally be fully satisfied.

The prioritisation is what the a11y group is offering with the
checklist: a priority list for what features of a basically required
functionality are less or more important to get right straight off the
bat. And it's then open for discussion to see what can technically be
achieved.

To be sure (and this is not targeted at anyone in particular) I can
see how the list may be perceived as long and overwhelming, in
particular considering that we want to get HTML5 to last call asap.
But we won't make progress by arguing about the usefulness of a list
of requirements that a set of users have put together. We can improve
the list and possibly add more requirements ;-) (e.g. by looking at
the requirements that have been published as legal requirements for
DTV in CEA-708), but I'd much rather people digest the existing list
and we move on to the next step, namely defining means for providing
solutions to the broad areas that are being required.

We have already made huge progress for captions/subtitles/text
descriptions/chapters with the <track> element and the TimedTrack API.
A discussion of a baseline format for time-synchronized text is
required next, e.g. a discussion about WebSRT.

The next step after that is getting the spec for audio descriptions
and sign language video right - this is about multitrack audio-visual
resources and also about time-aligning external audio and video
resources. We currently have an active discussion thread on the media
a11y mailing list about that.

There is plenty of work still left after that, but the a11y TF is
taking one step at a time to now move from the user requirements list
towards proposing initial drafts of technical solutions for the
different required aspects that can help this group to move towards
satisfying the requirements listed in the user requirements list. It
would be constructive if this group regarded the work of the media
subgroup of the accessibility TF as constructive and contributing
towards moving forward towards getting technical solutions and
collaborated towards that goal.

Regards,
Silvia.


[1] http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist
[2] http://www.w3.org/WAI/PF/HTML/wiki/TTML_Mapping_to_Requirments

Received on Saturday, 30 October 2010 05:22:06 UTC