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

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

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