- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 16 Jun 2010 01:43:30 +0000 (UTC)
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, Steven Faulkner <faulkner.steve@gmail.com>, public-html@w3.org
On Tue, 15 Jun 2010, Maciej Stachowiak wrote: > > I think Sam's point was this: using href="javascript:" and the style="" > attribute, one can make a link look and act like a button. You can do it with far less -- using just an external style sheet you can turn any link into something having the appearance of a button. > The spec makes this valid No, doing so is invalid. The spec says: # Authors must not use elements, attributes, or attribute values for # purposes other than their appropriate intended semantic purpose. > I the case of href="javascript:..." in particular, it seems to me that > pretty much any time that is present on a link, the link is essentially > acting as a button rather than as a link. Note that in the context of ARIA, we're not talking about whether a link should have been better presented as a button, but about what it should be exposed as in ATs. Consider the links on reddit: http://www.reddit.com/ >From an AT perspective, the "Submit a link" and "Create your own reddit" <a> elements are buttons, and are non-conforming (they should use <input> or <button>). The "share" <a> elements below the headlines are links. The arrow <div>s are buttons (and should probably use <input type=image> for optimal accessibility). It would be wrong to have the "share" links be marked up as buttons using ARIA, because then the ATs would report them as something different than what they actually are. Links and buttons are widgets that form part of platform widget libraries. You don't see native applications reporting link widgets as buttons to ATs. Why would we? > However, the spec currently makes javascript: URLs conforming. The spec doesn't make javascript: URLs conforming. The only author-facing mention of the javascript: scheme is in a non-normative introductory statement that takes no position on the scheme. The UA-facing mentions are all similarly neutral on the scheme and merely explain how the scheme should work for interoperability purposes. One mention even refers to its behaviour as being required merely for historical purposes. Incidentally, the one example mentioning javascript: refers to the resulting UI as a link, not as a button. > On the surface, it seems inconsistent to allow a feature that can be > used in almost no other way than to make a button act as a link, but at > the same time forbid applying ARIA markup to tell AT that it is a > button. The whole point of forbidding the misuse of ARIA here is to discourage the use of links as buttons, as described both by the change proposal and by the text of the spec, which explicitly encourages validators to say this. It even uses the link/button case as the explicit example: # Conformance checkers are encouraged to phrase errors such that authors # are encouraged to use more appropriate elements rather than remove # accessibility annotations. For example, if an a element is marked as # having the button role, a conformance checker could say "Either a button # element or an input element is required when using the button role" # rather than "The button role cannot be used with a elements". > I must admit I personally hadn't thought about this issue in evaluating > the ARIA roles allowed by the HTML5 spec. It seems like consistency > would call for either disallowing links to javascript: URLs (or likewise > links to href="#" with mouse event handlers), or allowing such links to > carry role="button". I don't have a strong opinion on this issue, but > there is a good argument to be made that the current spec is > inconsistent. As far as I can tell the spec is consistent here. Note that it is possible to use javascript: and <a> for what is legitimately a link (e.g. trivially using window.open()). It's unclear to me how to update my change proposal with the above. The arguments above are arguing against a misunderstanding of the current spec. Does this e-mail correct the misunderstandings sufficiently that the chairs will base their decisions on a correct understanding of the spec, or should the change proposal be updated to also argue against these misunderstandings? I don't really understand the right way to proceed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 16 June 2010 01:44:26 UTC