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

Hi Paul,

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

I withdraw my objection.

regards
SteveF

On 10 October 2012 19:35, Paul Cotton <Paul.Cotton@microsoft.com> wrote:

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