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

Hi Ian,

> On Mon, 12 Mar 2012, Charles Pritchard wrote:
> > On 3/12/2012 5:52 PM, Ian Hickson wrote:
> > > On Mon, 12 Mar 2012, Charles Pritchard wrote:
> > > > >
> > > > > Ignore the error, the HTML5 spec does not reflect implementations
> > > > > in this section about ARIA.
> > > > >
> > > > > The warning is not helpful to authors nor does it accurately
> > > > > describe the means in which ATs work with ARIA.
> > >
> > > Are you saying you think the spec is wrong here and we should not
> > > allow role="presentational"? I tend to agree, but I'm not sure it's
> > > worth it to try and work out exactly when role=presentational is
> > > harmful (as in this case) and when it's not.
> >
> > Consider something like CSS ::outside; it's a nice feature, but it's not
> > in many browsers. If it were, it'd make more sense for authors to mark
> > up decorative/presentation text in CSS.
> >
> > Pragmatically authors they have to make decisions, and sometimes that
> > means various techniques with HTML4 and strange mixes of roles.
>
> I don't understand how to interpret your answer with respect to my
> question (and thus whether you think the spec should change, given your
> earlier statement).
>
>
> > > On Mon, 12 Mar 2012, Charles Pritchard wrote:
> > > > > > These should only be warnings, not errors. The language "Authors
> > > > > > must not" is inappropriate.
> > >
> > > Warnings are generally not useful. Either something is fine and we
> > > should support it, or it's wrong and we should alert the author. I
> > > think "must" is very much the appropriate requirement level here.
> >
> > From the implementation-side, the spec is wrong, it ranks native HTML
> > semantics above ARIA DOM semantics.
>
> I do not understand what this means or why it is wrong.
>
>
> > As a "best practices" note, it seems overly optimistic. There are
> > situations with AT navigation where role conflicts do occur and/or
> > redundancy in tagging is helpful.
>
> Can you elaborate on this? Specifically, can you give an example of such a
> case that conflicts with what the spec says?
>
>
> > I don't believe it is appropriate for HTML to place restrictions on ARIA
> > DOM. It's does not reflect implementations. The HTML spec should only
> > specify what the default mappings are for HTML elements to ARIA. Authors
> > may be advised to test AT software with their product.
>
> I don't understand what you mean.
>
>
> > This statement is more in line with practice: "Authors must test
> > accessibility tree as part of development and usage of ARIA semantics.".
>
> We can't really put normative conformance criteria on whether authors test
> or not, that's a bit weird...
>
>
> On Tue, 13 Mar 2012, Charles Pritchard wrote:
> >
> > Some wild guesses:
> > Treating a link as a button or a button as a link.
>
> I agree that allowing a button to be reported as being a link is bad for
> accessibility. The spec currently allows this due to a W3C HTMLWG chair
> decision that I opted not to challenge.
>
>
> > @disabled and aria-disabled may be used via reference with aria-controls.
> > type="range" and role=slider for redundancy.
> > various styling tricks with css selectors.
>
> Can you elaborate on these? In what way do they conflict with HTML?
>
>
> > 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.
>
>
> > Ian has stated that warnings aren't very useful, he's looking for error
> > or bust. That's confusing when it comes to ARIA testing, as it's more
> > about the pragmatic effects of applying semantics and using a variety of
> > ATs to test them.
>
> It's all about the pragmatic effects always. I don't see how this changes
> things here. Maybe we understand the words "error" and "warning" differently?
>
>
> On Tue, 13 Mar 2012, Scott Gonz�lez wrote:
> >
> > It's my understanding that authors should only apply ARIA via script.
> > The redundancy cases seem to be the most reasonable use cases I've heard
> > of for wanting ARIA in the initial markup, but even that seems wrong.
> > What happens when you have type=range and role=slider, the UA doesn't
> > understand the new types, and the script either never loads or has an
> > error? The AT will pick up the role, but none of the functionality will
> > be there. I don't see how that's better than not having the role
> > applied.
>
> ARIA doesn't have to be specified only from script, but if specified it
> should only be specified for things where the browser can't do a better
> job itself. So there's no point putting it on an <input> element,
> typically. 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.)
>
> On Tue, 13 Mar 2012, Kornel Lesi�~Dski wrote:
> > On Tue, 13 Mar 2012 15:57:57 -0000, Hugh Guiney <hugh.guiney@gmail.com <hugh.guiney@gmail.com?Subject=Re%3A%20%5Bwhatwg%5D%20Validator.nu%3A%20%22Attribute%20role%20not%20allowed%20on%20element%20%20h2%20at%20this%20point.%22&In-Reply-To=%253CPine.LNX.4.64.1206082227150.378%40ps20323.dreamhostps.com%253E&References=%253CPine.LNX.4.64.1206082227150.378%40ps20323.dreamhostps.com%253E>> wrote:
> > >
> > > I am using it because VoiceOver does not understand <hgroup>/document
> > > outlines yet, and so announces two headings when there should only be
> > > one. It is not ideal markup; I'm merely trying to provide a better
> > > experience for AT users until new elements and parsing models are
> > > understood.
> >
> > Dusting off <hsub> proposal, which doesn't have that problem:
> >
> > http://www.w3.org/html/wg/wiki/ChangeProposals/hSub
>
> The benefits seem minor and insufficient to overcome the disadvantage of
> changing the spec again on this front, so I haven't adopted <hsub>.
>
>
>
You wote:

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

for example:

<nav role="navigation>

Under what circumstances can this example lead to  'conflicting
information'?

Note:  this example is not currently redundant in all browsers as the
mapping is not implemented in some browsers.

or this example

<button role="button">

Note: I am not advocating the unecessary addition of redundant roles, but
would like to understand circumstances where this would cause practical
harm, rather than just being unecessary.

you wrote:

ARIA doesn't have to be specified only from script, but if specified it
> should only be specified for things where the browser can't do a better
> job itself. So there's no point putting it on an <input> element,
> typically. 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?

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

Received on Sunday, 10 June 2012 09:18:08 UTC