- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 28 Feb 2011 21:30:15 -0500
- To: 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 whether or not the role
attribute should be allowed to override rather than merely to refine the
defaults provided by HTML elements, in particular elements other than
<div> and <span>. The result was an issue, two change proposals, and a
straw poll for objections:
http://www.w3.org/html/wg/tracker/issues/129
http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5
http://lists.w3.org/Archives/Public/www-archive/2011Jan/att-0019/ccp-129.html
http://www.w3.org/2002/09/wbs/40318/issue-129-objection-poll/results
== Uncontested observations:
* We would prefer the web be usable by as many people as possible.
* Standard controls are preferred over custom controls
* Web developers break the rules and show no signs of stopping.
* HTML5 provides the means for authors to add scripting, event handler
attributes to any HTML element. It also provides means to adjust
tabindex and visual appearance.
* It is possible to "violate" the semantics of elements using either
JS or CSS. Furthermore it is possible to do so in ways that can not
be reasonably detectable using automated tools.
* It is not creation of WAI-ARIA that caused authors to re-purpose HTML
content.
* ARIA markup happens to be one of the few ways we can
programmatically verify semantic consistency.
* ARIA conformance requirements could provide an indirect mechanism for
automated conformance checkers to flag potential non-conforming uses
of HTML elements, which would otherwise be uncheckable.
None of these were decisive. There were people who supported either of
these proposals even after taking these facts into consideration. The
fact that they were acknowledged up front was appreciated.
Additionally, both sets of proponents make essentially the same claims
for their respective proposals:
* 'balances the conformance criteria outcomes in favour of fulfilling
ARIA's role as a technology to "improve the accessibility and
interoperability of web content and applications"'
* "disallowing ARIA markup that does not make sense, and allowing
markup that does"
We firmly believe that these statements were made in good faith in each
instance.
=== Determining the constituency for this issue
Crucial to deciding this issue is determining the constituency for
role attributes on elements such as the <a> element. In particular
whether this spec text is primarily targeting (to use the vernacular of
the HTML Design Principles) users, authors, implementors, specifiers, or
theoretical purity. As this issue is primarily concerned with
conformance criteria, the objections that were put forward were
primarily ones that concerned authors and ones of theoretical purity.
While there is clearly a deep divide over the topic of theoretical
purity, there also is a very apparent divide over how to categorize the
set of authors. Two extended quotes to illustrate this, first from the
Change Proposal to Change Some Role Mappings:
Currently the a element is defined in the HTML5 specification as an
element that cannot have its native role overriden by ARIA roles.
Developers have and will most probably continue to repurpose the a
element to achieve desired interface features and style
considerations using Javascript and CSS. While re-purposing the
element may be non-conforming in HTML5, there is no indication to
developers when using a conformance checker, because the changes
that are made to make it non conforming cannot be checked using an
automated conformance tool. So there is no reason to believe that as
long as developers find a reason to repurpose the a element they
will stop doing because it says so in the HTML specification. This
view is confirmed by the author of the current ARIA in HTML5
conformance requirements:
"@cwilso I think we both know Web developers aren't going to be
using the specs as a guide of what they can and can't use"
More from the same Change Proposal:
Conformance criteria must not used to lessen the probability that
developers will use ARIA to make their content accessible, it should
be used to ensure that when ARIA is used it is used correctly
according to the WAI-ARIA specification and in such a manner that
will improve the accessibility of the content it is applied to.
Next from the objections to this change proposal:
This section first argues that Web developers aren't going to be
using the specs as a guide of what they can and cannot use, and
promptly uses this to argue for changes to the spec. However, this
is nonsensical. We should not design the spec's authoring
conformance criteria for people who will ignore the spec; they
cannot benefit from such changes. The people who will benefit are
those who _do_ care about the spec, and we owe it to them to provide
them with the most helpful QA tools (such as validators) as we can,
primarily by making the spec's conformance criteria as helpful as
possible, catching as many likely mistakes and authoring
contradictions as possible.
This same section claims that it would be bad if validators
complained about ARIA values when detecting a mismatch between
native semantics and ARIA values, but this is again an argument
against a strawman: the specification in fact specifically suggests
that validators not do this.
Finally, this section fails to actually provide concrete use cases
for the roles it proposes to add.
And more from these same objections:
Either authors will follow the spec, in which case they won't need
to the loosened requirements proposed, or they won't
In the course of these change proposals, numerous examples of existing
sites were cited, include jquery, yui, blogspot, jstree, and gmail. In
each case, the editor systematically excluded these use cases on the
basis of errors orthogonal to the introduction of ARIA attributes.
It is the chair's observation that the Working Group is considerably
more sympathetic to the "copy/paste" culture that has grown up around
HTML than is evidenced by the exclusion of these use cases. In short,
many web sites are produced by copying other sites that work and fixing
only what needs to be fixed. In other cases, people inherit legacy
sites which were produced using practices which are no longer considered
best practice. Additionally, backwards compatibility to older browsers
is specifically mentioned as a motivation for a number of these changes:
"How is graceful degradation in mixed environments not a use case?"
In short, the chairs find that authors who have mostly working but
currently inaccessible sites to be an important constituency to be
addressed and therefore the basis of valid use cases.
== Objections
Based on the above use case, the following objection was found to be
strong:
The current text in the HTML5 spec places severe limits as to what
ARIA roles can be added to which elements in an effort to dissuade
developers from using HTML5 elements and attributes incorrectly.
Accordingly, our attention turned to objections to the proposal to
"change some role mappings", starting with objections from the Counter
Change Proposal:
Conformance criteria must be used to lessen the probability that
developers will use ARIA to make their content inaccessible. This can
be achieved, for instance, by using them to ensure that when ARIA is
used, it is used correctly and in such a manner that will improve the
accessibility of the content to which it is applied.
This simply states that the counter change proposal is one way to
achieve this goal.
An accurate list would be confusing to authors..., which could
conceivably harm accessibility.
We find this to be an argument on behalf of others who are capable of
speaking for themselves, leading to a conclusion which is speculative.
No accurate list has been put forward; the only attempts at making
such a list so far have been either vague or woefully inaccurate.
This objection is lacking in specifics. If the proposal is adopted bug
reports on specific inaccuracies are be encouraged.
Even a vague list would be hard to maintain.
Again, lacking in specifics, and again bug reports are be encouraged.
Confusion stemming from the inevitable inaccuracies
This objection assumes the conclusion.
It is important that elements with strong native semantics be
specified separately from elements with mere defaults and some
constraints
This is no more than a restatement of the point of view that led to the
elimination valid use cases from consideration.
An earlier attempt at resolving bug 10444 (mentioned above) created
substantial confusion in the specification. For this reason, we should
not include the information requested in bug 10444. Since the issue
raised in bug 10444 was fixed, and since no complaints were made in
the bug regarding the fix, it is unclear what would need to change to
further satisfy the request made in this bug.
One incorrect fix does not preclude future corrections. At this time,
we have a concrete change proposal, so it is clear what change is being
requested.
However, both are non-conforming uses of the <a> element in HTML,
because they both use the <a> element for a purpose other than
representing a hyperlink... It's unfortunate, but that's what happens
when there are valid use cases.
Similarly, we find that starting from such markup (be it a willful
violation or simply legacy code being maintained) and needing to add
markup to make the result accessible to be a valid use case.
In any case, the above examples should not be exposed to ATs as
buttons widgets even if they were valid. They are exposed to users as
link widgets, not button widgets, and thus that is the appropriate AT
behaviour and the appropriate ARIA role.
We fail to follow the logic. They are exposed differently to AT users
and non-AT users and therefore this behavior is correct?
Buttons are supported by HTML, and therefore there is no reason for an
author to make a link act like a button to ATs.
We find consensus on the statement that buttons are the preferred
approach in such situations, but do not find consensus on the statement
that "there is no reason".
Making a link act like a button to ATs while leaving it as a link for
non-AT users will lead to non-AT users having a confusing experience,
since the author will think the link is going to appear as a button to
users and may refer to it as such.
The situation being described is exactly the opposite: in case where the
link acts like a button for non-AT users (by virtue of the techniques
such as JS), the use case is to enable the use of aria markup to make
such behave the same for AT users.
What's important to remember is that there are more than two kinds of
user agents; there are at least three... User agents without CSS
support or without scripting support, and certainly without ATs, which
always use the default semantics of the elements.
This is potentially a valid objection, but fails to explore what happens
in the case where such a user agent does not support ARIA, nor the case
where such a user agent does support ARIA. In the former case, it does
no harm. In the latter case, the result would entirely depend on how
ARIA was supported. In the course of this discussion, a large number of
specific examples were provided where existing sites utilized markup in
a way that could benefit from the "change some role mappings" proposal,
and absolutely none were identified which would harm the user agents
which do not support CSS or scripting but does support ARIA in some
fashion. As such this objection was considered to be weaker than than
the objections to the alternative.
The only way to keep things consistent amongst all three is to use
HTML elements appropriately, and not override their semantics with
ARIA.
To date that approach has failed to keep them consistent, nor is there
any evidence that this trend won't continue.
defaulting IMG elements to role=img when most IMG elements do not
convey images would lead to a poor user experience and cannot be
necessary to allow users to interact with images as images.
Potentially a strong objection.
The suggested text, as well as the text that it was intended to
clarify, is merely redundantly repeating ARIA requirements, which are
best left to the ARIA specification.
Misrepresents the bug reported, which was '"ARIA restricts usage of this
role to one per page" is an unclear statement'.
HGROUP elements are essentially equivalent to headings that contain
multiple "paragraphs" (in the sense defined in the HTML
specification). They should be conveyed as such to accessibility
tools.
This simply states as fact, without providing any evidence, a statement
which clearly is in dispute.
We should not make our specifications be confusing, we should not
include redundant requirements that are already in other normatively
referenced specifications, we should not explicitly state that certain
combinations are valid if there's no reason to suspect that they might
be invalid.
A potentially valid objection. It would be stronger if there were
evidence provided that this principle were systematically applied across
the specification.
== Arguments not considered
* This issue started out as a philosophic disagreement over the
direction of the use of ARIA to mark up various HTML elements. Based
on the direction of the chairs, this disagreement was made tangible
first through an expression in the terms of bug reports and ultimately
by actual spec text. A number of objections were stated on the basis
of how individual bug reports were worded; others were stated in ways
that tend to impeach the credibility of various individuals. The
chairs have declined to enumerate these arguments here. Instead we
are merely stating that none such were considered.
* A number of cases of "it is implicitly argued that". We did not
extract any such implicit arguments, and therefore ignored these
counter arguments.
* "missing the entire point of HTML's design philosophy" - if such were
documented and consensus could be found on the expression of this
philosophy, then perhaps this could have been considered, but failing
that we are looking for specific objections. Conversely, the counter
proposal does assert design principles for ARIA.
* "I strongly object to allowing nonsensical roles to be set on
elements. ARIA should be used to *augment* the available semantics of
HTML as necessary, not to subvert them." Once this is stripped of
emotive terms, what remains is a position statement completely lacking
in any substantiation. Again, the chairs believe that proponents of
each proposal believe that their proposal balances conflicting goals
in a way that the other does not.
* "I'd advocate for a short clear message in the HTML5 document that
says to web developers that for customizing the accessible exposure of
their UI go 'here' (ARIA docs)." We only evaluated proposals that
actually were put forward.
=== Specifics
Now that we have addressed objections based on general principles and
objections to things other than the what was actually proposed, we turn
to specifics. While generally we do not allow people to use bug reports
as a means to revisit previous decisions over and over again, in this
case we allowed a large number of bug reports to be pursued as a single
issue. The Change Proposal to "change some role mappings" is in fact a
large change; as such it seems likely that further tweaks in the form of
bug reports would be necessary. Furthermore, it is possible that the
Change Proposal contains some aspects over which we do not find
consensus. Looking for specific objections to the Change Proposal
itself we find:
defaulting IMG elements to role=img when most IMG elements do not
convey images would lead to a poor user experience and cannot be
necessary to allow users to interact with images as images.
The Change Proposal asserts that <img> has been mapped to the MSAA role
'graphic' in IE since the the 1990s, and that EVERY user agent that maps
html elements to accessibility APIs, maps the <img> element to an
image/graphic role in MSAA,IA2, ATK, UIA etc. These assertions are
uncontested. Furthermore, if it were the case that this would lead to a
poor user experience one would be able to substantiate this assertion by
citing a large volume of actual bug reports. None such were cited.
HGROUP elements are essentially equivalent to headings that contain
multiple "paragraphs" (in the sense defined in the HTML
specification). They should be conveyed as such to accessibility
tools.
In this case, we simply have both sides making assertions as to what the
HGROUP element is meant to convey, with precious little provided as
evidence. As such, we find that there is no consensus as of yet as to
what this element means, and don't wish for this decision to preclude
any possibility as of yet.
Several specific issues:
* Allowing slider, scrollbar, or progressbar for <button>, <input
type=image>, or <input type=image>
* Allowing progressbar, radio, slider, or scrollbar for <a>
* Allowing button, checkbox, option, radio, slider, spinbutton, or
scrollbar on <h1>-<h6>
In this case, we have a "concern" without a concrete proposal, and on
the other side we have some "Guiding Factors" without a specific mapping
showing how these factors apply to these specific situations. Given
this state, we endorse the recommendation made in the objections to this
proposal:
In order to justify allowing extremely unusual element/role
combinations (e.g. <h1 role=scrollbar>), some positive account of <h1>
elements being used as scrollbars in the wild should be provided.
Absent that, the utility to users of their conformance checker letting
them know that they're doing something extremely weird is greater than
the utility of repurposing such elements for such different roles.
*** Decision of the Working Group ***
Therefore, the HTML Working Group hereby adopts the ARIA in HTML5:
change some role mappings Proposal for ISSUE-129, with some specific
exclusions. Of the Change Proposals before us, this one has drawn the
weaker objections.
The specific exclusions are:
* Any changes to how <hgroup> elements are to be interpreted, or how
headings contained within such an <hgroup> are to be interpreted.
* Allowing slider, scrollbar, or progressbar for <button>, <input
type=image>, or <input type=image>
* Allowing progressbar, radio, slider, or scrollbar for <a>
* Allowing button, checkbox, option, radio, slider, spinbutton, or
scrollbar on <h1>-<h6>
We encourage discussion to continue on these topics, and for the
discussion to take tangible form as bug reports. Bug reports on these
specific topics will be allowed. Bug reports predicated on the
assumption that use cases of adding ARIA to existing markup that mostly
works but doesn't conform to the ideals defined by the specification
will be summarily closed.
== Next Steps ==
Bugs 10066 is to be REOPENED and marked as WGDecision. Additionally,
Issue 129 is to be marked as CLOSED.
Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal with the exception of the specific exclusions listed
above.
== 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:
* evidence that correct usage is growing rapidly and that that growth is
expected to continue. Ideally, this usage would include a large
subset of the sites that were cited, namely jquery, yui, blogspot,
jstree, and gmail. Alternatively, this evidence could include some
rationale as to why the cases which are cited should outweigh the
evidence provided by these sites.
* a substantial list of User Agents which are scripting unaware and CSS
unaware but are partially ARIA aware to the point where the addition
of role attributes produces substantially worse results than not
having such information available provides. This list would need to
be accompanied by a specific list of sites that employ such
problematic markup. Ideally such evidence would be provided in terms
of first hand statements by implementers of these tools themselves.
* a comprehensive document describing "HTML's design philosophy" over
which we have found there to be W3C Consensus within the Working Group
over the contents of this document.
Received on Tuesday, 1 March 2011 02:30:54 UTC