From HTML WG Wiki
Jump to: navigation, search

Retain several newly-introduced semantic elements, attributes, and controls


Several recent Change Proposals (remove <figure>, remove <aside>, remove <details>, remove hidden="", remove <progress>, and remove <meter>) advocate the removal of new semantic elements, attributes, and controls introduced in HTML5. This zero-edit Change Proposal argues for the retention of these new features. They each provides a semantic, declarative, media-independent way for authors to accomplish an extremely common task, and should be included in the core language.

This Change Proposal is for ISSUE-90 figure, ISSUE-91 aside, ISSUE-93 details, ISSUE-95 hidden, ISSUE-96 progress, and ISSUE-97 meter.


Rationale for <figure>

It is very common for articles to include some content that is important for understanding of the article, but whose actual position in the article is unimportant. (<figure> Solves Real Problems.) The content could be placed inline where it is first talked about, or moved to a footnote section or similar, without changing the meaning or the article. For example, a magazine article discussing a celebrity may have a picture of them with a caption explaining their scandalous appearance. A scientific article may contain a data table supporting some assertion being made in the article. A programming tutorial book may contain a snippet of code demonstrating the concept being taught in that section.

Users interacting visually with the article can easily skip past this content temporarily and avoid interrupting their reading of the main article, and then return to the content to understand it when they feel comfortable. Expressing this semantic directly in markup allows alternative UAs to present their users with the same ability, thus improving Accessibility.

<figure> expresses this semantic, indicating that its contents can be safely skipped over for someone reading the main article in which it is embedded, but are still relevant to the understanding of the article. The <figcaption> element exposes a short description of the <figure>'s content, which may be read out to help a user determine if they wish to look at the content of <figure> now or later.

Rationale for <aside>

Both pages on the web and articles in print often contain information that is tangentially related to a main article, but which is not required to be read in order to understand the main article. This content is often placed off to the side or otherwise separated from the main content, so that users of visual UAs can easily ignore it while reading. For example, an article may contain a "pull quote" - an attractive and eye-catching rendering of an important quote copied from the main content of the article. A blog may contain a "blogroll" or "Quote of the Day", which is not directly relevant to the blog post it appears with.

The <aside> element expresses this semantic directly in the markup, allowing other types of UAs to give their users similar ability to skip over irrelevant content and return to it at their leisure.

Rationale for <details>

The notion of "optional" content that can be skipped over when reading the main content is a useful semantic to express.

This semantic is used in many webpages. For example, forms sometimes contain optional sections that are not necessary to successfully submit the form, but allow you to give extra information. Message boards often have a "spoiler" feature for hiding long sections of content that aren't necessarily useful (such as a long digression proving some point used in an argument) or that readers may want hidden until they choose to view it (such as conversation about a movie or book that concerns important plot details).

The <details> element expresses this semantic, indicating that its contents may be optional or are otherwise suppressed, but may be called up and viewed or interacted with easily. The <summary> element provides a short description of the content within its <details> parent.

Rationale for hidden=""

Authors of web documents and applications often need to temporarily hide certain content from readers and users.

Via a combination of script and CSS, such functionality is possible to build today, and there are hundreds of such implementations extant on the web. It's clear that hidden="" Solves Real Problems.

Attempting to implement such functionality with JavaScript and CSS is fundamentally more difficult and error-prone than hidden="". hidden="" is literally the simplest thing that could possibly work, and thus we Avoid Needless Complexity in its design.

By making it as easy as possible to author, and by defining uniform UA behavior (unlike bolt-on scripts which emulate this functionality), we preserve our Priority of Constituencies.

Bolt-on emulations of hidden="" can fail to correctly hide content in a media-independent way, resulting in a degraded experience for users of aural browsers and other AT tools. hidden="" thus promotes Accessibility more than bolt-on alternatives.

Rationale for <progress>

It is common for webpages to indicate that some task is "in progress", and sometimes to indicate the actual level of progress that has been made. This can appear as a live view of the progress of some short task (uploading a file, for instance), or a more statically updated view of the progress of a longer task (indicating the current amount of donations to some fund, and how close that is to the desired amount, for instance).

The simplest way to indicate this is through simple text ("50% done", "$500 of $2000 raised"), but this is not always ideal. The author may want to express the progress visually, for example. As well, it may not be easy for a non-visual UA to indicate to a user that a live-updated progress section is being updated.

The <progress> element represents this semantic trivially, by taking a minimum, maximum, and current value for the completion of some task. An author may use any method they desire to indicate the progress of an event within a <progress> element, and be assured that all users will be able to understand what is being communicated. As well, it is now trivial for alternative user-agents to find <progress> elements and decipher their meaning, which may allow them to more easily indicate to the user when the progress of some event on the page is changing.

Rationale for <meter>

The <meter> element has nearly identical justification as the <progress> element. It exists to display gauges, rather than indications of progress on some task. For example, an author may indicate disk-space usage on a dashboard page with a small visual indicator (to save space), but still ensure that all users can understand what is represented by the graph by wrapping it in a <meter>.

Semantics are best expressed at the semantic layer (HTML), not at the presentation layer (CSS) or the accessibility layer (ARIA)

The fact that some content is currently irrelevant (hidden="") or is tangentially-related to the main text (<aside>) is semantic, not presentational, and so we help preserve HTML's Separation of Concerns by providing such functionality in HTML, not CSS. As argued by James Graham in an email to the WHATWG list, the fact that current ATs infer semantics from CSS is a failure of the semantic layer to adequately provide authors with the ability to say what they mean.

Expressing semantics with elements, unlike emulating semantics with <div> and CSS, is inherently Media Independent.

Semantics are universal. Expressing semantics with native elements promotes Universal Access better than expressing semantics just to users of AT by using ARIA attributes. For example, if content is irrelevant, it's irrelevant for all users, not just users of AT, so aria-hidden="" is not an appropriate alternative to hidden="". (Jonas Sicking made this argument in an email to public-html.) Ian Hickson put it this way in his null change proposal for ISSUE-31:

ARIA is intended to only affect accessibility API mappings (and thus ATs). Features such as alt="", however, are relevant far beyond AT users, for example to text browsers. It would be wrong, therefore, to make solutions that exclusively affect accessibility APIs be a suitable alternative for solutions that are necessary for UAs that do not use accessibility APIs.

Built-in markup is more likely to survive syndication/whitelisting

Providing functionality in elements allows for its use within syndication feeds and other contexts in which HTML is stripped of its associated styles and scripts.

Built-in markup is simpler than bolt-on enhancement

As Maciej pointed out in a comment on Bug 8118: "When a particular semantic, presentation and accessibility behavior all go together, it's useful to have a single construct to take care of all aspects." Such features Avoid Needless Complexity by being the simplest things that could possibly work.

Because such markup is as simple as can be, authors are far more likely to get such markup right. As Jonas Sicking said in an email to public-html:

[P]eople are much less likely to create accessible markup if they have to add extra markup specifically to make it accessible. I.e. many stop once a page looks correct to the average user, and don't go the extra mile to also support things like screen readers. Additionally, the ones that do make the effort to go the extra mile to, often get it wrong either out of not knowing how to properly add accessibility specific markup, or because they don't have a screen reader to test with.

So it's more likely that people will mark up a header correctly if we have a <h1> tag which changes the styling of the marked up section. So that people can write markup like:


rather than

<div role=heading aria-level=1>header</div>

My concern is that if people are forced to use the latter, many more of them will leave out the role and/or aria-level attributes, stick a class name on it and add some styling.

Browser support

Two browser engines, WebKit and Gecko, covering three major browsers, Safari, Chrome and Firefox, have expressed interest in supporting these elements. Including supporting accessibility for them. WebKit has even already added support for some of them, with work in progress for supporting more. Some people at Opera has expressed interest as well.

Microsoft hasn't officially said anything one way or another, but have indicated that they want to implement the HTML5 specification, and have not spoken up in favor of removing them from the specification.

The use of semantically rich elements is an expressed desire of the W3C Accessibility (WAI) community

In an email dated July 18, 2007, then chair of the W3C Protocols and Formats Working Group Al Gilman wrote:

The working group likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements, such as widgets built in to the markup. This reduces download size and the effort required to make a web page accessible. For these reasons, we would promote the use of such markup over the ARIA approach. That said, we do believe that HTML 5 will not incorporate document elements for all those included in the ARIA role taxonomy nor will it include all the states and properties. For these reasons, backward compatibility for the ARIA specifications is a must.

(emphasis added)

Also, from the WAI-ARIA Roadmap:

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. (emphasis added)

The HTML WG's Accessibility Task Force opposes the removal of these elements, attributes, and controls

Under the HTML WG Accessibility Task Force Work Statement, it is within the scope and responsibility of the Task Force to make proposals and recommendations to the Working Group.

On Tuesday, 20 Apr 2010 the Task Force formally stated:

The following consensus recommendation of the HTML A11Y Task Force (with objections) is hereby referred to the HTML Working Group pursuant to the Task Force consensus procedures at:

Recommendation: ISSUES-90, 91, 93, 95, 96, & 97

RESOLUTION: The HTML-A11Y Task Force opposes the change proposals to remove the elements as proposed in the following issues at the following URIs. We maintain the work item to check these elements and make them better.


A summary rationale together with pointers to additional information considered by the Task Force in reaching this consensus can be found at:

Final Vote: 21 voted "Yes", 4 voted "No"

84% of Task Force members voting on this resolution voted to support it.

All votes, Comments, including all Objections Recorded Against This Recommendation are logged via WBS at:


No change to the spec.


Positive Effects

  • Reduces incidence of media-dependent, buggy author attempts to emulate such functionality using JavaScript and CSS.
  • Makes such functionality available to authors within syndication feeds and other profiles of HTML which forbid scripting and/or styling.
  • Results in better overall accessibility in the long term.
  • Reduces overall code size; while next to negligible at the individual page level, a measurable difference over millions of page views.
  • Allows these elements to be inserted into a page using HTML editing software, while allowing another HTML editing software to understand the markup and let it be further edited. This applies mostly to the complex widgets such as <progress>, <meter> and <details> as they would have to be replaced by a large number of elements that likely would not be fully understood and further editable by another editor.

Negative Effects

  • Each new element, attribute, and control is extra functionality for browsers to implement, and for HTML educators, including tutorials, to teach.

Conformance Classes Changes

No change.


None known.


References are linked inline.