Re: Change proposal for ISSUE-85

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