Change Proposal for ISSUE-129

Summary

Change nothing.

Rationale

The bug titles given below are intended to describe the actual underlying requests or issues raised in the bugs. They do not match the original bug summaries as those were often quite misleading when compared to the actual requests.

General points

The current section defining the relationship between the HTML and ARIA specifications uses an approach eminently suited for addressing accessibility in HTML. It is defined in terms that the ARIA specification uses, provides the information needed by implementors, authors, and validator writers, and provides a coherent and concise set of UA and document requirements.

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. The current specification text achieves this: it balances the conformance crtieria 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. It does not allow overrides of widget roles by unrelated widget roles, or allow overrides of semantic roles by unrelated semantic roles, nor does it allow for overriding of aspects of elements. It allows roles to be overriden by their children in the ARIA role taxonomy where that makes sense, and disallows it where it does not. (The role taxonomy in ARIA is based on a role's features; it does not follow that children are always more specific versions of the same concept. For instance, menuitemradio and menuitemcheckbox are not interchangeable in user interfaces, but in ARIA the former is a child of the latter.)

Bug 10444: Requesting a list of all the elements that do not have a default ARIA role

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444

• There's no clear use case for this. Implementors wouldn't benefit (no default role would just be the overall default, so there's no need to list out which specific cases it should apply to). Authors wouldn't benefit (the section is listing restrictions, it's self-evident that anything that isn't restricted is unrestricted). Validators wouldn't benefit (there's nothing to implement if it's not a restriction).

• An accurate list would be confusing to authors. For example, for each element one would have to explicitly list that it does have a role if the accesskey is set with a valid value that the user agent was able to apply, etc. For elements that have roles in specific situations, like H1 which only has a role when it's not in an HGROUP, or INPUT elements which only have roles when their TYPE attribute is in particular states, the situation is even worse, because the list would have to give all the conditions not matched by the elements when the do have a role. Thus, the list would be extremely opaque and would not be helpful to authors — indeed on the contrary, it would lead authors to thinking the situation was far more complicated than it really is, potentially leading to them not using the features at all, which could conceivably harm accessibility.

• An accurate list would be incredibly hard to maintain, because of the complexities described in the previous point. No accurate list has been put forward; the only attempts at making such a list so far have been either vague or woefully inaccurate.

• Even a vague list would be hard to maintain. We actually had a vague non-normative list in the spec for a while, but ended up removing it from the spec because of the maintenance nightmare that it spawned (the list kept having to be updated because errors kept being found — and that was just with a non-normative vague list).

• Confusion stemming from the inevitable inaccuracies listed in the previous points will likely lead to implementation mistakes, leading to poor interoperability, which would harm accessibility (since this is an accessibility feature).

In summary: no use cases, maintenance nightmare, might even harm accessibility.

Bug 10462: Merge the table defining strong native semantics and the table listing role and state constraints into a single table

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10462

Providing unclear or ambiguous guidance to authors about how ARIA can be used in HTML5 is likely to negatively impact the correct use of ARIA on the Web. Indeed, failing to provide such information does a disservice to both Web developers, who author ARIA-supporting applications, and to users with disabilities, who rely on those annotations to make use of those applications.

Therefore, it is imperative that the information provided be structured coherently, be compatible with ARIA terminology, and be correct. To this end, it is important that elements with strong native semantics be specified separately from elements with mere defaults and some constraints, and that both sets of requirements be properly introduced with RFC2119 and ARIA terminology. This is what is done in the specification as it stands today.

In summary: keeping the tables separate is key to maintaining the clarity of the specification.

Bug 10448: Allow links to be described as scroll bars, buttons to be described as progress bars, etc

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448

No use cases have been provided to explain the benefit of allowing links to be described as scroll bars, buttons to be described as progress bars, and so forth, despite repeated requests for use cases.

See also the section below explaining why use cases are necessary for such features.

Note: a working group decision not to add the apparently arbitrary set of roles discussed in the above bug should not be taken as a working group decision not to add specific roles in specific situations in the future, as use cases are put forward. Should a use case be provided for a particular combination, they should be considered on their own merits and added if appropriate.

Summary: no use cases.

Bug 10449: Allow an H1 element to be described as a spinbutton or checkbox, etc

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449

No use cases have been provided to explain the benefit of allowing headings to be described as spinbuttons, checkboxes, and so forth, despite repeated requests for use cases.

See also the section below explaining why use cases are necessary for such features.

Note: a working group decision not to add the apparently arbitrary set of roles discussed in the above bug should not be taken as a working group decision not to add specific roles in specific situations in the future, as use cases are put forward. Should a use case be provided for a particular combination, they should be considered on their own merits and added if appropriate.

Summary: no use cases.

Bug 10481: Set the default role of IMG elements to ARIA's "img" value

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481

Bug 10493: Requesting additional prose in the HTML spec stating that certain roles defined in the ARIA spec have restrictions on their use defined in the ARIA spec

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493

Bug 10592: ?

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10592

Bug 10594: ???

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10594

Bug 10603: ?

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603

Bug 10903: Requesting more introductory text

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903

Bug 8000: Allow authors to use elements in ways that contradict their semantics

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8000

Details

Change nothing.

Impact

Conformance Class Changes

None.

Objections to the other change proposal

If there is objectionable material in the other change proposal that would be inappropriate to list in the above CP, then list it here so that it can be tracked and presented during the poll.

Process objections

• The discussion about changing the title or adding an introduction section seems out of scope for this issue, since it is already covered by issue 109, which has already gone to poll and is awaiting a chair response.

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 addition the merging of the tables in the current spec text [sic]

• The premise that the current text does not define which roles, states, and properties can be used in which situations is flat-out incorrect. That is the bulk of the current section, and it is defined very precisely.
• No reasoning is provided for merging the list defining the strong native semantics and the list defining restrictions for elements without strong native semantics.
• Merging these tables results in confused conformance criteria; the subtlety of the current spec's requirement is lost. For example, compare the text in the current spec to the text in the proposed text when it comes to defining the requirements on an input element with a type attribute in the Number state. The current spec text is straightforward. The proposed text in this CP is incoherent. This is, IMHO, a result of this misguided attempt at merging the tables.

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

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

Miscellaneous specifics

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