- 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>
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:50 UTC