W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: Change proposal for ISSUE-85

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 15 Jun 2010 22:46:05 -0700
Message-ID: <AANLkTinVAIsAEdfRcA95jaGppqbW6tdhSZINCvW0vfZE@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, Sam Ruby <rubys@intertwingly.net>, Steven Faulkner <faulkner.steve@gmail.com>, public-html@w3.org
One thing that would be good to get clarified is how a UA is supposed
to handle <a role=button>.

So far it seems like most of the discussions revolve around what is
valid or not, this question mostly affects validators, but not UAs.
I.e. this is mostly a question of if we recommend such markup or not.
This is arguably a minor issue. The much more, IMHO, important
question is what the UA requirements are with regards to <a
role=button>.

Do we require that UAs ignore the role attribute and tell for example
AT tools that it is a link? Or do we forward the role attribute to AT
APIs?

I think a good argument could be made that if someone has gone through
the trouble to add 'role=button' to an element, then that is likely
the most accurate role. Thus I think a reasonable argument could be
made that we should forward this information to AT users.

/ Jonas


On Tue, Jun 15, 2010 at 9:37 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> Ian and I discussed this topic on IRC and I believe we ended up on roughly the same page about the semantics of buttons and links, how this applies to reddit, and how that is relevant to techniques like javascript: URLs or links with onclick attributes. I see that Ian has updated his Change Proposal, but in case anyone would like to see the discussion, you can see the conversation from 04:33 tp 05:08 here.
>
> http://krijnhoetmer.nl/irc-logs/whatwg/20100616#l-158
>
> Regards,
> Maciej
>
>
> On Jun 15, 2010, at 7:30 PM, Maciej Stachowiak wrote:
>
>>
>> On Jun 15, 2010, at 6:43 PM, Ian Hickson wrote:
>>
>>> 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 href="javascript:..." issue is relevant because it can make the *behavior* like a button, and indeed almost always does.
>>
>>>
>>>
>>>> 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.
>>
>> However, a validator will not flag this error.
>>
>>
>>>> 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>).
>>
>> That seems wrong to me. They both act as links, even though they have an appearance that may resemble buttons. They show a URL in the status bar when hovered, and take the user to that page when clicked, through a straightforward application of <a href>. It seems to me <a> is being used for the intended semantic purpose, even if styled in a superficially button-like way. It is proper for these page elements to show a URL in the status bar, show the link cursor when hovered, and be recognized as links by search engines. It would be semantically inferior to mark them up as <input> or <button> elements, since then the previously mentioned properties would not hold.
>>
>>
>>> The "share" <a> elements below the headlines are links.
>>
>> How are the "share" elements links? They don't have the styling of a button, true, but when clicked they do not perform a navigation, rather they perform a command. It is inappropriate that this element shows a link cursor, shows "#" in the status bar when hovered, and is seen by the search engine as a link, since it does not link to anything.
>>
>> Are you arguing that the semantics of being a button or link are based solely on appearance and not at all on behavior? That does not match my understanding of the word "semantics". I think I may be completely failing to understand what you think makes the semantic distinction between a button and a link. I would appreciate if you could explain it. Perhaps the explanation should go in the Change Proposal.
>>
>>
>>> 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?
>>
>> Native applications using most native accessibility APIs can report anything they like as a button or link.
>>
>>>
>>>
>>>> However, the spec currently makes javascript: URLs conforming.
>>>
>>> The spec doesn't make javascript: URLs conforming.
>>
>> Are you saying that the spec makes javascript: URLs nonconforming, or that there an html document can be in some third state besides "conforming" and "nonconforming"?
>>
>>> 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()).
>>
>> Would you agree that the vast majority of uses are not legitimately a link?
>>
>>> 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.
>>
>>> From your reddit examples, it's clear that your understanding of button and link semantics is not the same as mine. I think it is uncharitable to call either understanding a "misunderstanding" until we are each clear on what the other's understanding is.
>>
>> To be clear: I believe the semantics of a link are that it navigates the user to a different page. The semantics of a button are that it performs a command. Appearance is irrelevant to the semantics. By this understanding, I would draw the exact opposite conclusion on what is or is not a button or link in the reddit examples you gave. I would like to hear how your understanding differs before commenting further.
>>
>> Regards,
>> Maciej
>>
>>
>
>
>
Received on Wednesday, 16 June 2010 05:54:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:18 UTC