I would suggest using a list to define the various attributes, rather than a long sentence.

I would also suggest clarifying the aria-valuenow instructions.  As best I can tell, it is equal to the value iff the value can be parsed as a number.  Otherwise, (only for a range?) it is the default value, if that can be calculated.  Otherwise, it is undefined?

The various differences are intentional and meaningful; not just editorial. Are there any you think are wrong?

I considered using a bulleted list instead of a comma-separated list in a sentence, but it didn't seem like much of a win.


> I would also suggest clarifying the aria-valuenow instructions.  As best I can
> tell, it is equal to the value iff the value can be parsed as a number. 
> Otherwise, (only for a range?) it is the default value, if that can be
> calculated.  Otherwise, it is undefined?

Otherwise, it is not specified at all.

I'm not sure what there is to clarify.

Some differences are editorial, because of sentence construction and the need to keep sentences grammatical.  They still led me astray when I was doing the comparisons.  (Thus my preference for a bulleted list, which would have made the comparisons more obvious.)

>> I would also suggest clarifying the aria-valuenow instructions.  
>> As best I can tell, it is equal to the value iff the value can
>> be parsed as a number. 

(This was one place where the slight differences in wording confused me -- I was trying to figure out whether or not they also implied differences in edge cases for parsing.)

>> Otherwise, (only for a range?) it is the default value, 
>> if that can be calculated.

Given the level of parallelism, I think (but am not certain) that it would be worth making it even more parallel by adding an explicit note that there is no default value for progressbar or number.

>> Otherwise, it is undefined?

> Otherwise, it is not specified at all.

So the value of <input type=number>six</input> is implementation-defined; browsers are allowed to interpret it as 6 (or 43.7) if they wish, and compatibility is not expected?  I would prefer that it be explicitly the value undefined (or at least null), but admit that my intuition could well be wrong here.

> So the value of <input type=number>six</input> is implementation-defined;
> browsers are allowed to interpret it as 6 (or 43.7) if they wish, and
> compatibility is not expected?

No, not at all. There is no value (more precisely, the value is the empty string). However, there's no numeric value to convey to the AT using aria-valuenow; if this was an explicit HTML DOM we were talking about, the element would have no aria-valuenow attribute.


I haven't added an explicit note that the aria-valuenow attribute is omitted in the cases you mention, because _everything_ is omitted unless stated otherwise explicitly. I don't really see how to make that clearer without just hitting the reader over the head with it, as it were, and that would just make the spec even more painful to read.

I think ARIA integration has been tricky enough that it may be worth erring on the side of being too explicit.

In the specific case of aria-valuenow, range and spinbutton make it a required attribute, so it should exist (but be set to "").  (But the aria spec does seem to allow undefined or absent to be interpreted as the default value, which in this case is "").

> I think ARIA integration has been tricky enough that it may be worth erring on
> the side of being too explicit.

I disagree. I think the danger of being too explicit is that implementors would be swiming in trivial requirements and would miss the important ones.


> In the specific case of aria-valuenow, range and spinbutton make it a required
> attribute

I assume you mean slider and spinbutton.

When the spec sets an implied role=slider, it always also implies aria-valuenow.
For the case of role=spinbutton, there's one case where it can't set aria-valuenow, namely when the value is not known. (Setting it to "" is just as non-conforming as omitting it, except the ARIA spec says it SHOULD NOT be specified if the value is not known, which implies a preference to omitting it.)

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.