Objections against CP for ISSUE-129

If there is objectionable material in the other change proposal that would be inappropriate to list in the Change Proposal for ISSUE-129, then list it here so that it can be tracked and presented during the poll.

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 situations.
• 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 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.

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

http://jqueryui.com/demos/dialog/

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

http://developer.yahoo.com/yui/examples/carousel/carousel-ariaplugin_source.html

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.

http://developer.yahoo.com/yui/examples/tabview/tabview-ariaplugin_clean.html

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 anyway.

http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html

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.)

http://jqueryui.com/demos/slider/

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").

http://masinter.blogspot.com/

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

http://www.jstree.com/demo

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.

Objections to the proposed text

Overview

• The proposed text contains internal contradictions. For example, it suggests that the "abbr" element has no default role, but then specifies that the "abbr" element (when defining a command) has, in certain cases, the "menuitem" role; it also simultaneously allows authors to use aria-* attributes only in manners allowed in the HTML spec, allows authors to use aria-* attributes in any manner allowed in the ARIA specs, and requires authors to not use the aria-* attributes in ways that conflict with certain requirements, leaving the exact conformance situation highly unclear.

• The proposed text either abuses RFC2119 or has bogus conformance statements (it's unclear which). For example, the text explicitly allows "conflicts" to make things "difficult for assistive technology" (presumably mis-use of RFC2119, since "conflicts" are obviously not a defined conformance class); it also in another paragraph allows authors to "need" to do something.

• The proposed text has redundant conformance requirements, for example it restricts how people may use ARIA features multiple times with subtly different phrasing, without explaining why the requirements are repeated or whether the subtle differences are intended or not. Another example is how it simultaneously has a generic rule regarding state attributes matching equivalent HTML attributes, and has explicit rules for specific attributes. Another example is that it requires support for both the entire ARIA specification and then explicitly requires support for a subset of that specification.

• It contradicts the ARIA specification. For example, for "abbr" elements it says any aria-* attribute is allowed, but the ARIA spec restricts which attributes are allowed based on the role.

• It doesn't use the terms defined by ARIA for the purposes required by this section. For example, the term "strong native semantics" is not used. This means the spec breaks the normative definition chain.

• It allows ARIA attributes that are redundant with HTML native features, despite this having been demonstrated to result in cargo-cult accessibility authoring, which is harmful to accessibility, as discussed in bug 11557 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=11557).

Title and introduction

• The change proposal adds an introduction, but the change proposal does not provide any rationale for this. (See also the objections regarding whether such changes should even be in scope of ISSUE-129.)

The tables

• The proposed text supposedly alphabetises the elements to which roles, states, and properties can be applied. However, this is nonsensical:
  • The list is not a list of element types, but a list of conditions that elements can find themselves in, so it makes no sense to alphabetise the list by element name (some of the rows don't have any element name at all!).
  • The list's ordering was the only mechanism for resolving conflicts, by changing the order arbitrarily, this resolution mechanism is lost (leading to some of the problems listed in the overview above).
• The table contains numerous tautological statements, e.g. saying that "Applicable widget attributes and global attributes" may be applied.
• The second table is simply wrong. Here are some examples (there are many more errors; these is just a sample):
  • It refers to the disabled attribute rather than the disabled concept, so for example it requires aria-disabled="true" to be set on controls that are descendants of disabled FIELDSET elements.
  • It requires that draggable="" be set on elements that are marked as aria-grabbed, even though you can drag elements that don't have the attribute and setting the attribute would affect the user interface in a potentially breaking manner.
  • It requires that the aria-checked="" attribute match the default value of the checkedness of a checkbox element, rather than the current state.
  • It disallows aria-multiselectable="false" even on INPUT type="email" elements where "false" is the only sane value.
  • It uses terms like "match the state" or "match the value" without defining them.
  • It requires that aria-autocomplete be set in a way that mirrors the autocomplete="" attribute, despite this contradicting ARIA requirements (aria-autocomplete="" is about author-provided autocompletion UI, not UA-provided UI; the UA obviously is responsible for making its UI accessible, not the author!), and despite this being harmful to accessibility even if it didn't contradict ARIA (since it would mean that any UA with unusual autocompletion UI would be inaccessible on pages that followed the rules given in the proposal).

The Guidance for User Agents section

There is nothing of use in this section. All the requirements and statements are redundant statements repeating requirements or statements from elsewhere in the HTML and ARIA specifications. All it serves to do is lengthen the specification and potentially confuse readers.

The HTML to Platform Accessibility APIs Implementation Guide

The change proposal surreptitiously includes an entire extra document which it mentions in passing should possibly be an appendix to the specification. The paragraphs below summarise objections to that document.

This document contains requirements that are redundant with the HTML, ARIA, and ARIAIMPL specifications. Having specifications state redundant requirements is very poor form for specification writing, as it leads to unintended ambiguities (where different specifications unintentionally state things slightly differently), and thus interoperability failures. Implementors and advocates who are not fully engaged with the standards process are likely to try to find meaning in the unintended differences, with often quite unexpected conclusions (just look at the folklore that has sprung up around the spelling of the specification's name — is there a space between the "HTML" and the "5" or not? Entire yarns of pseudo-history have been spun around this question). These problems can be especially pernicious because to advocate that an implementor who follows one spec should instead follow the other requires more than the usual standards-compliance advocacy (and indeed, can be at odds with that advocacy, since it requires violating one spec to follow the other).

Furthermore, not only is the proposed document redundant, it is both incomplete and inaccurate. As currently written it presents a dramatically oversimplified view of the requirements on implementations, but even as currently written it does not claim to be complete, with numerous holes, an entire "To Do" section, and question marks throughout.

In fact, the proposed document is unnecessary. Vendors have not shown an inability to read the existing normative specifications, and the text does not help authors or readers of the specification. While it would be fine for the working group to publish a note of this kind (with suitable disclaimers), it is inappropriate as an addition to the specification itself.

Counter Change Proposal

See Change Proposal for ISSUE-129.