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

[Steve Faulkner]

Hi Ian,
you wrote:

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

that has nothing to do with it being redundant, it's to do with people
copying and pasting code, the same issue would occur for many other
attributes. That's why we have conformance checkers to pick up such issues
where they cause harm. If the role and the input type do not match the role
is no longer redundant, so you did not answer the question.


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

again you have changed the element so it is no longer redundant (not that
<nav role=navigation"> is redundant in this case as IE and other browsers
have not implemented the mapping and are unlikely in IE's case to in the
foreseeable future due to constraints in their accessibility APIs)

So it would appear you have no examples of when a redundant role causes
harm. Do you have any example where using a role that matches the implied
default role causes harm?

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

I would agree with you, except there has been no indication from browser
vendors (to my knowledge) that they intend to fix this issue. If you know
otherwise please share the good news. Until such times as we do have such a
commitment from vendors, the conformance requirements in the spec should
reflect not what we would like to happen, but what is required to get the
feature to work.


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


the following input (gmail search box) uses aria-haspopup=true

<input type="text" value="" autocomplete="off" name="q" class="gbqfif"
id="gbqfq" *aria-haspopup="true"* style="border: medium none; padding: 0px;
margin: 0px; height: auto; width: 100%; background:
url("data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw%3D%3D")
repeat scroll 0% 0% transparent; position: absolute; z-index: 6; left:
0px;" dir="ltr" spellcheck="false">


the following link (from the gmail 'more' menu)  use aria-haspopup and
aria-owns

<a aria-owns="gbd" aria-haspopup="true" onclick="gbar.tg(event,this)" href="
http://www.google.com/intl/en/options/" id="gbztm" class="gbgt"><span
class="gbtb2"></span><span class="gbts gbtsa" id="gbztms"><span
id="gbztms1">More</span><span class="gbma"></span></span></a>

the gmail search button  uses aria-label

<button class="gbqfb" aria-label="Google Search" id="gbqfb"><span
class="gbqfi"></span></button>

These are few examples in use, I don't know if you consider them 'valid
use'.

regards
SteveF

On 28 August 2012 23:15, Ian Hickson <ian at hixie.ch> wrote:

> 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.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html