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

We have recorded your formal objection to the WG decision on ISSUE-31 / ISSUE-80 requirements survey at:
http://dev.w3.org/html5/status/formal-objection-status.html#ISSUE-031b

Do you wish to maintain this Formal Objection?  If so then we will keep it on this list so that it can be presented to the W3C Director at the next transition of the HTML5 specification.  If not please let us know and we will drop it from the list.

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Steve Faulkner
Sent: Monday, April 18, 2011 5:48 PM
To: Sam Ruby
Cc: public-html@w3.org
Subject: 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/TextAlternativesIssue12
> 2 
> 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 Wednesday, 10 October 2012 18:36:22 UTC