A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Change Proposal for ISSUE-129: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
Line 10: Line 10:
=== Bug 10448: Allow links to be described as scroll bars, buttons to be described as progress bars, etc ===
=== 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: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448
=== Bug 10449: Allowing an <h1> element to be described as a spinbutton or checkbox, etc ===
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449


== Details ==
== Details ==

Revision as of 00:31, 13 January 2011

Summary

Change nothing.

Rationale

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

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

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: Allowing an

element to be described as a spinbutton or checkbox, etc

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

Details

Change nothing.

Impact

Positive effects

Negative effects

Conformance Class Changes

None.

Risks

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 elements it says any aria-* attribute is allowed, but the ARIA spec restricts which attributes are allowed based on the role.