This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Example: <!doctype html><title>Demo</title> <input role=textbox> Causes the error message “Element input is missing one or more of the following attributes: type.”, even though the type attribute has always been optional on <input>. Adding the attribute type=text causes a different error message “Attribute role not allowed on element input at this point”, even though the role attribute is global (allowed on all elements) in HTML5. This bug somewhat resembles bug 15910 (which is RESOLVED FIXED, and appropriately so: that bug is not present now – but it too relates to the role attribute and might reflect a similar underlying problem).
Cc'ing Steve Faulkner to get his feedback. Steve, is <input role=textbox> meant to be valid? From the W3C HTML spec, it's still unclear to me whether elements with strong native semantics are allowed to have role attributes that match their "implicit WAI-ARIA semantics". The WHATWG spec still explicitly disallows that - "Authors must not set the ARIA role and aria-* attributes to values that match the default implicit ARIA semantics defined in the following two tables." http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria ...and while the W3C HTML spec doesn't explicitly disallow it, it seems to me it's still not clear what it does allow ^ http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics For example, is <input role=dialog> meant to valid? Or <input role=link>? etc. (In reply to comment #0) > Example: > > <!doctype html><title>Demo</title> > <input role=textbox> Question: Why are you marking up that way? As far as I understand it, that's not useful for accessibility purposes, because UAs already expose <input> without a type attribute to AT as a textbox. > Causes the error message “Element input is missing one or more of the > following attributes: type.”, even though the type attribute has always been > optional on <input>. Yeah, I agree that's not a helpful error message in this case. > Adding the attribute type=text causes a different error message “Attribute > role not allowed on element input at this point”, even though the role > attribute is global (allowed on all elements) in HTML5. But in some cases the spec additionally gives specific constraints on where role can be used, based on its value: http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics So, far example, <input type=checkbox role=button> is explicitly disallowed by the HTML spec. Yeah, it does not explicitly disallow <input type=text role=textbox> but then it (the W3C version at least) doesn't clearly and explicitly disallow <input type=text role=dialog> or <input type=text role=dialog> either, as far as I can see. > This bug somewhat resembles bug 15910 (which is RESOLVED FIXED, and > appropriately so: that bug is not present now – but it too relates to the > role attribute and might reflect a similar underlying problem). Right. See my comment there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15910#c7 [[ So I think what we are leaning toward is only allowing cases like <button role=button..> if there is also some other aria-* attribute(s) on the element; e.g., aria-pressed. ]] But actually, we (Steve and I) never got around to discussing that further and now spec change has been made yet to address it.
(In reply to comment #1) > But actually, we (Steve and I) never got around to discussing that further > and now spec change has been made yet to address it. s/now spec change/no spec change/
(In reply to comment #1) > From the W3C HTML spec, > it's still unclear to me whether elements with strong native semantics are > allowed to have role attributes that match their "implicit WAI-ARIA > semantics". I don’t see anything unclear here: the W3C HTML5 Candidate Recommendation specifies that the role attribute is allowed for all elements. Later it imposes restrictions on its values. > The WHATWG spec still explicitly disallows that - It does. This raises the question what exactly the validator is validating against: W3C HTML5 CR, W3C HTML 5.1 WD, WHATWG Living HTML du jour, or something else? > ...and while the W3C HTML spec doesn't explicitly disallow it, it seems to > me it's still not clear what it does allow ^ Especially since W3C HTML5 CR explicitly says that the role attribute is allowed on all elements, it clearly allows anything in that attribute that it does not explicitly disallow. We can also infer that in all cases, there must be at least one valid value for the attribute. > For example, is <input role=dialog> meant to valid? Or <input role=link>? > etc. As per W3C HTML5 CR, no, since these attributes would conflict with the strong native semantics, violating a requirement in the first sentence of 3.2.7. For <input type=text> (without a suggestions source element), the only allowed value for role is the default value of textbox. It might be argued that it is then pointless to specify that attribute, and it might also be argued that it is pointless to disallow it. In any case, you just need to decide which of the alternatives you regard as the “HTML5 specification”. > > <!doctype html><title>Demo</title> > > <input role=textbox> > > Question: Why are you marking up that way? I’m not. I encountered it in a discussion about a person’s attempt at learning to use the role attribute. The error messages caused quite some confusion. > As far as I understand it, that's > not useful for accessibility purposes, because UAs already expose <input> > without a type attribute to AT as a textbox. Maybe. But it is at least imaginable that some software recognizes the ARIA role attribute without knowing the intrinsic semantics assigned to some element in this or that HTML specification. > > Adding the attribute type=text causes a different error message “Attribute > > role not allowed on element input at this point”, even though the role > > attribute is global (allowed on all elements) in HTML5. > > But in some cases the spec additionally gives specific constraints on where > role can be used, based on its value: > > http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria- > semantics First, that part of HTML 5.1 Nightly (which says that “it is inappropriate to cite this document as other than work in progress”) does not impose any restrictions on role in <input type=text>. Second, the error message says that the role attribute is not allowed, instead of complaining about the value of the attribute. > Yeah, it does not explicitly disallow <input type=text role=textbox> but > then it (the W3C version at least) doesn't clearly and explicitly disallow > <input type=text role=dialog> or <input type=text role=dialog> either, as > far as I can see. There is no ambiguity on either issue in the W3C HTML5 CR, and the issues are distinct: even if the latter were ambiguous, this would not constitute a reason for regarding the former as ambiguous – it needs to be considered on its own. > https://www.w3.org/Bugs/Public/show_bug.cgi?id=15910#c7 > > [[ > So I think what we are leaning toward is only allowing cases like <button > role=button..> if there is also some other aria-* attribute(s) on the > element; e.g., aria-pressed. > ]] This would make things even more complicated, and I don’t see why you would allow the role attribute in such a case if you don’t allow it otherwise. From what I read between lines, it seems that the odd error message “Element input is missing one or more of the following attributes: type” for <input role=textbox> reflects the idea that role=textbox is allowed on <input> but not for type=text, so the error message is trying to say that the element should have a type attribute with a value other than text. And the error message “Attribute role not allowed on element input at this point” is meant to say that the role attribute with the specific value used in the markup is not allowed when the type attribute has the value text. But the messages are very confusing, and for some reason, different error messages are given about essentially the same situation (type property has the value text, the difference being just in it having that value by default vs. due to explicit type=text attribute).
(In reply to comment #3) > (In reply to comment #1) > > For example, is <input role=dialog> meant to valid? Or <input role=link>? > > etc. > > As per W3C HTML5 CR, no, since these attributes would conflict with the > strong native semantics, violating a requirement in the first sentence of > 3.2.7. OK, yeah, I had read that sentence previously, and that's one of the requirements which the existing implementation in the validator is based on. But I'd really prefer it were stating closer to the table that lists what the strong native semantics are. I'll talk with Steve about it. > For <input type=text> (without a suggestions source element), the > only allowed value for role is the default value of textbox. I see what you're saying. Because <input role=text> is the only role value that doesn't conflict with the strong native semantics of <input>/<input type=text>, it isn't disallowed. Again though, I'd really prefer if that were stated somewhere more explicitly. I mean, if it's not clear to me after having spent many hours refining the ARIA support in the validator, I don't think the average Web author has any hope at all of trying to understand what the requirements are. > > [[ > > So I think what we are leaning toward is only allowing cases like <button > > role=button..> if there is also some other aria-* attribute(s) on the > > element; e.g., aria-pressed. > > ]] > > This would make things even more complicated, and I don’t see why you would > allow the role attribute in such a case if you don’t allow it otherwise. I don't really know either. But Steve knows quite a bit and I'm interested in hearing what he's thinking about this these days. > From what I read between lines, it seems that the odd error message “Element > input is missing one or more of the following attributes: type” for <input > role=textbox> reflects the idea that role=textbox is allowed on <input> but > not for type=text, so the error message is trying to say that the element > should have a type attribute with a value other than text. That error message isn't really trying to say anything. It's a dumb error message -- a generic one emitted by Jing based on just reading the schema formalism that tries to capture the base requirements. There are some limitations first of all in trying to using any kind of general formalism to express this stuff, and even more limitations in trying to use grammar-based schema to express them. One of the biggest downsides is that the tools that process those kinds of formalisms can only emit boilerplate “Element %s is missing one or more of the following attributes: %s.” error messages with element and attribute names plugged in. We don't get to choose what the error message says, unless we just allow anything in the grammar and then disallow in some post-processing that does enable control over the content of error messages. We do that in the validator already some cases. This may be a another case where we want to switch to doing it that way. > And the error > message “Attribute role not allowed on element input at this point” is meant > to say that the role attribute with the specific value used in the markup is > not allowed when the type attribute has the value text. But the messages are > very confusing, and for some reason, different error messages are given > about essentially the same situation (type property has the value text, the > difference being just in it having that value by default vs. due to explicit > type=text attribute). That's an artifact of the complexity of the grammar-based schema wer're using and the relatively poor error message that Jing emits. I may be able to improve it by tweaking how it's expressed in the schema. I'll look. In the mean time, if you're curious, you can find the relevant part of the schema here: https://bitbucket.org/validator/syntax/src/default/relaxng/web-forms.rnc?at=default#cl-48
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > For example, is <input role=dialog> meant to valid? Or <input role=link>? > > > etc. > > > > As per W3C HTML5 CR, no, since these attributes would conflict with the > > strong native semantics, violating a requirement in the first sentence of > > 3.2.7. > > OK, yeah, I had read that sentence previously, and that's one of the > requirements which the existing implementation in the validator is based on. > But I'd really prefer it were stating closer to the table that lists what > the strong native semantics are. I'll talk with Steve about it. > > > For <input type=text> (without a suggestions source element), the > > only allowed value for role is the default value of textbox. > > I see what you're saying. Because <input role=text> is the only role value > that doesn't conflict with the strong native semantics of <input>/<input > type=text>, it isn't disallowed. Again though, I'd really prefer if that > were stated somewhere more explicitly. I mean, if it's not clear to me after > having spent many hours refining the ARIA support in the validator, I don't > think the average Web author has any hope at all of trying to understand > what the requirements are. > > > > [[ > > > So I think what we are leaning toward is only allowing cases like <button > > > role=button..> if there is also some other aria-* attribute(s) on the > > > element; e.g., aria-pressed. > > > ]] > > > > This would make things even more complicated, and I don’t see why you would > > allow the role attribute in such a case if you don’t allow it otherwise. > > I don't really know either. But Steve knows quite a bit and I'm interested > in hearing what he's thinking about this these days. > > > From what I read between lines, it seems that the odd error message “Element > > input is missing one or more of the following attributes: type” for <input > > role=textbox> reflects the idea that role=textbox is allowed on <input> but > > not for type=text, so the error message is trying to say that the element > > should have a type attribute with a value other than text. > > That error message isn't really trying to say anything. It's a dumb error > message -- a generic one emitted by Jing based on just reading the schema > formalism that tries to capture the base requirements. There are some > limitations first of all in trying to using any kind of general formalism to > express this stuff, and even more limitations in trying to use > grammar-based schema to express them. One of the biggest downsides is that > the tools that process those kinds of formalisms can only emit boilerplate > “Element %s is missing one or more of the following attributes: %s.” error > messages with element and attribute names plugged in. We don't get to choose > what the error message says, unless we just allow anything in the grammar > and then disallow in some post-processing that does enable control over the > content of error messages. We do that in the validator already some cases. > This may be a another case where we want to switch to doing it that way. > > > And the error > > message “Attribute role not allowed on element input at this point” is meant > > to say that the role attribute with the specific value used in the markup is > > not allowed when the type attribute has the value text. But the messages are > > very confusing, and for some reason, different error messages are given > > about essentially the same situation (type property has the value text, the > > difference being just in it having that value by default vs. due to explicit > > type=text attribute). > > That's an artifact of the complexity of the grammar-based schema wer're > using and the relatively poor error message that Jing emits. I may be able > to improve it by tweaking how it's expressed in the schema. I'll look. In > the mean time, if you're curious, you can find the relevant part of the > schema here: > > > https://bitbucket.org/validator/syntax/src/default/relaxng/web-forms. > rnc?at=default#cl-48 hi Mike, as discussed have updated text around this issue please have a look at http://www.w3.org/html/wg/drafts/html/master/dom.html#state-and-property-attributes
(In reply to comment #5) > hi Mike, as discussed have updated text around this issue please have a look > at > http://www.w3.org/html/wg/drafts/html/master/dom.html#state-and-property- > attributes Thanks. I've updated the validator now, and the "<input role=textbox>" case is no longer reported as an error. I fixed it for other input cases as well.