- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 18 Apr 2011 16:15:20 -0500
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
For the Accessibility Task Force's information:
QUOTE:
*** 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.
http://lists.w3.org/Archives/Public/public-html/2011Apr/0453.html
---------- Forwarded message ----------
From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 18 Apr 2011 16:53:51 -0400
Subject: Working Group Decision on ISSUE-31 / ISSUE-80 requirements survey
To: "pub >> HTMLWG WG" <public-html@w3.org>
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.
--
Laura L. Carlson
Received on Monday, 18 April 2011 21:15:48 UTC