W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2009

RE: ARIA roles added to the a element should be conforming in HTML5.

From: Schnabel, Stefan <stefan.schnabel@sap.com>
Date: Thu, 12 Nov 2009 09:34:14 +0100
To: Phil Spencer <phil.spencer@digforfiredmg.co.uk>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Charles McCathieNevile <chaals@opera.com>, Jonas Sicking <jonas@sicking.cc>, Lars Gunther <gunther@keryx.se>, Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
Message-ID: <8EA44C66E2911C4AB21558F4720695DC5D84790B95@DEWDFECCR01.wdf.sap.corp>
That's the real point. Apologies if I was too rude in my mail. All I wanted to say is that 

a) UA's have their own interpretation of what is gracefully accepted and what is not 

and

b) What will be accepted and what not regarding element nesting "fluctuates" a bit between the HTML releases

and

c) consequently, ARIA can act as "glue" here for some scenarios

So, in my opinion, a good start harmonizing this would be a sophisticated built in code check in the UA's (as already performed for well formed XHTML tags in some browsers) that can be executed on request or mandatory (to be discussed).

I know that so many code checkers exist but their existence is not tightly coupled to the development process, still their usage is considered as something "voluntarily" in the web developer scene (I also know that this viewpoint is debatable).

Anyway, still too many browsers consume gracefully what's been written only complaining by leaving out parts of the rendering or silently "allowing" things that are actually not permitted for a given HTML version. That's the real issue and should be addressed. I'm curious how W3C will actively drive this.

- Stefan

-----Original Message-----
From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no] 
Sent: Mittwoch, 11. November 2009 22:21
To: Phil Spencer
Cc: Schnabel, Stefan; Tab Atkins Jr.; John Foliot; Charles McCathieNevile; Jonas Sicking; Lars Gunther; Shelley Powers; HTMLWG WG; W3C WAI-XTECH
Subject: Re: ARIA roles added to the a element should be conforming in HTML5.

Yes, you are right, in HTML 4, an anchor element can only be 
placed WITHIN the H1 element. (Stefan was wrong about this, even 
if he is right that it works technically.) But according to the 
HTML 5 draft (and I believe according to HTML 3.2 as well), you 
can wrap the anchor element AROUND the H1 element, effectively 
making the heading a link (or button).

Leif

Phil Spencer On 09-11-11 18.39:

> It is valid to have a link WITHIN the heading (either all or
> part of it)? e.g.
> 
> <h1>Page about <a href="http://www.google.com">google</a></h1>
> 
> I've just used the W3C validator and it seems fine (xhtml 1.0
> transitional)
> 
> I don't have any issue with this semantically.
> 
> 
> On 11/11/2009 09:07, "Schnabel, Stefan"
> <stefan.schnabel@sap.com> wrote:
> 
>> Sorry guys,
>> 
>> this discussion is a little bit wired and comes far too late.
>> 
>> 
>> Since HTML4 came out it was possible to "sell" a Heading as a
>> link by doing
>> 
>> <A href="someref"><H2> Details Chapter</H2></A>
>> 
>> Why hasn't anybody complained before? Why now for ARIA? I
>> don't understand.
>> 
>> There are SO MANY examples of HTML misuse without ARIA. ARIA
>> is to bridge the gap, not to enlarge it.
>> 
>> Regards Stefan
>> 
>> -----Original Message----- From: wai-xtech-request@w3.org
>> [mailto:wai-xtech-request@w3.org] On Behalf Of Leif Halvard
>> Silli Sent: Dienstag, 10. November 2009 20:38 To: Tab Atkins
>> Jr. Cc: John Foliot; Charles McCathieNevile; Jonas Sicking;
>> Lars Gunther; Shelley Powers; HTMLWG WG; W3C WAI-XTECH 
>> Subject: Re: ARIA roles added to the a element should be
>> conforming in HTML5.
>> 
>> Tab Atkins Jr. On 09-11-10 19.46:
>> 
>>> On Tue, Nov 10, 2009 at 12:34 PM, John Foliot
>>> <jfoliot@stanford.edu> wrote:
>>>> We all can pretty much agree that making an <h1> a
>>>> 'button' doesn't really make a whole lot of semantic
>>>> sense,
>> 
>> [...]
>> 
>> 
>>> Since I brought up that example, that sort of markup
>>> actually isn't a bad idea in my opinion.  Now it would
>>> probably be better done with <details>, but when that
>>> didn't exist a <div><h1/><p/></div> was a good
>>> approximation of the semantics.  In some cases it still
>>> might be better semantically, for example if you were
>>> implementing a tab-based interface in js.
>>> 
>>> *Is* it most helpful to convey to ATs that the heading is a
>>> button in that example?  Are there better ways to do it?
>>> You really can't/shouldn't use an actual <button> in the
>>> example, because it's *not* semantically a button, it's a
>>> heading.  It's only when you bring behavior into the mix
>>> that acquires a slightly different character.
>> 
>> I would think that the reason that you shouldn't use a button
>> is because it isn't a  button because it isn't inside a form.
>> 
>> 
>> Well, it is still a button - even outside a <form>, but a
>> button outside the form element - what use is that? Why
>> doesn't HTML 5 say that it is invalid, like HTML 4 does?
> 
> 
> 
Received on Thursday, 12 November 2009 08:34:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:07 GMT