W3C home > Mailing lists > Public > www-validator-cvs@w3.org > August 2013

[Bug 22846] Wrong error messages when role attribute is used in <input>

From: <bugzilla@jessica.w3.org>
Date: Sun, 04 Aug 2013 15:53:01 +0000
To: www-validator-cvs@w3.org
Message-ID: <bug-22846-169-WVYk6y2pX0@http.www.w3.org/Bugs/Public/>

--- Comment #4 from Michael[tm] Smith <mike@w3.org> ---
(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:


You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 4 August 2013 15:53:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:19 UTC