W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2010

[Bug 10066] replace section 3.2.6 with the alternative spec text provided

From: <bugzilla@jessica.w3.org>
Date: Sun, 22 Aug 2010 02:41:24 +0000
To: public-html-a11y@w3.org
Message-Id: <E1On0Uu-0007Km-56@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10066





--- Comment #12 from Maciej Stachowiak <mjs@apple.com>  2010-08-22 02:41:23 ---
When I produced the diffs attached to this bug, I found that they fall into the
following categories:


1) Use of some ARIA property attributes is restricted when a related native
HTML attribute is present.

2) Some elements that previously had no default role and allowed any role
simply because the spec did not say otherwise, are now explicitly documented as
allowing any role. Oddly, some remain undocumented though.

3) Some elements have much less restrictive sets of allowed roles in the
proposal than in the current draft. In some cases (e.g. <a role=button>) it's
clear how this relates to the rationale based on actual author usage practices.
In other cases (e.g. <a role=scrollbar>, <input type=checkbox role=radio>),
it's not obvious without further explanation how that rationale applies. Are
these things that authors really do? If so, are there examples that can be
cited? I don't think I have ever seen an <a> element used as a scrollbar or a
slider myself, and I've seen a lot of crazy markup.

4) Some elements have a more restrictive set of allowed roles and/or new
default roles. For example, embed allows any role in the current draft, but in
the proposal is limited to no role, application, document or image. As another
example, keygen is now not allowed to take any role at all.

5) Some elements are about equally restrictive but just different. For example
<menu type=context> changing from no role to "menu".


I also noticed the following notable details in the changes:

1) Element default roles that are not explicitly documented in the proposal.

The proposed new ARIA section explicitly lists most of the elements which have
no role by default and can be given any role. However, it seems to have missed
the following:

a (that does not represent a hyperlink)
area (that does not represent a hyperlink)
caption
command
dd
dl
dt
h1-h6 (with an hgroup ancestor)
img (that does not have an empty alt)
li (with no ol or ul parent)
optgroup
option (not in list of options or datalist)

2) Elements that have their default role changed

These differences seem more individually notable than the others, and may be
oversights in either the current spec or the proposal. They might be worth
extra attention.

details - changed from no role to "button" role
input type=file - changed from "button" role to no role
link (that represents a hyperlink) - changed from "link" role to no role
menu type=context - changed from no role to "menu" role
output - changed from "status" role to no role
math - changed from no role to "math" role
table - changed from "grid" role to no role
td - changed from "gridcell" role to no role
tr - changed from "row" role to no role

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Sunday, 22 August 2010 02:41:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:13 UTC