Re: Working Group Decision on ISSUE-31 / ISSUE-80 requirements survey

Hi Sam,
I strongly disagree with the content of the decision and would
like to raise a Formal Objection.

It is not acceptable that  the HTML5 specification goes to last call
with normative requirements that directly contradict WCAG 2.0

regards
stevef

On 18 April 2011 21:53, Sam Ruby <rubys@intertwingly.net> wrote:
> The decision follows.  The chairs made an effort to explicitly address
> all arguments presented in the Change Proposals on this topic in
> addition to arguments posted as objections in the poll.
>
> *** Question before the Working Group ***
>
> There is a basic disagreement in the group as to where and which
> specification should define requirements on the possible values of text
> alternative examples.  ISSUE-31 and ISSUE-80 both have proposals that
> touch on the various text alternatives examples.  Additionally, we have
> three distinct proposals for this question, and a straw poll for
> objections:
>
> http://www.w3.org/html/wg/tracker/issues/31
> http://www.w3.org/html/wg/tracker/issues/80
> http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209
> http://www.w3.org/html/wg/wiki/ChangeProposals/TextAlternativesIssue122
> http://www.w3.org/2002/09/wbs/40318/issue-31-80-requirements-objection-poll/results
>
> Note: other aspects of these issues included other Change Proposals and
> led to separate polls.
>
> == Uncontested observations:
>
> With three proposals, we don't generally expect much to be uncontested.
> Unsurprisingly the only thing we find of conceded and uncontested is as
> follows:
>
>  Parts of WAI are member only
>
> This observation was not decisive.  There were people who supported
> different proposals even after taking this fact into consideration.
> The fact that this was acknowledged up front was appreciated.
>
> == Objections to letting HTML5 define the requirements
>
> The following objections were expressed in the survey on the proposal
> that lets requirements on the possible values of the text alternatives
> to be defined by the current text in HTML5:
>
>  It is my belief that creating modular components of a larger
>  specification such as HTML5 allows for greater flexibility and
>  responsiveness.
>
> A valid objection, though one considerably weakened by the lack of
> specifics.
>
>  The most current and complete author guidance emerging from the
>  work-effort behind HTML5 is "Techniques for providing useful text
>  alternatives"
>
> Lacking in specifics, this one was not given any weight.
>
>  I object to keeping @alt guidance in the HTML5 spec on the grounds
>  that HTML5 should just have one spec which defines these issues
>
> A valid objection, though one considerably weakened by the lack of
> identifying any operational problems with having multiple specs.
>
>  the HTML5 spec's definitions of @alt hides a lot of complexity
>
> A valid objection, though one considerably weakened by the lack of
> specifics.
>
>  Having W3C WAI specifications and W3C HTML5 specifications that
>  provide conflicting text alternatives examples is bad. It will lead
>  to confused authors.
>
> This objection lists 4 bugs with specifics; bugs which were not raised
> separately as issues, but for which the only remedy advocated is to
> remove large amounts of text from the HTML5 spec and also remove the
> entire "HTML5: Techniques for providing useful text alternatives"
> document.  What is missing is any evidence that these issues couldn't
> be raised, and that they couldn't be resolved per the current Decision
> Process.  Lacking such evidence, this objection was found to be weak.
>
>  The more choices you give people, the harder it is for them to
>  choose, and the more likelihood of them getting things wrong. Too
>  many or conflicting examples adds complexity and leads to confusion.
>  In contrast a narrow, focused set of examples leads to clarity, which
>  leads to more authors getting it right.
>
> This objection simply states that the examples should be in one place,
> and doesn't specify where that place should be.  If there are examples
> that should be removed, we encourage specific bug reports.  Lacking
> evidence of the right place for these examples to go, this objection
> was not found to be relevant to the decision at hand.
>
>  best practices for the provision of text alternatives is a work in
>  progress, and is definitley not represented well by the current HTML5
>  spec text
>
> A valid objection, one with a concrete proposal, though one weakened by
> the lack of substantial rationale or enumeration of specific problems
> with the HTML5 specification.
>
> Next we look to the "split out and modify parts of Section 4.8.2.1 the
> img element" Change Proposal for portions that could be interpreted as
> objections to this Change Proposal.  We start with the rationale:
>
>  As the non machine-checkable text alternative conformance
>  requirements in HTML5 are not tied to any practical measurement or
>  consequence of non-conformance. As the rigidity of the current
>  conformance requirements does not reflect the diversity of real world
>  uses and constraints for the use of the alt attribute for providing
>  text alternatives to those that require them.
>
> A potentially valid argument, but lacking any evidence, was not given
> any weight.
>
> Next we turned to the Positive Effects section of this Change Proposal.
>
> A number of these effects (specifically: cross-referencing WCAG,
> formatting and addition if images, less jargon, integration of ARIA,
> elevation of the profile, and discoverability) simply argue for the
> continued existence of the "HTML5: Techniques for providing useful text
> alternatives", which was not in dispute.  None of these arguments were
> found to further the argument that any information be removed from the
> HTML5 draft.
>
> Next:
>
>  Allow a range of subject matter experts to have more input into the
>  content and style of the recommendations.
>
> It is difficult to interpret this one as an objection.  No one is
> contesting the work on the "HTML5: Techniques for providing useful text
> alternatives".  It is not clear if this is arguing that experts are
> being excluded from providing input to the HTML5 draft.  In fact, the
> exact opposite claim is made in the Change Proposal to "Provide
> detailed instructions and examples for doing so to all readers of the
> HTML specification.".  As neither side provided any evidence of their
> case on this point, this objection (if in fact, it was intended to be
> one) is found to be weak.
>
> And finally:
>
>  Make it easier to publish updated versions of the recommendations as
>  changes to user agent support and new research for methods of
>  providing text alternatives necessitates modification of the
>  specification.
>
> Lacking any evidence of a specific problem, this too was found to be
> weak.
>
> Next we turn to the rationale in the "Remove text alternative examples
> from HTML draft." Change Proposal:
>
>  At times the value for text alternatives is subjective...  If we made
>  a test and asked 10 different accessibility professionals to provide
>  text alternatives, we will likely get 10 different answers.
>
> We are not prepared to make a decision based on what somebody feels is
> "likely".  This objection cited two bugs that were resolved, not by
> removing all examples from the HTML5 draft and the entire
> alt-techniques document, but by the removal of a single example from
> the HTML5 draft.  Should additional specific problems be identified, we
> have no reason to believe that they can be addressed in a similar
> manner.  Lacking evidence of a systematic problem, the case was not
> made that the remainder of the examples should be removed speculatively
> on the basis that they might have problems.
>
>  The best HTML5 can do is to point authors to the W3C's domain that is
>  chartered to deal with these issues.
>
> The "fact" that this was the "best HTML5 can do" was found to be an
> assertion without evidence.  Additionally, there clearly are a number
> of references to WCAG in the "HTML5: Techniques for providing useful
> text alternatives" draft.
>
>  Eliminates repetition and conflicting information within the HTML
>  Working Group.
>
>  Alleviates duplication of effort and double maintenance.
>
>  Eliminates repetition and conflicting information between the HTML WG
>  and WAI Working Groups.
>
> We have a competing assertion that presenting the same information in
> ways that vary the formatting, jargon, etc. is helpful.  Lacking any
> evidence to the contrary, this objection was considered to be weak.  As
> to conflicting information, this was dealt with previously: we
> encourage specific problems to be pursued as separate issues.
>
>  The HTML5 ISSUE-66 decision said that UAAG is the proper place to
>  provide Image Analysis Heuristics assistance
>
> The scope of that issue was specific text which was found to be "not
> useful, confusing, and potentially harmful".  Again, we find this as
> evidence that identifying specific problems and addressing them works,
> and that there is no need to speculatively remove other text over
> which nobody has identified any problems.
>
>  WAI CG's Consensus Resolutions on Text alternatives in HTML 5 as they
>  recommended: that HTML5 state that "For guidance on accessibility
>  requirements for text alternatives authors should consult WCAG 2.0."
>  and that HTML should not provide any guidance that conflicts with
>  WCAG.
>
> In both cases, if applicable, they can be pursued via bug reports.
>
>  As one study indicates, users prefer embedded reference links into
>  the body of a document
>
> This was found to be indirect evidence that duplication can be helpful
> at times.
>
> == Objections to using the "Techniques for providing useful text
> alternatives"
>
> The following objections were expressed in the survey on the proposal
> to "split out and modify parts of Section 4.8.2.1 the img element":
>
>  the HTML5 specification needs to fully contain a specification of all
>  elements and attribute values of the HTML5 language
>
>  The HTML specification should provide the requirements for the
>  features that it defines. Web content authors, UA developers, and
>  others consulting the spec would be done a disservice if the
>  specification lacked a comprehensive description of <img>'s
>  requirements
>
> The fact that the HTML5 specification should define all elements and
> attribute values is not in dispute.  Nor does any Change Proposal
> suggest that the HTML5 specification not define all of the machine
> checkable requirements.  The question is where best practices for the
> alt requirement should be defined.  On the topic of where the best
> practices for the alt attribute should be defined, this objection does
> not identify any specific problem and therefore was considered weak.
>
> Turning to the "Provide detailed instructions and examples for doing so
> to all readers of the HTML specification." Change Proposal for
> objections, we find an extensive RATIONALE section, starting with:
>
>  * The HTML specification is the logical place to define the HTML
>   language.
>
>  * The HTML specification is where one finds all the other descriptions
>   of requirements that apply to authors of HTML documents.
>
>  * Defining the requirements that apply to HTML's <img> element's
>   alt="" attribute in the same specification as the requirements for
>   the <img> element's src="" attribute makes it more likely that
>   authors reading the requirements for src="" will see the
>   requirements for alt="".
>
> Taken together, we find this rationale to be solid and strong but just
> short of compelling.  Restating: we find this to be a strong objection
> to the wholesale removal of this text.  Of course, specific arguments
> can, have, and will presumably continue to be argued on a case by case
> basis; but a wholesale removal would need to identify a pattern of
> problems and identify a solution that specifically addresses the
> underlying causes.
>
> We find the statements such as "we should ensure that we provide the
> most robust, creditable, usable and useful set of text alternative
> requirements possible" to be uncontested yet unrelated to the problem
> at hand which is to determine _where_ such statements should be placed.
>
> The following statement is found to be in dispute:
>
>  The HTML specification should also include detailed examples of these
>  requirements, because including examples near the text they are
>  illustrating is the most optimal way of explaining those
>  requirements.
>
> No evidence was provided that this was 'optimal'.  Others, cited
> previously, have stated that there are other possible organizations  of
> this material which may be more suitable for some audiences.
> Additionally, there were dubious claims of time savings on behalf of
> others that we cite in the 'Arguments not Considered' section.
>
> Taken together, it suggests that providing this information in multiple
> ways is the most appropriate way forward, and this weakens this
> particular objection considerably.
>
> There were other arguments (e.g., "structural integrity", "layering
> violations") which we did not find necessary to evaluate further as
> they appeared to be lacking supporting evidence of an actual problem
> and could only strengthen what is already a strong case.
>
> == Objections to using WCAG 2.0 to define the requirements
>
> The following objections were expressed in the survey on the proposal
> to let the accessibility requirements on the possible values of the
> text alternatives be defined by WCAG 2.0 and not HTML5:
>
>  WCAG 2.0 is too general and when it provides examples, then they are
>  not authoritative.
>
> A valid objection that was not disputed.  It was weakened a bit by the
> fact that it does not cite specifics.
>
>  WCAG 2.0 itself doesn't contain any concrete examples, because WCAG
>  2.0 aims to be abstracted so highly that it is detached from concrete
>  practicalities.   The WCAG 2.0 techniques document does not appear to
>  be as comprehensive and does not appear to contain as useful examples
>  as the texts proposed by the two other CPs.
>
> A valid objection that was not disputed.  It was weakened a bit by the
> fact that it does not cite specifics.
>
>  WCAG 2.0's techniques for HTML and XHTML were written with HTML 4.01
>  & XHTML 1.0, 1.1, and 2.0 in mind, and don't take into account the
>  plethora of new, changed, or removed features in HTML5 & XHTML5
>
> It is hard to see how this objection applies to a proposal to "Give the
> examples to the Web Content Accessibility Guidelines Working Group
> (WCAG WG) to incorporate into their specs and technique documents"
>
> The only portion of the Positive Effects section of the "split out and
> modify parts of Section 4.8.2.1 the img element" Change Proposal, as
> that was found to be relevant to this Change Proposal was:
>
>  Make it easier to publish updated versions of the recommendations as
>  changes to user agent support and new research for methods of
>  providing text alternatives necessitates modification of the
>  specification.
>
> Again, lacking any evidence of a specific problem, this was found to be
> weak.
>
> We note that the objections we previously extracted from the "Remove
> text alternative examples from HTML draft." Change Proposal also apply
> equally to this proposal, and with the same relative weight.
>
> *** Decision of the Working Group ***
>
> Therefore, the HTML Working Group hereby adopts the REQUIREMENTS
> portion of the "Provide detailed instructions and examples for doing so
> to all readers of the HTML specification.":
>
>  http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
>
> Of the Change Proposals before us, this one has drawn the weaker
> objections.
>
> == Next Steps ==
>
> Since the prevailing Change Proposal does not call for a spec change,
> no further action is required.
>
> Bugs 9169, 9174, 9215, 9216, and 9241 can be pursued separately.  One
> way to proceed would be to close these bugs and open bugs against WCAG
> 2 and/or "HTML5: Techniques for providing useful text alternatives".
> Another way would be to mark them as TrackerIssue and thereby cause new
> issue(s) to be created, with the resolution of such issues having the
> potential to affect any document produced by this working group.
>
> == Appealing this Decision ==
>
> If anyone strongly disagrees with the content of the decision and would
> like to raise a Formal Objection, they may do so at this time. Formal
> Objections are reviewed by the Director in consultation with the Team.
> Ordinarily, Formal Objections are only reviewed as part of a transition
> request.
>
> == Revisiting this Issue ==
>
> This issue can be reopened if new information come up. Examples of
> possible relevant new information include:
>
> * Identification of a systemic pattern of problems based on specific
>  bug reports and their ultimate resolution and identify a solution
>  that specifically addresses the underlying causes.
>
> * Publication of a new version of WCAG that contains sufficient
>  concrete examples relevant to HTML5 which would serve as a suitable
>  reference.
>
> === Arguments not considered:
>
> The following objection was not considered:
>
>  If we do this we should make sure to strip out all content regarding
>  alt="" from the W3C HTML spec, so that there are no contradictory
>  statements across specs.
>
> We only evaluate Change Proposals which actually are brought forward.
>
>  object to this change proposal as the only means to endorse moving
>  all author guidance for accessible and appropriate text alternatives
>  to "HTML5: Techniques for providing useful text alternatives"
>
> All we will look at is the objections and rationale presented.
> Comments that are NOT actual technical objections to material in the
> change proposal ARE NOT ACCEPTABLE and WILL BE IGNORED.
>
>  Include examples for the provision of long descriptions for complex
>  images.
>
> This is the subject of another issue, the status of which is currently
> OPEN.
>
>  Free up the HTML5 editors time, to work on other aspects of the
>  specification.
>
> Lacking direct evidence that this is a problem, this was not considered
> further.  Indeed, the editor actively disputes this in the following
> statement:
>
>  Keeping the text as is minimises the impact on the editor's time,
>  freeing him up to work on bugs.
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Monday, 18 April 2011 21:48:56 UTC