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

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





--- Comment #13 from steve faulkner <faulkner.steve@gmail.com>  2010-08-22 05:24:24 ---
Maciej wrote:

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

all of these are in the latest draft except "option (not in list of options or
datalist)" as I could not find where the option element can be used in
circumstances other than in a  list of options or a datalist,





(In reply to comment #12)
> 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 05:24:26 UTC