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

[Benjamin Hawkes-Lewis]

On Wed, Aug 29, 2012 at 7:14 PM, Steve Faulkner
<faulkner.steve at gmail.com> wrote:
> 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.

We have linters to help authors catch interoperability issues, but
especially as most authors aren't going to use a linter, they are no
substitute for designing the language so as to minimise author errors
that reduce interoperability.

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

[snip]

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

I think you're missing Ian's point. Authors copy-paste markup from
deployed corpus. If linters throwing warnings/errors about "redundant"
markup caused authors to remove it, that would reduce the amount of
"redundant" markup in the corpus. Consequently, there would be fewer
copy-paste errors involving misunderstandings of the "redundant"
markup. The harm caused by "using a role that matches the implied
default role" is the proliferation of markup likely to result in
copy-paste errors.

Having said that, I don't buy Ian's argument because:

1. Informed authors are unlikely to reduce their own content's
interoperability (backwards compatibility with today's client software
that doesn't expose implicit semantics) in favor of making it easier
for other authors to copy-paste their markup without errors. Assuming
the linter gives accurate information about markup interoperability,
such warnings/errors are unlikely to result in authors removing
"redundant" markup. So an important effect of emitting these
warnings/errors is to decrease the linter's signal-to-noise ratio.

2. Linter behaviour aside, I suspect more content will be enriched
with "redundant" ARIA markup than broken by copy-paste errors involved
in said markup.

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

I don't recall a statement from Microsoft that they are not planning
to expose implicit native semantics (e.g. expose ariaRole of
"navigation" for <nav>). Do you have a reference for this? It casts
yet another question mark over the ongoing standardisation process for
ARIA, as exposing implicit native semantics is an ARIA requirement.

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

So long as we're talking about "redundant" ARIA markup motivated by
implementations not exposing implicit native semantics, the Living
Standard is trying to describe the behaviour on which implementations
on converging, not what implementations do today. For client software
implementors, what matters is implementor intention, not current
browser behaviour.

However, useful linter behavior needs to be predicated on current
browser behavior, because that's what authors care about. So I agree
that Living Standard requirements for conformance checkers should be
relaxed to take account of current browser behavior.

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

What most authors want out of conformance checking is not "authoring
styles" but interoperability, and they will need to keep using
"redundant" markup to achieve that.

Having said that there's no reason a linter couldn't provide "info"
messages as well as "warning" and "error" messages to alert authors to
language features that might be usable one day …

--
Benjamin Hawkes-Lewis