- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Wed, 29 Aug 2012 21:10:46 +0100
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: whatwg <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Arlen Walker <arlen.walker@gmail.com>
On Wed, Aug 29, 2012 at 7:14 PM, Steve Faulkner <faulkner.steve@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
Received on Wednesday, 29 August 2012 20:11:34 UTC