[whatwg] Validator.nu: "Attribute role not allowed on element h2 at this point."

[Ian Hickson]

On Sun, 10 Jun 2012, Steve Faulkner wrote:
> > > 
> > > I've used role and/or redundant ARIA within the scripting 
> > > environment to minimize calls in applications checking for roles. 
> > > Redundancy doesn't harm anything, I actively promote it, as it does 
> > > help, sometimes.
> > 
> > I disagree with that premise, for what it's worth. Redundancy can lead 
> > to a number of problems; on the Web, in particular, it's common for 
> > redundancy to lead to cargo-cult authoring mistakes. For example, 
> > expert A writes a Web page with some redundant roles, author B copies 
> > markup from that page and changes it to suit their needs, but ignores 
> > the previously "redundant" bits and thus ends up with conflicting 
> > information instead of redundant information. Page ends up being 
> > sub-optimally accessible, because the previously "redundant" 
> > accessibility annotations now conflict with the page's real semantics, 
> > and are wrong.
> 
> Can you provide an example of how using a redundant role value can lead 
> to conflicts?

Sure. Support someone writes:

   <input type=submit name="submit" value="Submit My Form!" role=button>

...and then someone else copies and pastes it, and changes the type and 
name and value, but doesn't know what "role" is:

   <input type=password name="password" value="" role=button>


> for example:
> 
> <nav role="navigation">
> 
> Under what circumstances can this example lead to 'conflicting 
> information'?

User copies-and-pastes this:

   <nav class="fx-2" data-rollup="2s streamB"
        onclick="activateRollup(this)" role=navigation>

...and tweaks it for their sidebar, getting:

   <aside class="fx-3" data-rollup="3s streamC"
          onclick="activateRollup(this)" role=navigation>


> > > You're only really going to need it when making custom widgets with 
> > > <div>s. (There's a lot of ARIA roles you'd never need to use if you 
> > > just used HTML correctly, IMHO.)
>
> You are incorrect here, there are some cases where putting a role on an 
> input is required as implemented in browsers, to allow the use of non 
> global aria attributes on the element. It would be better if this was 
> not a requirement, but until browsers fix their implementations, in 
> limited circumstances it is necessary. this is detailed in 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=11557 a bug for which you 
> have chosen not to fix without providing an adequate explanation. I am 
> unlcear why you want HTML not to ignore implementation realities?

Bugs should be fixed. We shouldn't warp the language to work around 
temporary bugs. We certainly shouldn't teach a new generation of authors 
to use bad authoring styles just because of a transitory issue with 
certain browsers. Just fix the browsers. If in the meantime there are 
hacks that can be applied for those browsers, it's fine for those to be 
done even if they cause validators to raise a red flag -- they _should_ 
raise a red flag.

It's just like writing a paper in school. It's not ok to hand in a paper 
that has Sellotape around the top of each page, one would get points 
dinged for presentation if nothing else. So someone who is reviewing one's 
paper should raise a red flag if one's paper has such tape. However, if 
one's printer has a problem that causes it to slightly rip each page as it 
prints the paper, then maybe it's considered acceptable to have the tape 
on the paper.


On Sun, 10 Jun 2012, Steve Faulkner wrote:
> 
> You don't clearly differentiate between roles, properties and states, 
> ther are quite a few states and properties NOT provided in HTML5 that 
> may have use cases for adding to an input element, for example 
> aria-hapopup, aria-labelledby, aria-decirbedby, aria-controls etc

Could you give an example of any of these in valid use?


On Tue, 12 Jun 2012, Arlen Walker wrote:
> 
> Simply writing code can lead to cargo-culter mistakes. ;{>} Should 
> writing code be barred?

There's a difference between self-explanatory code where copy-and-paste is 
relatively safe, and misterious code that is prone to cargo-culting.

Consider this:

   max="341"

If you copy-and-paste it, it's pretty obvious how to change the maximum to 
340 or 342. But now consider this:

   max="<341 *2 *5"

If someone copies-and-pastes this, they'll have no idea what all the 
symbols mean. Maybe changing 341 to 342 does what they want, or maybe it 
does something completely unexpected. How can they know?

We, as language designers, have to minimise the occurences of the latter 
kind of thing in our language, and have to try to flag every dangerous 
occurence of them so that copy-and-paste authors are less likely to be 
put in this position.


> Seriously, I can see sending a warning, saying "should not," that it's 
> not a good idea. But barring it seems both unnecessary and inconsistent 
> with the rest of the spec. Why do ARIA-related attributes get treated 
> differently from any other HTML attribute? In no other HTML attribute is 
> the author barred from explicitly specifying a default value.

That's not true, actually. By and large I try pretty hard to make it so 
that there is no default value, so that the problem doesn't turn up.

For example, looking at the global attributes, you can't set the default 
value for any of "contenteditable", "dir", "draggable", "dropzone", 
"hidden", "inert", "itemid", "itemscope", "lang", "spellcheck", "title", 
and "translate". For attributes like "accesskey", "class", "itemref", and 
"style" you can technically set it to the default value, but the default 
value is trivial (the empty string), so it's not a cargo-cult problem. For 
other attributes, e.g. "contextmenu", "id", "itemprop", "itemtype", and 
"tabindex" it is technically possible to give the default value, but as 
with role="", it's not conforming.

So all the global attributes are consistent with the decision for role="".


> To take consistency to its logical end, the ARIA semantic default from 
> the table might be considered the "missing-value-default" found in other 
> HTML attributes. Is there something I'm missing that makes this Not A 
> Good Idea?

You'll notice that most missing value defaults, at least for the global 
attributes that might get copied-and-pasted around more, are not in fact 
valid keywords.


> To get down to specifics, I'd expect:
> 
> <nav>
> <nav role>
> <nav role="navigation">
> 
> to be identical in the spec's eyes, excepting the first being the preferred (but not required) form.

The processing model for role="" is defined in the ARIA specs, so whether 
the second and third examples above mean the same is up to that spec. The 
default is up to the HTML spec. However, what we're discussing here is not 
what it means, but whether it should be allowed.


> > For example, expert A writes a Web page with some redundant roles, 
> > author B copies markup from that page and changes it to suit their 
> > needs, but ignores the previously "redundant" bits and thus ends up 
> > with conflicting information instead of redundant information. Page 
> > ends up being sub-optimally accessible, because the previously 
> > "redundant" accessibility annotations now conflict with the page's 
> > real semantics, and are wrong.
> 
> I don't see how this differs materially from someone copying a batch of 
> code with valid ARIA markup in place, and changing it so the content is 
> at odds with the valid "non-redundant" ARIA markup. And, in fact, 
> allowing the author to specify the default would preserve ARIA in 
> cargo-culted code if the elements themselves get changed to, say, 
> <div>'s.

I'm not sure I understand what you mean. Can you give an example?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'