HTML5 details element, built-in and bolt-on accessibility

Now that the HTML5 spec is settling down, we’re seeing a resurgance of people attempting to cut good bits out. One of the latest targets is the very useful details element. This is an expanding and contracting element that you can use to “hide” more details without JavaScript. It’s not supported anywhere yet, but my glamorous co-author Remy cleverly fakes it on his 2010 Full Frontal conference page. His code is


 <details>
  <summary>Get in touch</summary>
  <p>Interested in sponsoring? Get in touch.</p>
 </details>

If you click on the text inside the summary element (which defaults to the text “details” if absent), the details element expands. Click again, and it contracts.

Anyway, the argument against this element is that it duplicates what you can do already with a div, some JavaScript and some WAI-ARIA information to add role and state information to this widget. That’s true, but it completely misses the point that one of the reasons HTML5 is so interesting to developers is precisely because it greatly simplifies web development, meaning you don’t have to muck around with script and ARIA.

The new HTML5 forms UI widgets and validation (supported in Opera), for example, are entirely superfluous, you could argue, because you can do the same in JavaScript. Why have built-in sliders for input type=range or input type=date or even good old fashioned textarea when you could have one single input element and script everything else?

The answer is because it’s much more hassle to pull in script and keep role and state info with ARIA. It’s much better to build these things into the language, with built-in accessibility because the browser vendors bake in role and state information and hook up the widgets to the operating system.

Expecting developers to reinvent this wheel every time is “bolt-on” accessibility, and we all know that they won’t actually do it. Yes, they can use a library. I’ve seen the whole jQuery library pulled in just to make an expando box behave like details.

I refer you to John Foliot, whose email to the HTML Working Group makes an excellent argument that explains the subject much better than I can. I should add that Foliot is by no means an HTML5 cheerleader and is a great advocate of accessibility and ARIA. His main points are

I recommend you read the whole email and his blogpost Thoughts on <details> versus @summary .

Added June 2011: Implementing HTML5 <details>.

48 Responses to “ HTML5 details element, built-in and bolt-on accessibility ”

Comment by Shelley

You and John have both given bullet points, such as elements are better than attributes, but you haven’t said why.

Why? Considering the attributes exist anyway, why is encapsulating a dynamic behavior in Details better than using JavaScript. And what should happen with Details, when JS is turned off? Or it’s used in a print context?

You also don’t cover the costs associated with new elements. Do you consider it negligible?

Regardless, I hope you submit your post as a counter-proposal to the W3C. You don’t have to be a member.

Comment by Bruce

Shelley asked:

“what should happen with Details, when JS is turned off? Or it’s used in a print context?”

Details should still work if JavaScript is off, just as new html5 form validation does. Or just as clicking on a form label passes focus to its associated form control. Why would it behave differently? The whole point is to build these common widgets into the browser so as not to require scripting.

In a print environment, I would imagine that it would be auto-expanded. I asked Hixie, who disagreed; he suggested that if the details element were open at the time the print button is pressed (whether by user activation or by default) then the contents would be printed, otherwise not.

I don’t know what the better alternative is. I don’t know what a print environment should do if you press print while a video is playing (show the poster/ first frame/ current frame?).

However, that doesn’t seem to me a reason to remove details from the spec.

Comment by patrick h. lauke

personally, i don’t like this because it’s so strangely specific to one single effect. why not define another element for an accordion menu? and another one for a dropdown menu? or an image carousel?
it seems arbitrary that the spec should have a baked-in effect like this little expando-thing…unless i’m missing the point completely…

Comment by Shelley

Bruce, these questions have to be answered before introducing declaractive elements into production use. We can’t toss the elements up and say, well we’re about these issue later.

In current applications is JS is turned off, collapsed sections should be displayed by default. People are used to this now. What happens when we start to introduce inconsistent behaviors?

As for the print, typically printed pages are either printed with a separate CSS, whereby everything is open by default, or, at a minimum, jS is turned off. The details element operates outside of this normal, standard web environment.

What does it add that makes up for the problems it will cause. What does it enable, to compensate for the unresolved issues?

And your bullet list — what is the reason for each item. They’re a statement of fact, but what is the background to justify them being considered as facts?

Comment by Shelley

I hate comment boxes and GMail. Typo city.

Should say:

“We can’t toss the elements up and say, well we’ll worry about these issue later. “

Comment by John Foliot

I should add that Foliot is by no means an HTML5 cheerleader…

Hey Bruce, that’s not quite true, nor fair. I am a huge fan and supporter of HTML5, as it will, when done, advance web accessibility significantly. I stand diligent however to ensure that we do the very best we can do, as we craft this next generation mark-up language, to ensure that accessibility remains a big winner.

Shelley Powers wants to know why elements are better than attributes. I did respond to that question in an email to the HTML WG Mailing List, but it seems she doesn’t want to hear (or doesn’t like) the answer.

In HTML (and XML) elements are the basic building blocks of our DOM structure. Elements are clearly defined and easily processed by parsing agents. We can extend properties to these basic building blocks using attributes, but be very clear, attributes are *additional* properties added to a basic element, and extending those additional properties requires both additional code, and additional effort on the part of the author. Demanding that authors add additional code to any element to ensure that it ‘becomes’ accessible is problematic, as any author who fails to add these extra properties (either through negligence or ignorance) has now created a ‘thing’ that is not accessible. This is the ‘bolt-on’ approach to accessibility that the accessibility community has been working to eliminate for years. (Yes, ARIA is itself a bolt-on solution, but that’s simply because it was designed as a retro-fit solution. Given the choice between bolting on accessibility, or having none, the choice is clear. However ARIA is not optimal for the very reason that it *is* bolt-on, and if we can do better this time, we should.)

Having an element that has explicit rules for processing, including the accessibility requirements, ensures that when the author uses said element, the accessibility comes as part of the element, no additional effort required. Identifying common, repeated patterns in existing markup (as HTML5 has done) and taking common attributes from these patterns to create new elements is an efficient choice, as we can now also ensure that these elements are accessible ‘out of the box’ as well. As I explained to Shelley in that subsequent email, we can certainly perpetuate a pattern that reads or we can admit that eventually we need a new element: . I ask you, which makes more sense, which is easier to author, and which would *you* rather use? Arguing that we continue to use from here on in is inefficient, short sighted and sub-optimal, as it leaves open the possibility of authors simply creating (which would be accurate, but incomplete).

I want to be very clear; ARIA is extremely useful and should hold an important place in the hierarchy of the HTML5 stack. At the same time however, every move we can make to reduce the need for ARIA by shifting the accessibility bits higher up that stack is a move we should embrace fully today. I cannot fathom arguing to maintain the status quo, when we can do better moving forward.

(And as for how the details element *should* be rendered in print? Why, use a print style sheet of course! Perhaps you might want to style the details element as a footnote: http://www.w3.org/TR/css3-gcpm/#turning – again, elements are also easeir to work with when styling or scripting:

details {
float: footnote;
}

…seems pretty obvious to me.)

Comment by John Foliot

(Grrr… trying this again)

Having an element that has explicit rules for processing, including the accessibility requirements, ensures that when the author uses said element, the accessibility comes as part of the element, no additional effort required. Identifying common, repeated patterns in existing markup (as HTML5 has done) and taking common attributes from these patterns to create new elements is an efficient choice, as we can now also ensure that these elements are accessible ‘out of the box’ as well. As I explained to Shelley in that subsequent email, while we can certainly perpetuate a pattern that reads <hole-in-a-wall class=”window”> or we can admit that eventually we need a new element: <window>. I ask you, which makes more sense, which is easier to author, and which would *you* rather use? Arguing that we continue to use <hole-in-a-wall class=”window”> from here on in is inefficient, short sighted and sub-optimal, as it leaves open the possibility of authors simply creating <hole-in-a-wall> (which would be accurate, but incomplete).

Comment by Bruce

Sorry if I misrepresented you John. Serves me right for trying an American metaphor. I thought saying you weren’t a “cheerleader” means that you’re not an uncritical supporter, eg not someone paid to rouse the troops and shout hurrah regardless of the quality of the gameplay.

So you’re not like this sad deluded cheerleading fool.

Comment by Shelley

John, what makes you think it’s easier for a developer or designer to have to create an element than it is to create an attribute.

If you use the DOM, to add or remove an attribute is one function call. To add or remove an element is, at a minimum, three lines of code. Or more. Where did people get the impression that elements are somehow easier than attributes?

As for ARIA and the “stop gap” attitude about it, when you get all browsers and other user agents to support something like aria-hidden, then you can use aria-hidden in many widgets. When you package widget behavior, you then have to go out and advocate accessibility for _each and every widget.

Example: input type=datetime is implemented in Opera. But it’s not implemented accessibly. And you can’t style the calendar that pops up, because _it is not part of the DOM.

Yet alternatives available now are accessible, and can be styled and customized.

Patrick also has a very pertinent point: why details? Why not tabbed pages, and accordion, and any of the other dozens, hundreds of widgets?

Even if these items become available in browsers, are they available in the HTML editors? The WYSIWYG
editors? The lint tools, such as HTML Tidy? No, and there’s a darn good chance they may not, either. Many of the developers of these tools do not like HTML5. They feel it’s sloppy and introduces conflict, as well as applying arbitrary and difficult to implement conformance rules. Many feel they’ve been ignored by the browser companies.

Regardless, I’d rather see this discussion energy directed towards write ups in the HTML WG that I can respond to once, rather than by bits and pieces and Twitter and comments here and there.

I’m also getting a little tired of the personal attacks against me, because I do disagree with the inclusion of these elements. I’ve had my arguments called “tripe”, and been accused of being “awful” to members of the accessibility community _just_ because I disagree.

Comment by Bruce

” input type=datetime is implemented in Opera. But it’s not implemented accessibly.”

true enough; it’s an experimental implementation and I’ve got bugs filed to make the date picker keyboard accessible.

“And you can’t style the calendar that pops up, because _it is not part of the DOM.”

Perhaps true. Note that you can style CSS generated content, which also isn’t in the DOM, because you can pinpoint it with a selector. There aren’t CSS selectors yet for calendar widgets, although I’d expect the Basic UI module to be extended for these purposes (and sliders etc).

“Even if these items become available in browsers, are they available in the HTML editors? The WYSIWYG editors? The lint tools, such as HTML Tidy? No, and there’s a darn good chance they may not, either. Many of the developers of these tools do not like HTML5.”

If WYSIWYG editor X doesn’t allow authoring of certain elements while WYSIWYG editor Y does, I imagine that editor X will lose customers pretty quickly. But that’s a perfectly legitimate choice for the developer to make.

“I’d rather see this discussion energy directed towards write ups in the HTML WG that I can respond to once.”

I quite like blogging about stuff I choose to.

“I’m also getting a little tired of the personal attacks against me.”

You won’t find any of those here, Shelley. I didn’t name you as one of the people trying to take details away, as I wanted to focus on the arguments not the people.

Comment by John Foliot

1) Shelley Powers has put forth a *Change* Proposal – it is incumbent on her to build support behind this requested change; it is foolish to suggest that others must put forth other Change Proposals to counter her proposal. To be clear, myself personally, I don’t want any change, so there really should be nothing I need do.

2) Shelley asks:

…what makes you think it’s easier for a developer or designer to have to create an element than it is to create an attribute.

I didn’t say that. However, it’s very basic: attributes are children of elements; you can have an element without any attributes, but you cannot have an attribute without any element. *I* want baked in accessibility without the need of attributes whenever possible, because if you rely exclusively on attributes to extend accessibility, there remains a chance that the attribute will not be added – a point of failure we should be able to address.

3) Shelley seems aghast and surprised that ARIA is a stop-gap solution (albeit one that is actually getting some traction – hurrah). Yet, if you’ve spent any time working in the field of web accessibility, you would know that this ‘stop-gap’ approach was by design:

Up to now, the roadmap has addressed current (X)HTML markup as supported by today’s desktop browsers using ARIA. The markup in today’s browsers, like accessibility, requires developers to do things manually through the use of JavaScript. While this is extremely flexible, it suffers from a number of problems:

Although improvements have occurred, JavaScript does not behave the same on all browsers and platforms.
Data models are inconsistent.
Accessibility is bolted on, rather than being built in.
Accessibility solutions remain more device-dependent than they should be.
Heavy accessibility lifting is done by the author in line with the way JavaScript is used.

Through the use of declarative markup and tight integration of accessibility into the application framework, we can produce more consistent cross-platform solutions which support accessibility and reduce the enablement efforts of the author.

http://www.w3.org/TR/wai-aria-roadmap/

4) Shelley also states:

Many of the developers of these (authoring) tools do not like HTML5. They feel it’s sloppy and introduces conflict, as well as applying arbitrary and difficult to implement conformance rules. Many feel they’ve been ignored by the browser companies.

Many? I know of one (Vlad Alexander of XStandard), but can Shelley point us to other editor developers who share Vlad’s perspective? There are numerous standalone editors out there, including very large tool-sets such as the Creative Suite from Adobe, which includes an industry staple: DreamWeaver (how do they feel?), as well as some very well known plug-in WYSIWYG editors (TinyMCE, CKEditor, etc.) – I am unaware of their “concerns”, but look forward to hearing them as part of any dialog.

5) Dialog *has* happened on the HTML WG Mailing List, and to date it has generally not found a lot of support for Shelley’s Proposal. That she is frustrated about this I can understand, but her Change Proposal was put forth with little consultation of the larger Working Group, and in particular with the Accessibility Task Force set up to work on accessibility issues within the emergent HTML5 specification. As she is requesting a change that runs counter to the work and efforts of the WAI over the past decade (vis-a-vis “bolt-on” solutions), it really should not be surprising that there is little interest from that quarter.

6) I personally have discussed this with Shelley in a number of fora, and have striven to remain professional and to not make this personal. If at any time it has appeared otherwise, I will publicly apologize for that, as it is neither my intent nor desire. However, I remain adamant that Shelley’s proposals introduce potential failure points w.r.t. accessibility, and I cannot in good faith support them.

Comment by Cheryl D Wise

Re: what will web editor creators like Adobe (Dreamweaver) and Microsoft (Expression Web) do with HTML 5?

In my experience as an Adobe Community Expert and Microsoft MVP they will add the new elements to the next version of their editors when either the specification became a published recommendation or there is substantial browser support.

Fortunately both of those programs are extensible and people can add support even before the program’s developers do. So folks won’t have to wait to implement HTML 5 of they do not want to do so. That’s how support for php first appeared in Dreamweaver for example.

What other smaller companies do depends on then market but both Abode and Microsoft have government agencies as major clients so anything that helps create accessible code will be something they will want to implement sooner rather than later.

Comment by Bruce

interesting post, Shelley. I disagree (for the same reasons as are discussed above so no-one benefits from rehearsing the arguments).

By the way, for the datepicker widget, I find input {font-size:2em;} acts upon the font. Setting colours is less simple; I have numerous bugs filed in Opera about these; I hope we’ll see these addressed in forthcoming releases (as Opera 10.50 removed the hardcoded icons for type=email and type=url after Pat Lauke and I showed why they were horrible)

Comment by John Foliot

A few thoughts more: many of the new elements in HTML5 aren’t yet perfectly rendered across all browsers – HTML5 being very much a work in progress. However, using Shelley’s justifications, we might as well also drop <video> and <canvas> too, as a) neither are accessible *today*, b) we can already do these things using other common and hugely deployed tools in hand today (yes, I mean Flash).

(And for those of you that go, but, but… it’s essentially the same argument on why I prefer not to use scripting to supply accessibility – there is too much overhead and many just shy away)

I also find it interesting that Shelley’s original proposals centered so heavily on accessibility, yet when holes were punched in that argument she heads of to find more. Now it just sort of looks like “I don’t like them, and I’ll just keep poking until I can find a reason to kill them”

I humbly suggest that rather than eliminate great ideas based on incomplete implementation today, that efforts would be better focused on identifying current and existing issues and working towards getting them fixed (as Bruce and Patrick Lauke are doing at Opera). In this regard, the note quoted in Shelley’s latest post from Doug Sheppers (W3C CSS WG) about looking to ensure that CSS is properly extended to these new elements is a far more productive path forward. Take the win we get from more semantic elements (and their baked in accessibility) and make them “world class” w.r.t. CSS and scripting.

We all benefit in the end.

Comment by Shelley

Notice in my post that I’m focusing on specifics.

Not generalities. Specifics. And you’re welcome to respond in the email list with specifics. Bruce, you can respond via link in the bottom of the archive page if you’re not a member.

http://lists.w3.org/Archives/Public/public-html/2010Apr/0157.html

You can also provide a counter-proposal, I believe, even if you’re not a member. Check with the co-chairs on that one.

John, I listed several very specific issues related to the built in elements versus either using existing elements (such as a div and img for figure) or using a script library (for progress). You might want to use that as a basis to respond.

Or you can also write a counter proposal, since the chairs have called for these now. Or not, your choice.

As for why my original reasons for focusing on accessibility, I answered that: because that was that rationale given by the editor, and the only rationale given by the editor.

Perhaps you didn’t read my response to Jonas that included this explanation.

Comment by John Foliot

Specifically: Shelley’s proposals are bad for accessibility, as it/they perpetuates the ‘bolt-on’ philosophy to access, by suggesting that authors can use ARIA to add the accessibility bits to their code-base – bits that are not natively present. When authors don’t (by design or accident) we have a failure, and there is very little we can do about it: it is a failure of the author, not the technology.

Creating stand-alone elements that have specific accessibility hooks/semantics integrated directly within them ensures that accessibility is bound directly to those elements, not added to after-the-fact. Authors need only use the appropriate element, and the AT and User-Agent work seamlessly to ensure access: if it isn’t perfect today (for example, poor CSS support), that can (and should) be worked on – it should *not* be a reason to abandon this approach.

Specifically, this kind of behavior has been requested and advocated for since at least 2007, by the highest ranking advisory committee within the W3C’s Accessibility Working Group (the PFWG – Protocls and Formats Working Group): http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html (so it’s not just John that is saying this, it is, in fact, the current consensus position within the WAI community of experts, including those who actually developed ARIA in the first place – who else but they would be more aware of the shortcomings of what they wrought?)

Specifically, most content authors I’ve spoken to about this are in agreement that this both makes sense, and is efficient and useful moving forward (as opposed to remaining stuck in 2010 solutions). Not a single one of them has expressed concerns about ‘cost’.

Intentionally or otherwise, Shelley your proposals specifically shackle accessibility advances, and should not be considered for *THAT REASON ALONE*.

I am aware of some counter-proposals coming forth soon, and will watch to see what happens there. I have all of April to decide if another counter-proposal is in fact required. There is also the CfC (Call for Consensus) process, which must be followed whether or not alternate proposals or counter-proposals emerge, and if the CfC is tight, a vote might also be considered as well.

Comment by Bruce

Thanks Shelley

as you’re proposing a change, do counter-proposals need to be written? eg, do I have to propose we keep the status quo? (I’m unsure of procedure)

Comment by Shelley

John, you seem to believe that if these elements are released, developers will immediately flock to their use. I find it unlikely that most will be used. They are inferior to what we have, and most developers won’t use an inferior product.

Seriously, no one is going to use hidden. “Material that isn’t relevant” What an inane and vague description. And it’s the exact same thing as aria-hidden…except there’s nothing about its accessibility in the HTML5 spec. Nope, not a thing.

Then there’s the progress element that differs across platforms, and even browsers. Oh, and it can’t be styled. Yup, that one will go over well. But better than meter, who know has a clue what it’s about.

But there’s something else about them — there’s nothing in the spec about how they map to the accessibility APIs. Nope, not a thing. You all will have to negotiate with each and every browser to get this. You’ll have to file bugs, and pester. Why? Because it’s not accessible.

I could go on, but I’m tired of talking to air.

I would think a better use of time for accessibility is stop referring to ARIA as a “bridge”, a “stop gap”, or “bolt on”, because all you do is give developers the idea that, what the hell, maybe we shouldn’t add ARIA to our libraries and applications.

After all, the accessibility folks don’t seem to believe in it.

That’s the message being sent. That’s what we’re hearing.
Bruce, yes, you have to propose a counter-proposal. Several people are working together as a team, maybe you can join them?

Joke: How many WhatWG members does it take to counter my change proposals? Evidently quite a few.

Well, I thought it was funny…

Comment by Shelley

And this should be worth a glance for you John — Webkit folk desperately trying to implement accessibility into the progress element, making up roles as they go. This ought to go well.

http://bit.ly/dciTMl

Oh, yes. Yes indeed. Really superior option.

Comment by Bruce

Shelley said

“I would think a better use of time for accessibility is stop referring to ARIA as a “bridge”, a “stop gap”, or “bolt on””

No. It’s right to describe it as what it is. And that’s why we need to ensure that HTML5 has these things baked in rather than trying to block them.

Built-in trumps bolt-on. Always.

Comment by John Foliot

I take exception to Shelley’s comment, as it completely ignores history and the actual design intent of ARIA, which was developed (starting close to a decade ago) to retro-fit content that was inaccessible for a variety of reasons. As a retro-fit solution, it is *very* clever and well done, but as it still requires additional effort and code on the part of the author, it is less optimal than using specific native elements which require no additional effort on the author’s part to convey meaning; for example <button> (see how you know what that is, no ARIA required?) Even the W3C admits that using ARIA, while strongly recommended, adds to the developer’s workload:

Including WAI-ARIA support does require a little extra effort, yet it is not significantly more than usual development. For those developing static Web pages or using libraries with WAI-ARIA built in, implementing WAI-ARIA is fairly straightforward. Developing custom, cross-browser JavaScript widgets is more complex, and implementing WAI-ARIA in these is proportionally more complex. http://www.w3.org/WAI/aria/faq

It is less than helpful to the accessibility cause to have late-comers show up and start telling those who have worked in the field for years (including some of the biggest and brightest stars, including Rich Schwerdtfeger (IBM Distinguished engineer), TV Ramen (Google, developer of Emacspeak), James Craig (Apple), and countless others) that they are wrong. Further, to go onto blogs and tell that community that quoting from the ARIA document is inappropriate does the accessibility community a real disservice. Quoting directly from the ARIA Working Draft:

WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. This is important because the invention of new types of objects is faster than standardized support for them appears in page languages.

It is not appropriate to create objects with style and script when the page language does provide semantics for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively.

It is expected that, over time, host languages will evolve to provide semantics for objects that previously could only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature. Legacy content may continue to use WAI-ARIA, however, so the need for user agents to support WAI-ARIA remains. http://www.w3.org/TR/wai-aria/introduction#co-evolution

Frankly Shelley, please stop spreading mis-information; you are helping no-one, and hurting the web accessibility cause simply to drive your own political agenda. If you believe that the ARIA Working Draft is incorrect, you might still be able to provide your feedback, although the deadline for submissions to the Protocols and Formats Working Group at the W3C was February 2, 2010. It’s really too bad your interest and knowlege in ARIA doesn’t go back that far, as if your observations were valid, they could have been addressed prior to that date in the appropriate forum.

Comment by Bruce

Useful write up by Steve Faulkner on those bits of ARIA which are not “built in” to HTML5 http://www.paciellogroup.com/blog/?p=585

People should realise that the two technologies are complementary. When accessibility can be baked in to a language, it should be. But when what you want to do cannot be easily made accessible in a host language, ARIA is your friend.

Simple.

Comment by Shelley

And as Steve pointed out in his writing, just because it’s built in doesn’t mean people will use it. The issue isn’t about accessibility, it’s about whether it’s better to have native elements or use other technologies to create the functionality. In particular, when the native elements are demonstratively inferior, and have a heavy cost to tool builders, are they really the better option?

John, I’ve been in the development community for 25 years, and one thing I know: given two options, we won’t pick the inferior one.

Comment by Cheryl D Wise

I’ve been creating websites since 1993 and teaching people how to create sites since 1998. It is so much easier to teach people to use native elements than to get them to add ARIA to add in accessiblity when they want bells & whistles.

Comment by John Foliot

Yes Shelley, we can all see how <button> is inferior to this:

<DIV id=:rk class=”J-K-I J-J5-Ji L3 J-K-I-JO” tabIndex=0
unselectable=”on” closure_hashCode_l16mgm=”182″ act=””>
<DIV class=”J-J5-Ji J-K-I-Kv-H” unselectable=”on”>
<DIV class=”J-J5-Ji J-K-I-J6-H” unselectable=”on”>
<DIV class=J-K-I-KC unselectable=”on”>
<DIV class=J-K-I-K9-KP unselectable=”on”> </DIV>
<DIV class=J-K-I-Jz unselectable=”on”>Search Mail</DIV>
</DIV></DIV></DIV></DIV>

(Source: http://www.paciellogroup.com/blog/?p=585, taken from Gmail)

And that superior choice of code? Ooops… they forgot to bolt on the ARIA stuff, so guess what? Inaccessible.

Please, stop spreading your FUD. You are right, the issues *is* “…about whether it’s better to have native elements or use other technologies to create the functionality…” and many of us are tired of you telling the world that a retrofit is better than a fresh start. The accessibility experts community believes that semantic elements are better (not just me), the majority of the browser manufacturers and WHAT WG members believe they are better, and through-out this entire time, I’ve not heard, read or seen *anyone* support your proposals or perspective. I know that this bothers you, but at some point, you need to give it up and listen to the crowd, or remain bitter and frustrated.

Bruce, sorry to monopolize your blog here. I don’t believe there is anything more I can contribute to this discussion – I leave it to your readers to form thier own intelligent and informed decisions, and hope that the links I have previously provided help them in their research. I am bowing out now – thanks for the opportunity.

Comment by Bruce

Shelley, I don’t think I’ve said anything about your having an agenda. (I’d be grateful if you could supply me with a link to my saying that, as the context might remind me).

If you don’t know what your agenda is, how am I expected to know?

Comment by Benoit Piette

Looking at the example :

<details>
<summary>Get in touch</summary>
<p>Interested in sponsoring? Get in touch.</p>
</details>

Details… details of what? p is the details.
Summary… summary of what, the details?, but is a child of details,
A summary of a table I can buy, but a summary of a detail?
English is not my first language, but am I the only one to think this is weird semantics?

I’d rather have something like this

<section id =”mysection”>
<h1>section title </h1>
<p>Default stuff</p>
<p detailsOf=”mysection”>
The details
</p>
</section>

Think of something similar to label input relationship. But this looks like a reverse longdesc so I am not sure this is a good idea either.

It is that HTML already has the necessary semantics to define a details relationship.
I fear that the details element is only a bolt on element to add default behaviour for a something / details relationship. Isn’t that the job of JavaScript? It is like if we would add an ul element because we need indentation (not because we need an unordered list). IMHO this is wrong and ugly.

What if semantically speaking I define some content to be the details of some other content, but don’t want the default behaviour (show hide). What will happen? What’s the impact on accessibility? I really don’t like this.

Do we really want/need a “clickToShow” element? That’s what details looks like to me. Like it or not, that’s its primary function. That is how people will understand it. I don’t think this is good for accessibility in the long run.

Comment by Bruce

Hi Benoit

I agree with you that the element name “summary” is confusing. I wanted “rubric”, but I’m not entirely sure that’s right.

Comment by Thierry Koblentz

Very interesting read.
At first, I thought this was a no brainer, but I must admit Shelley made a few good points.

I don’t think authors go for “superior” solutions though, imho they go for whatever gives them more freedom (room for customization). I’d say the gmail “button” is a good example of that.

If native elements come with unwanted behavior/styling, developers will prefer to go with junk markup if that gives them more power. And *that* will hurt Accessibility (imho).

So on one hand there is the risk that some authors won’t bother using ARIA, and on the other hand there is the risk that these native elements will not be used at all because they come with some string attached to them.

What if these native elements came with an attribute that would let authors turn off their native behavior/styling? Something the end user could switch back on if he wanted to (i.e., via UA’s preferences).

Comment by Rhys

Hi Bruce,

I was wondering if you would know why Im having trouble measuring the height of an element which is wrapped in a parent with hidden overflow (both inside a element)

Pretty standard expand/collapse stuff, but for some reason when its inside a element js (well jQuery.outerHeight fn) only reads the padding not actual height.

Ive created a demo to explain it better, both examples share the same css rules and js enhancement yet the 1st example which uses a tag doesn’t work!

Seems fine on every other browser except chrome (safari is fine), its like theres some strange property chrome applies to a element.

Anyway if you have any thought it would be most appreciated.
http://www.iconinc.com.au/tests/chrome-test-case.html

Comment by Rhys

oh sorry in the comment above I didn’t escape <details> so where it says “a element” it should read “a <details> element”