W3C home > Mailing lists > Public > www-archive@w3.org > February 2011

Objections to ISSUE-129 CP1

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 9 Feb 2011 20:40:44 +0000 (UTC)
To: www-archive@w3.org
Message-ID: <Pine.LNX.4.64.1102092035490.28618@ps20323.dreamhostps.com>

== Objections to the rationale ==

=== Objections to the rationale's introduction  ===

The rationale of this CP implies that requiring authors to violate the 
semantics of elements should be allowed, but this would lead to serious 
accessibility and data analysis failures, essentially missing the entire 
point of HTML's design philosophy for the past 20 years, and regressing us 
substantially to the days of "font" elements, single-pixel GIFs, and 
layout tables. This would be a disaster for accessibility, a disaster for 
advocacy, and would lead to such confusion amongst the developer community 
that we might easily lose a decade of pro-accessibility advocacy progress 
(historically, developers have reacted quite poorly to dramatic changes in 
the messaging on such topics).

This CP claims that the specification provides tools for authors to 
violate the semantics of an element in the form of JS and CSS, but does 
not provide tools in the form of ARIA. However, this is false. The 
specification provides ARIA tools to violate semantics to the same extent 
as CSS and JS tools; it makes such violations non-conforming regardless of 
the technology used (CSS, JS, or ARIA). Therefore this is a false 
dichotomy: if an author finds it acceptable to violate the specification 
in one place, it stands to reason that violating the specification 
elsewhere would be considered no worse, and if an author does _not_ 
violate the semantics using CSS and/or JS, then there's no need to use 
ARIA for this use either.

ARIA markup happens to be one of the few ways we can programatically 
verify semantic consistency, and seriously relaxing, or indeed removing, 
the restrictions on how ARIA can be applied to HTML would cause us to 
largely, or completely, miss this opportunity to educate users to improve 
their site's accessibility. Furthermore, the specification details care 
that validators need to take in the messaging in this area to encourage 
authors to write better, more accessible markup, rather than having them 
just drop the ARIA -- so the risks detailed in this CP have already been 
mitigated by the specification's current text.

It is important for overall platform consistency that a platform's 
specifications take a holistic approach, considering all of the features 
as a whole rather than each one individually. This CP fails to take such 
an approach, instead treating ARIA markup as a special case to which basic 
design principles somehow do not apply. For instance, it is implicitly 
argued in the CP that authors writing HTML without ARIA are able to update 
their markup, and this is contrasted to the case of an author writing HTML 
with ARIA where it is explicitly argued that the author cannot update any 
markup except ARIA markup. However, this is patently absurd: ARIA markup 
is just as much markup as the rest of HTML, so if one part of the document 
can be edited, so can the rest. Indeed, in conjunction with the 
aforementioned advice for validator implementors, it is more likely that 
authors will correct their non-ARIA markup than the ARIA annotations, 
since the validator is not expected to even mention ARIA in such 

The rationale makes a number of false statements or implications. For 
instance, it refers to ARIA as an "accessibility repair method", which is 
inaccurate (the word "repair" indeed only appears once in the whole ARIA 
specification, in the context of images used for mathematics). The ARIA 
specification's abstract clearly delineates ARIA's role as being for 
describing "accessible user interface elements" that "can be used to 
improve the accessibility and interoperability of web content and 
applications": it is essentially and primarily for annotating "div" and 
"span" elements that are being used to create custom widgets. Another 
example of a false statement or implication in this CP is the assertion 
that the ARIA role taxonomy is designed so that children in that taxonomy 
can always be used in place of their parents. However, this is trivially 
disprovable by example: the "radio" role is a child of the "checkbox" 
role, yet these are not interchangeable native HTML concepts; similarly, 
the "listitem" role, which requires a "list" parent in the DOM, has as a 
child role the "treeitem" role, which requires a "group" or "tree" parent, 
so again these are clearly not interchangeable.

=== Objections to "basis for changes to command roles" ===

This section of the change proposal contains very little rationale; it 
mostly describes the ARIA spec's design and asserts design principles that 
themselves have no rationale. The only argument in this section is that 
the proposed changes are somehow necessary in order to let authors provide 
graceful fallback by using links and buttons which are then overridden by 
ARIA roles for ATs and CSS and JS for non-AT UAs. However, this fails to 
provide the one piece of information that would be helpful: concrete use 
cases. The change proposal allows A and BUTTON elements to be labeled as 
role=progressbar, for instance, but gives no use cases for it. There is no 
scenario described wherein one would need to use a link or button to 
author a a progress bar that had gracefully degradation in legacy UAs (on 
the other hand, the new PROGRESS element allows authors to provide 
graceful degradation in legacy UAs while being both compatible with 
non-ARIA ATs and new ARIA-capable ATs when used with new UAs).

The change proposal should provide specific use cases for the combinations 
it wants to allow. The arguments presented in this section (or indeed 
anywhere in this CP, or in the original bugs that were escalated for this 
issue) fail to provide any use cases at all.

=== Objections to "basis for defining h1 to h6 element that does have an hgroup ancestor" ===

The rationale begins by implying that there is ambiguity regarding the 
default role of elements that the specification does not mention 
explicitly in the accessibility tool annotations section, but there is no 
such ambiguity: the default for _any_ element without strong native 
semantics or implied ARIA semantics is defined by the ARIA specification. 
The change proposal continues to state that it would be illogical for the 
specification to require that headings inside HGROUP elements be exposed 
to UAs in the same way as headings outside HGROUP elements, but this is a 
straw man argument, since the specification explicitly states that these 
two cases are not handled the same way, by excluding headings inside 
HGROUP elements from the normative conformance requirements that apply to 
headings in general.

The change proposal goes on to state that two adjacent H1 elements with no 
role should be handled by ARIA user agents in the same way as two adjacent 
P elements, and that this is bad. However, in practice this is quite 
harmless; indeed, when reading a book title and subtitle one does not 
distinguish them other than by a pause between them ("The Reality 
Dysfunction. Space is not the only void.").

The proposal in fact suggests making the hgroup element have no role, and 
transferring the heading role to the child of hgroup with the highest 
rank. This fails to handle the case of there being multiple such elements, 
and further means that in the ARIA tree, the subheadings are demoted to 
the status of regular paragraphs, which is a significantly worse 
degradation of the semantics than making all the subheadings of equivalent 
weight in the ARIA rendering.

This section also references the outline algorithm, but this is irrelevant 
to the discussion as the outline algorithm is orthogonal to the ARIA roles 
used on elements. It also makes an absurd false statement regarding a 
supposed limitation of the hgroup element (that it can't indicate 
subheadings, despite this being the entire point of the element), which 
would similarly be irrelevant were it in fact true.

=== Objections to "basis for changes to allowed roles on the a element" ===

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 

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.

It cites a few pages, but each one in fact is non-conforming HTML and 
would benefit more from using HTML correctly:

  This uses a link where a button would be more appropriate (closing a
  dialog is not a link, it's an action).

  Despite claims to the contrary both in the CP and in the source of
  the page, this document does not in fact appear to use the role
  attribute. The comment in the source points out a couple of reasons
  why using a link for a button is a bad idea, too.

  I wasn't able to find any ARIA in use on this page. The links that
  would presumably be marked as buttons on this page are better
  presented as links, so it's not clear that this provides a use case

  Again, there does not appear to be any ARIA on this page, but in any
  case it's not clear that any role other than menuitem="" would be
  appropriate for the items in this menu. (menuitem="" is the role the
  HTML spec would enforce on pages that marked this up correctly using
  the "menu" and "a" elements.)

  It would be quite inappropriate for the demo on this page to use a
  _link_ for its UI (the tabindex="" attribute in conjunction with a
  "div" would be much more appropriate). In any case HTML already
  provides for this semantic natively ("input type=range").

  HTML already provides checkboxes; using links for that semantic is a
  misuse of HTML.

  Using links for this semantic is again a misuse of HTML. The "div"
  element is the appropriate element to use for creating widgets of
  this nature.

  GMail's buttons made from links
  GMail mostly uses "div"s for its buttons, but in any case the CP is
  correct: GMail should not use links for buttons.

The CP goes on to admit that the "a" element isn't necessary for these use 
cases, and that "div" will work fine. But it then says that the change to 
the HTML5 spec is needed to work around the lack of a fix to the _HTML4_ 
spec; a fix that has already been applied to the HTML5 spec (and thus 
would take effect at the same time as the workaround, and no later) and 
that has already been widely implemented.

Finally, the CP in this section repeats the assertion that HTML's 
authoring conformance criteria in one section will be ignored, and that 
therefore conformance criteria in another section must be loosened to 
allow authors to work around their mistakes. This is self-contradictory. 
Either authors will follow the spec, in which case they won't need to the 
loosened requirements proposed, or they won't, in which case the entire 
discussion is moot since authors will ignore both the ARIA-related 
conformance criteria _and_ the more fundamental requirements related to 
correct use of elements.

=== Objections to "basis for the img elements defualt role being img" [sic] ===

It is true that we should not mandate UI for any user agents -- and the 
role="" attribute does not. Mapping or not mapping an element to 
role="img" does deny ATs "the ability to offer users a preference about 
what role information they can receive"; if it did, then we would be 
mandating UI, which we should not, just as the CP says.

Even without role=img, a user should still be able to tell his UA and AT 
to zoom into images on the page. If only role=img allowed this, then the 
user wouldn't be able to zoom into background images, images used as 
buttons ("input type=image"), images used a list bullets, etc. Quite 
obviously, this would be a bug in the UA/AT. If the specification's 
current requirements broke ATs, then the ATs would be broken already in 
numerous cases where role=img does not, and cannot, apply to an image 
(e.g. any image in CSS).

=== Objections to "basis for allowing roles on heading elements (H1-H6)" ===

Contrary to some of the statements in this section, it is not "perfectly 
valid HTML markup" to use script on these elements if the result is an 
abuse of the element's semantics. The role="" attribute gives us the 
unique opportunity to catch this particular error as a syntax error. This 
is a good thing, not a problem.

This section also makes the argument that we have to make particular ARIA 
constructs valid because if they're not valid authors won't use them, 
while simultaneously arguing that we need them to be used because authors 
are going to ignore other conformance requirements. Either authors are 
going to follow conformance requirements, or they are not. If they are, 
then the issue raised in this section does not come up. If they are not, 
then there is nothing we can do to authoring requirements that will make 
any difference.

Finally, this section provides an example where a heading, which in the 
graphical representation looks like a heading, acts like a heading, and 
gives no indication of being anything but a heading, happens to have an 
onclick="" handler. It is subsequently argued that in ATs, this heading 
should in fact appear to be a button. However, that would be quite 
confusing to any AT user. For example, should a friend of the reader's 
refer to the heading as a heading, the AT user would have no way to know 
which heading their friend was referring to. The heading in this example 
isn't a button. Exposing it as a button to ATs would be a bug.

=== Objections to "Guiding factors for decisions on ARIA Role use" ===

This section consists of nothing but assertions without rationales. I 
disagree with many if not all of these assertions; they should not be 
considered uncontested, merely unsubstantiated.

=== Objections to the "Positive Effects" section ===

The section claims that the specification as currently written deters 
authors from using ARIA, but this is not true -- the specification 
includes text (which is even included in this change proposal's proposed 
replacement text!) to ensure that conformance checkers do not lay the 
blame with ARIA attribute usage.

The change proposal claims that the proposed changes will allow developers 
to use HTML validators to check ARIA conformance, but that misses the 
point. To check ARIA conformance, an author should use an ARIA validator. 
An HTML validator should check HTML conformance. The change proposal 
prevents that (as it in fact admits).

Finally, this section claims that the proposal will make authoring 
conformance requirements more closely match deployed content, implying 
that this is an improvement. However, it is quite the opposite. The goal 
of conformance requirements is not to reflect _current_ practice, but to 
reflect _best_ practice.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 February 2011 20:41:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:45 UTC