W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Working Group Decision on ISSUE-129 aria-mapping

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 28 Feb 2011 21:30:15 -0500
Message-ID: <4D6C5A37.3070704@intertwingly.net>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC