Working Group Decision on ISSUE-204 aria-hidden

The decision follows.  The chairs made an effort to explicitly address
all objections that were provided in response to the poll, as well as
arguments presented in the Change Proposals on this topic.

*** Question before the Working Group ***

The HTML WG has not reached consensus on how to exempt ARIA attributes
from the rule that prohibits reference to hidden elements. This straw
poll results from discussions on bug 12228. This bug has not been
resolved and it is considered that further discussion in bugzilla will
not result in the bug beings resolved. This issue has been captured as

== Objections that apply to both proposals

This issue has been open since February, and resulted in convergence to
two separate proposals.  Despite this, we have a number of objections
that apply to both proposals, and therefore don't contribute to our
current task of identifying the proposal that draws the weakest
objection.  As described later in this decision, such could be
considered in the future if the objections were accompanied by new
information sufficient to have changed the decision as well as a
concrete Change Proposal.

The majority of these objections deal with relationship to other

     The ARIA specification does Implementation in Host Languages
     ( Nowhere in here does
     it state that other specifications can redefine how authors should
     use ARIA.

     This provides yet another place where the WAI-ARIA specification
     team needs to keep track of authoring guidance. We have both an
     authoring practices guide as well as a user agent implementation
     guide. The HTML specification must not be dictating the
     implementation of another spec. by authors or user agents unless
     agreed upon by members of that working group for this reason.

     WAI-ARIA is a cross cutting technology. Any restrictions should be
     addressed in WAI-ARIA so that they may be applied to other host

     because it contradicts WAI-ARIA 1.0’s normative requirements for
     calculating the accessible description for a node in the
     accessibility hierarchy.

     This belongs in the WAI-ARIA specification and it would be a very
     good issue to address in ARIA 1.1

     because it contradicts WAI-ARIA 1.0’s normative requirements for
     calculating the accessible description for a node in the
     accessibility hierarchy.

     It is inappropriate to base any HTML 5 behavior on the current ARIA
     specifications because the current ARIA specifications are normative
     for HTML 4 only. Work has not yet begun on ARIA for HTML 5, except
     as has been negotiated with the PF-WG expressly for use in HTML 5

Additionally, there was one comment that applied to a specific part of
the details of one change proposal, and applied equally well to the base
part of the spec that the other proposal did not replace.  This was the
objection to the following text:

     When specified on an element, it indicates that the element is not
     yet, or is no longer, directly relevant to the page's current state,
     or that it is being used to declare content to be reused by other
     parts of the page as opposed to being directly accessed by the

== Substantive differences in behavior

Objections to 'User Agents are encouraged to expose the full semantics
of hidden="" elements to Assistive Technology when such elements are
referenced from WAI-ARIA attributes such as aria-describedby="".'

     * This creates an undue burden on assistive technologies.

     * This can result in harmful behaviors, particularly with regard
       to tab focus requirements.

Objections to 'should avoid':

     * This would be an unnecessary restriction on authors (in some
       examples, flattening would not lose any essential meaning)

== Wording choice

There were a number of arguments based on wording choices:

   * The use of the word should vs. must leaves impression of doubt on
     whether authors should use use aria-describedby to reference hidden

   * objections to should avoid: "This is a confusing way of expressing
     it, since it doesn't use the RFC2119 language used for other
     restrictions in ‘HTML5’."

   * objections to the definition of structured text being given by
     example, thereby leaving room for differences of opinion on whether
     a particular element is structured or not.

   * objections to the list of example elements using both “eg” and
     “etc”, since this is nonsensical.

   * objection to “When specified on an element, it indicates that the
     element is not yet, or is no longer, visible or interactive”:
     implies @hidden is presentational and specific to the visual medium.

   * objection "Since the content is not rendered, linking to it would
     result in behavior the user does not expect, either dropping the
     user at a location with no rendered content, or failing to
     navigate.": this contradicts the spec elsewhere, which fully defines
     the result

== Evaluation of arguments

As described above, there were a number of objections that apply to both
proposals, and in at least one case are made by the same individual
against both proposals.  If the people who felt this way had presented a
third proposal, then these arguments would have been considered. As it
is, these arguments don't help select between the two proposals that we
do have.

As described later in the "Revisiting this Issue", providing such a
proposal would be a key part of causing this issue to be reopened.

Additionally, there were a number of objections based on wording
choices.  Some cases are purely editorial.  Additionally, two
objections don't clearly make their case: these are "should vs must",
"implies presentational".

Rather than making a decision based on correctable flaws, the chairs
would prefer that those that wish to pursue this do so by opening bug
reports.  Meanwhile, the chairs are asking the editors to first apply
the decision as is, and then will encourage the editors to work with the
Working Group to make whatever editorial and factual corrections are
necessary, as long as the end result does not invalidate this decision.

This leaves the substantive difference in behavior objections.
Unfortunately, none of these are conclusive.

   * Assertion of "undue burden" is made without evidence, and is largely
     (but not completely) refuted by statements in the other proposal
     that there exist two implementations which are prepared to implement
     this change.

   * Assertion of "harmful behaviors" is also not sufficiently supported
     by evidence.  In particular, it makes a claim that has previously
     been disputed, and without a single example of such markup.

   * "unnecessary restriction" is weakened by the lack of any evidence
     that there is sufficient pent up demand to introduce markup lacking
     in "essential meaning" to counter-balance the (alleged) potential
     harm and (potentially temporary) lack of interoperability that such
     would introduce.

As such, this decision comes down to burden of proof.  In the case of
"undue burden" the burden of proof would be on those that claim that
there is a burden.  In the case of "harmful behaviors", the burden of
proof would be on those that claim that the behaviors are harmful.  In
the case of "unnecessary restriction" the burden of proof would be on
those that argue for the restriction.

Therefore we find "unnecessary restriction" to be the strongest
objection.  To help explain this conclusion, applying the principle of
burden of proof to these specific objections results in the following:

At the F2F there appeared to be genuine and widespread interest in
allowing browser vendors to experiment with allowing rich markup to be
exposed in hidden areas via accessibility APIs.  Discouraging authors
from producing such markup runs counter to that goal.  Despite this,
actual evidence of harm or burden would justify such a restriction, if
such objections could be adequately substantiated.

As described in the "Revisiting this Issue", providing such evidence
would be a key part of causing this issue to be reopened.

== Not considered

Additionally, we got an response to the survey that was not considered:

     I will push for a formal objection by IBM of the HTML 5
     specification if this change proposal goes through

These types of statements have no place in surveys. As stated above, no
evidence was provided backing the assertion of "undue burden".  As
described below, such evidence would be considered sufficient new
information to reopen the issue. Lacking such evidence, we believe that
this objection would be unlikely to receive serious consideration by the

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the
"AllowAriaReferHidden" change proposal:

Of the Change Proposals before us, this one has drawn the weaker

== Next Steps ==

Bug 12228 will be REOPENED and marked as WGDecision.  Once the editors
have made the change, ISSUE-204 will be CLOSED.

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

== Revisiting this Issue ==

This issue can be reopened if new information is presented. Examples of
possible relevant new information include:

* Demonstration of actual harm, using markup that lacks in
   "essential meaning", coupled with either an actual example of an
   implementation that  demonstrates the problematic behavior or a
   statement by an implementator that they can't implement the change
   proposal in a way that does not expose this problematic behavior.

* Demonstration of undue burden, ideally in the form of first hand
   statements by actual implementors accompanied by a sufficient
   description of the implementation details to explain why this
   requirement presents such a burden.

* A revision of WAI-ARIA that addresses this issue, accompanied by
   technical rationale why the solution adopted by that specification is
   superior to the one reflected in the HTML5 specification, and a
   concrete change proposal as to how the HTML5 specification should be

Received on Monday, 13 August 2012 22:30:10 UTC