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

Hi Ian,

On 10 June 2012 10:16, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> 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?
>
>
>  <http://www.paciellogroup.com/resources/wat-ie-about.html>
>

further comment on the incorrectness of your statement:

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


-- 
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:26:42 UTC