The This versatility allows for It’s relatively straight forward to identify instances of flagrant misuse (more on that later). However, it has gotten to a point where people will come across entirely valid use cases, or at least instances where a A Well. Hold up there a minute. Before we turn up our collective noses at the use of Yes, people should use semantic HTML whenever possible. But, let’s be careful about making it seem like any use of a Before we talk about that, let’s rewind a bit and briefly look at where the Originally introduced in HTML 3.0, the The DIV element … represent[s] different kinds of containers, e.g. chapter, section, abstract, or appendix.
In HTML 3.2
What’s interesting here is that By HTML 4.01, the definition of However, without any specific semantics the elements could promote, there was no real way to programmatically convey what the elements could or should be used for. At least not in a way that could be interpreted by assistive technologies, especially since HTML5 was where WAI-ARIA support, and sectioning and grouping elements with more specific semantics were first introduced.
You know… like “definition” but… with a By HTML5 and as the The HTML goes on to note:
Authors are strongly encouraged to view the MDN provides further developer guidance for In HTML AAM, a A nameless container element that has no semantic meaning on its own.
By representing nothing, a Reasonably, this might be a bit hard to track for some who are expecting a clear right and wrong way to markup accessible content. For instance, consider the following:
What problem is doing something like that going to create? We’ll touch on that again later, but for now let’s look at some The most common example for how not-to-div is when used to create interactive content such as “links” or “buttons”:
Without getting too deep into it (you can read this But, if someone goes to all the trouble to make their Now, regarding structural content containers, a quick way to determine if a While incredibly simplified, there are websites being built today that resemble the above markup example.
These are instances of misuse that are both easy to identify, and rectify. Whether that be by changing the Let’s look at two examples of when a To start, consider a series of paragraphs or other elements that are written in a language that differs from the primary document (web page). A In the above example, using the wrapping Next, a In the above, “But wait”, you might say, “isn’t using Sometimes, sure. As mentioned, Beyond Going a step further, there are other elements such as For instance, a With HTML though, a Thus, if Regarding the The reason Landmarks are meant to define particularly important areas of a web page, and a Having a page full of region landmarks would make the accessibility of that page worse, as if “everything” is marked up as being important, then really, nothing is important.
Hmm… Sounds a bit like Regarding the “fine” Similarly, let’s take a look at that question I raised about a If your initial thought was that it won’t programmatically be exposed as a paragraph to screen reader users. Well…
See the Pen In HTML a There are so many complex accessibility issues we need to be concerned about. Having developers swap out And to be absolutely clear, I am not advocating for the use of Use semantic HTML. Use semantic HTML as a default. Just maybe also don’t worry so much about if other people aren’t using semantic HTML if what they’ve built doesn’t actually result in accessibility issues? Or, if calling out the lack of semantic HTML, be very specific about what the actual problem is. The semantics of HTML are not just about accessibility. They’re useful for other tools that consume HTML, and can be far easier to understand for fellow developers modifying markup than a sea of never-ending Remember, In a previous draft I had called out Eric Bailey’s presentation on the intersection of performance and accessibility.
My post changed considerably and I couldn’t figure out where to put this without going onto some other tangent. So here it is anyway. I suggest reviewing his slides for more information on this particular topic - mostly b
Featured Content Ads
add advertising here
Featured Content Ads
add advertising here
Featured Content Ads
add advertising here
The semantic (de)evolution of
elements, at least.
A
element. The
to be used as generic container for inline content.
Modern
div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements. It can also be used in a dl element, wrapping groups of dt and dd elements.
div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.
generic ARIA role. Similarly to HTML’s
generic as:
Representing nothing
Clear misuse of
role=button MDN article for that), a
div-button have all the necessary keyboard accessibility, expose itself as a “button” and any other applicable state (disabled, presed, expanded, etc.), and they even went to the trouble of making it behave nicely with Windows High Contrast Mode. Well, good on them. Sure, this was far more effort than using a native element. But if it’s done right, then there’s nothing really wrong about it, is there?
Structural misuse
). Or, by employing ARIA to assign any necessary role, state and property attributes where necessary (e.g.,
This (
lang attribute specified with necessary the language tag, to contain all this content and identify it as being of the appropriate language.
...
...
...
...
...
lang attribute is far easier than specifying it on each individual element. Also, assuming this grouping of content is unique to the current page, a
and other intro-related content to the primary topic of the page. Flexbox is then used to layout the content as needed (style attributes are used for simplifying the example).
A
generic by any other tag name…
generic. To name a few,
, , , and are implicit generic elements.
,
and
where under very common markup conditions, they too are exposed as generic elements. The reason for this is because accessibility roles have very specific purposes. HTML elements also have well defined semantics to indicate how developers are supposed to use each element, but not all HTML elements have an exact one to one match with how their implicit ARIA semantics are defined.
maps to role=banner when scoped to the element. This means that so long as no element, sectioning content element, or sectioning root element comes between the
and the , then
will be exposed as a banner landmark.
is not always a banner. A
is perfectly valid and is semantically appropriate to use as a descendant of an landmark containing mostly site-oriented, rather than page-specific content.
is not scoped to , it becomes a generic element, just like a
element as well.
element, it actually starts off as a generic. It can be exposed as a region landmark, so long as the element is provided an accessible name. For instance:
...
...
behaves this way was due to rampant overuse / misuse of the
element. “Section all the things!”
region landmark is really supposed to be used only when a more descriptive landmark is not appropriate.
The severity of semantics
and
element to be the containers for each of those examples, respectively. Semantically, that would have made sense. However, their use would not expose any role difference than the
i'm a paragraph by Scott (@scottohara)
on CodePen.
is but one way to define a paragraph. Implicit paragraphs are created with each new ‘block’ of text in the page. So, similarly, before playing the “use semantic HTML and you get accessibilty for free” card, it’s important to think about the reality of the user impact, and if that card is really worth playing at this time. Would using explicit
elements be better? Yes. Would it help ensure user style sheets would have a consistent hook to modify paragraphs? Also yes. Is this what people are actually talking about when calling the use of a
? Generally not.
Post-outro: Concerning soup
is the most versatile and used element in HTML. It represents nothing, while allowing developers to manipulate it into almost anything by use of CSS (for styling), JavaScript (for functionality) and ARIA (for accessibility information).
s to be used for many purposes, but unfortunately this permissiveness can easily result in misuse. When not used carefully, the end result could either be
soup, content missing semantic meaning, inaccessible interactive controls, or some combination of all.
’s use is benign, and it is pointed out as being an example of inaccessibility. “Someone should have used semantic HTML instead!”
comes to the party. A11y folk be like:
s, remember that context matters.
is bad… or, if swapping one out for a more semantic element would actually even move the accessible needle.
came from.
element represented a “division” of content. As originally written:
and
, with the element becoming part of the HTML specification because Netscape had introduced the element prior to implementing the standardized
element. Cow paths be paved… even if they eventually lead nowhere.
’s original definition could be looked at as a very early idea of what would someday become sectioning content in later versions of HTML. I’m not saying that’s what the intent was at the time, but clearly HTML lacked specific elements for common sectioning/grouping containers. A
or
in HTML 4.01
had become less explicit in mentioning what it could represent, but rather was to be used as a general tool for structuring content. In HTML 4.01 we also saw the loss of
being promoted for block-level structuring, while the
-finition
… I’m sorry. I just can’t delete it…
is defined today by the HTML Living Standard a
had become:
.
is mapped to the
, ARIA defines
is free to be anything. A
is essentially chaotic neutral and can easily pivot between valid and invalid use, per the whim of the developer that uses it.
Hi there, I'm a paragraph of content!
use cases that are more easily identifiable as invalid or not.
is not an interactive element by default. Styling alone does not make a
a “button”, for instance. Nor will even adding click handlers meet all the requirements for re-creating accessible buttons.
is being used in place of a more semantic element might be quickly determined by reviewing its visual representation. Alternatively, if looking at the underlying source code, the classes (as long as they’re not gobbledygook) or IDs that are used on the elements:
id=main>
...
class=footer>
elements to their more appropriate HTML elements (e.g.,
).
) is fine
is perfectly acceptable to use.
could be used, with a
to specify the
is a perfectly acceptable element to use here. More on that in a bit…
is also absolutely OK to use when structuring content for styling purposes. For instance,
style="flex: ...">
s are used to contain the
s to structure content a bad thing? Shouldn’t those examples have used more accessible elements?”
s are misused a lot, so it is not unreasonable for someone to initially think this. However, for the above examples… well, more context is necessary. This is accessibility related, after all.
, there are actually a good handful of more semantic HTML elements that are exposed as
. This holds true for the
, huh?
examples, sure those could have used a
s already in use.
serving as a paragraph of content.
over
s for other equally generic elements, or elements that might provide minor improvements for users, when there is a backlog of far more pressing issues to resolve… I don’t know. I think there’s a severity level here that is being glossed over.
s when semantic elements would be more appropriate.
s.
s are meant to represent nothing. They can be made into just about anything… just don’t make them into soup. I think we can at least all agree that’s not what
s are for.