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.

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: Requesting that the non-normative summary be explicitly part of the normative table

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

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

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

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.

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