This content originally appeared on Scott O’Hara - Accessibility engineer, UX developer and designer and was authored by Scott O'Hara
The <div> 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).
This versatility allows for <div>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 <div> soup, content missing semantic meaning, inaccessible interactive controls, or some combination of all.
A <div> comes to the party. A11y folk be like:
It’s relatively straight forward to identify instances of flagrant misuse. However, it has gotten to a point where people will come across entirely valid use cases, or at least instances where its use is benign, and it is pointed out as being an example of inaccessibility. “Someone should have used semantic HTML instead!”
Well. Hold up there a minute. Is that really going to make something more accessible? Swapping out <div>s with other semantic elements?
Before we talk about that, let’s rewind a bit and briefly look at where the <div> came from.
The semantic (de)evolution of <div>
Originally introduced in HTML 3.0, the <div> element represented a “division” of content. As originally written:
The DIV element … represent[s] different kinds of containers, e.g. chapter, section, abstract, or appendix.
In HTML 3.2 <div> and <center> were defined as essentially the same element.
<center> was treated as a "shorthand" for <div align=center>, with the element becoming part of the HTML standard because Netscape had introduced the element prior to implementing the standard <div> element. Cow paths be paved... [even if they eventually lead nowhere](https://www.w3.org/TR/html401/present/graphics.html#edef-CENTER).
What’s interesting here is that <div>’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 <div> or <center> element served as an alternative to people chucking everything into <table> elements, at least.
A <div> in HTML 4.01
By HTML 4.01, the definition of <div> had become less explicit in mentioning what it could represent, but was still promoted as a feature specifically for structuring content.
Keep in mind though, that while <div> was supposed to be used to structure and group meaningful content, its “semantics” purposefully did not provide a consistent definition of what type of content it represented, and thus how it could be interpreted by assistive technologies.
Modern <div>-finition
You know… like “definition” but with a <div>… oh gosh I’m sorry. I just can’t delete it…
By HTML5 and as the <div> is defined today by the HTML Living Standard a <div> had become:
The
divelement has no special meaning at all. It represents its children. It can be used with theclass,lang, andtitleattributes to mark up semantics common to a group of consecutive elements. It can also be used in adlelement, wrapping groups ofdtandddelements.
HTML goes on to note:
Authors are strongly encouraged to view the
divelement as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of thedivelement leads to better accessibility for readers and easier maintainability for authors.
MDN provides further developer guidance for <div>.
In HTML AAM, a <div> is mapped to the generic ARIA role. Similarly to HTML’s <div>, ARIA defines generic as:
A nameless container element that has no semantic meaning on its own.
Representing nothing
By representing nothing, a <div> is free to be anything. A <div> is essentially chaotic neutral and can easily pivot between valid and invalid use, per the whim of the developer that uses it.
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, <span tabindex=-1 id=”consider-q”>consider the following</span>:
<div>Hi there, I'm a paragraph of content!</div>
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 <div> use cases that are more easily identifiable as invalid or not.
Clear misuse of <div>
The most common example for how not-to-div is when used to create interactive content, such as “links” or “buttons”:
<div class=button onclick=foo()>
Click me!
</button>
Without getting too deep into it (you can read this role=button MDN article for that), a <div> is not an interactive element. Styling alone does not make a <div> a “button”, for instance. Nor will even adding click handlers meet all the requirements for re-creating accessible buttons.
In regards to structural content containers, a quick way to determine if a <div> 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:
<body>
<div class=header>
...
</div>
<div id=main>
...
</div>
<div class=footer>
</div>
</body>
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 <div> elements to their more appropriate HTML elements. Or, by employing ARIA to assign any necessary role, state and property attributes where necessary. And, in regards to interactive content, ensuring that all the necessary keyboard, accessibility functionality (JavaScript and styling) is provided. Sure, the latter is far more work than the former, but hey… if it’s done right, it’s not “wrong”. Just took far more effort is all.
This (<div>) is fine
Let’s look at two examples of when a <div> is perfectly acceptable to use.
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 <div> could be used, with a lang attribute specified with necessary the language tag, to contain all this content and identify it as being of the appropriate language.
<div lang=fr>
<h3>...</h3>
<p>...</p>
<ul>
<li>...
<li>...
<li>...
...
</ul>
...
</div>
In the above example, using the wrapping <div> to specify the 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 <div> is a perfectly acceptable element to use here. More on that in a bit…
Next, a <div> is also absolutely OK to use when structuring content for styling purposes. For instance,
<main>
<div style="display: flex; ...">
<div style="flex: ...">
<h1>...</h1>
<!-- sub-heading / meta data could go here -->
</div>
<div style="flex: ...">
<!-- social follow links -->
</div>
</div>
<!-- other semantic elements / content go here -->
</main>
In the above, <div>s are used to contain the <h1> 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).
“But wait”, you might say, “isn’t using <div>s to structure content a bad thing? Shouldn’t those examples have used more accessible elements?”
Sometimes, sure. As mentioned, <div>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.
A generic by any other tag name…
Beyond <div>, there are actually a good handful of more semantic HTML elements that are exposed as generic. To name a few, <address>, <kbd>, <abbr>, and <body> are implicit generic elements.
Going a step further, there are other elements such as <header>, <footer> and <section> 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.
For instance, a <header> maps to role=banner when scoped to the <body> element. This means that so long as no <main> element, sectioning content element, or sectioning root element come between the <header> and the <body>, then <header> will be exposed as a banner landmark.
With HTML though, a <header> is not always a banner. A <header> is perfectly valid and is semantically appropriate to use as a descendant of an <article> or a <section>. However, in that context it does not represent a landmark containing mostly site-oriented, rather than page-specific content.
Thus, if <header> is not scoped to <body>, it becomes a generic element, just like a <div>. This holds true for the <footer> element as well.
<body>
<header> I'm a banner! </header>
<main>
<header> I am NOT a banner! </header>
...
</main>
</body>
Regarding the <section> 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:
<!-- a generic section -->
<section>
<h2>...</h2>
...
</section>
<!-- a 'region' landmark -->
<section aria-labelledby=h>
<h2 id=h>...</h2>
...
</section>
The reason <section> behaves this way was due to rampant overuse / misuse of the <section> element. “Section all the things!”
Landmarks are meant to define particularly important areas of a web page, and a region landmark is really supposed to be used only when a more descriptive landmark is not appropriate.
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 <div>, huh?
The severity of semantics
Regarding the “fine” <div> examples, sure those could have used a <section> and <header> 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 <div>s already in use.
Similarly, let’s take a look at that question I raised about a <div> serving as a paragraph of content.
If your initial thought was that it won’t programmatically be exposed as a paragraph to screen reader users. Well…
See the Pen i'm a paragraph by Scott (@scottohara) on CodePen.
In HTML a <p> 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 <p> 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 <div> over <p>? Generally not.
There are so many complex accessibility issues we need to be concerned about. Having developers swap out <div>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.
And to be absolutely clear, I am not advocating for the use of <div>s when semantic elements would be more appropriate. Use semantic HTML. Use semantic HTML by defult. Just maybe also don’t worry so much about if other people aren’t using semantic HTML if what they’ve created is not actually going to create any major (blocking) 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 <div>s.
Remember, <div>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 all agree that’s not what <div>s are for.
Post-outro: Concerning soup
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 because I don’t want to write about stuff he’s already covered so well.
This ended well. I think this ended well…
yeh. It’s fine.
This content originally appeared on Scott O’Hara - Accessibility engineer, UX developer and designer and was authored by Scott O'Hara
Scott O'Hara | Sciencx (2022-01-20T00:00:00+00:00) Divisive divs. Retrieved from https://www.scien.cx/2022/01/20/divisive-divs/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.