Skipping heading ranks can be confusing and should be avoided where possible: Make sure that a <h2> is not followed directly by an <h4>, for example.W3C Web Accessibility Initiative (WAI)
Imagine my predicament: my so-called textboxes have a default <h4> heading 1 (see below), but my textboxes do not always follow an <h3>. Sometimes, they appear directly after an <h2>, or even another <h4> that serves as a real heading, not a textbox. Naturally, I haven’t been updating the textbox headings to maintain logical order.
<div class="textbox">
<h4>TITLE HERE</h4>
<p>YOUR TEXT HERE</p>
<p>YOUR TEXT HERE</p>
</div>The “Accessibility and inclusive design manual” from the UK Department of Education states that skipped heading levels can cause confusion for users, and from a semantic code perspective, is incorrect.
Nesting headings properly is crucial; subheadings should descend in order of importance, avoiding jumps. Headings should demonstrate document structure and relationships between sections. Users often skim pages by headings, and search engines use them to index content.
Do not skip heading levels, as it is confusing and semantically incorrect.
Creating an accessible heading structure is essential for ensuring everyone can understand and navigate your website or document. By using the correct HTML heading elements, descriptive headings, and avoiding skipped levels, you can establish a clear and understandable heading structure that benefits all users. As I mentioned in my “Turning headings into link targets—cont’d” post about this issue, given the importance of maintaining a sound document outline, I may have to add a task to my blog posts housekeeping to-do list.
Here I am, ready to tackle this task… and make it the topic of this post.
A catch-22 situation
Now, if you paid attention to my footnote, you might ask: if you chose <h4> for its appearance — a bad rationale, by the way — why not use CSS to style normal text the way you want your headings to look?
h4 {
color: #333;
font-size: 16px;
font-size: 1rem;
font-weight: 800;
}The simple answer is that these textboxes are not merely paragraphs. They are display items, akin to those found in scientific reviews or other articles, designed to support the reader’s understanding of the topic. These auxiliary sections play a crucial role in presenting information succinctly and clearly, without interrupting the flow of the main text. Therefore, they merit their own headings to highlight their significance and ensure a seamless reading experience.
While preparing my article “Turning Headings into Link Targets—cont’d,” I discovered that the recommended method for adding an anchor to a heading is to use the <section> element with an id attribute. Before this, I wasn’t even aware of this element. This discovery led me to explore its proper usage in detail; this will be the subject of a future post. But, if you’re interested in learning (now) more about when to use it, consider reading “the <section> element” textbox in the aforementioned article. Yes, a textbox!
<section id="introduction-to-everything">
<h2>Introduction to everything</h2>
...
</section>As explained in the aforementioned textbox, sections should always include a heading, typically by incorporating a heading element (<h1> – <h6>) as a child of the <section> element. Given that my textboxes are described as “auxiliary sections” and considering that an HTML section is a thematic grouping of content, I should even replace my <div> element (see code in the introduction) with the <section> element. However, this solution does not address the issue of skipping heading levels. I find myself back at square one.
“Why don’t you update the heading of your textbox based on the section you place it in?”
“That would indeed be an easy fix, but there’s one major caveat: the appearance would lack consistency!”
So, here is my dilemma: how to keep a stable heading without breaking the hierarchical rules while still using the <section> element. This is the essence of a catch-22 because if I choose to maintain a stable heading for aesthetic consistency, I end up breaking the hierarchical rules, which impacts accessibility. Conversely, if I follow the hierarchical rules, I lose the visual consistency of my headings.
Seeking expert advice
As someone who isn’t an expert in HTML, I realized I needed help navigating this intricate issue. I found myself indeed lacking the necessary expertise to solve the problem effectively. This situation felt like a catch-22—no matter what I tried, I couldn’t find a satisfactory solution. Faced with a complex problem like this, I therefore turned to my editing assistant, Copilot, for guidance. I thought that Copilot, with its broader knowledge base and coding specialization, might offer more insightful solutions and help me overcome this challenge.
I understand your dilemma. To keep a stable heading without breaking the hierarchical rules and still use the <section> element, we can consider a couple of approaches:
[Text moved below for clarity]
These approaches should help you keep your content accessible and semantically correct without disrupting the visual design or heading hierarchy. Choose the one that best fits your needs and design preferences.
I hope this helps! If you need any more assistance or have further questions, feel free to ask. 😊
Approach 1: Visually hidden headings
[Continuation of the original conversation]
If you want to maintain the semantic structure without displaying the heading visually, you can use visually hidden headings. This way, the headings are present for accessibility and structure but do not disrupt the visual design.
Copilot provided me with code examples for this approach (both HTML and CSS for Visually Hidden class):
<section class="textbox">
<h4 class="visually-hidden">Textbox Title</h4>
<p>Your textbox content here...</p>
</section>.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
border: 0;
}While the concept of using visually hidden headings to maintain semantic structure and accessibility is appealing, it presents a couple of significant challenges in my context. Firstly, this approach necessitates updating the heading of the textbox every time it is placed in a different section. This is not only tedious but also prone to human error, as it requires meticulous attention to ensure consistency and accuracy across various sections. Secondly, and perhaps more importantly, this approach results in the loss of the textbox title. The title serves as a vital cue for the content within the textbox, providing users with a clear understanding of its purpose and context. Without a visible title, the textbox may lose its intended impact and functionality, potentially confusing users and diminishing the overall user experience.
Approach 2: Using ARIA roles
[Continuation of the original conversation]
If you prefer not to use headings at all but still want to ensure accessibility, you can use ARIA roles to provide semantic meaning without actual headings.
Again, Copilot provided me with code examples for this approach:
<section role="region" aria-labelledby="textbox-title">
<div id="textbox-title" class="visually-hidden">Textbox Title</div>
<p>Your textbox content here...</p>
</section>Initially, I found the suggestion to use ARIA roles a bit too advanced for my understanding. So, I turned to Copilot for clarification. Copilot explained that ARIA, which stands for Accessible Rich Internet Applications, involves attributes that can be added to HTML elements to enhance web content’s accessibility. These attributes help assistive technologies interpret and interact with the content more effectively.
Copilot also clarified the purposes of role="region" and aria-labelledby="textbox-title". The former attribute designates a specific section of the content as a region, while the latter associates the textbox with a label, ensuring that assistive technologies can identify and announce the textbox’s title to users. By using ARIA roles, I could create a stable, accessible heading structure for my textboxes without breaking the heading hierarchy or disrupting the visual design.
At first, I hesitated to adopt this approach due to my unfamiliarity with ARIA roles. However, another concern also emerged: sections should always include a heading. Next!
Approach 3: Using a paragraph as a pseudo-heading
[Continuation of the original conversation]
Another alternative is to use a styled paragraph to act as a pseudo-heading. This won’t break the heading hierarchy but can still provide a visual cue.
Copilot provided me with the following code for this approach:
<section class="textbox">
<p class="textbox-title">Textbox Title</p>
<p>Your textbox content here...</p>
</section>.textbox-title {
font-weight: bold;
font-size: 1.25em; /* Adjust size as needed */
margin: 0.5em 0;
}I explained to Copilot that I had already thought of using styled paragraphs as pseudo-headings (see above) but had rejected the idea, hoping for something more advanced. That was why I turned to it for a better solution.
Admittedly, it provided me with something advanced—the second approach using ARIA. Still, I was not satisfied. I was hoping for something else (not knowing exactly what, to be honest). So, I came back to Copilot (later, during another conversation, as the new Copilot cannot recall what happened in a previous session). He suggested the ARIA solution again but also came up with a new one…
Approach 4: Dynamic heading levels with JavaScript
Ensuring a consistent and accessible structure for your textboxes is important. To achieve this, you can use the <section> element for your textboxes and dynamically adjust the heading level based on the surrounding context.
When I read this description, I thought I had finally obtained what I was looking for. But when I looked at the code Copilot provided, I knew this was not the case.
<section class="textbox">
<h4 class="textbox-heading">Your Heading</h4>
<p>Your textbox content here...</p>
</section>
<script>
document.addEventListener('DOMContentLoaded', function() {
const textboxes = document.querySelectorAll('.textbox');
textboxes.forEach(textbox => {
const heading = textbox.querySelector('.textbox-heading');
const parentSection = textbox.closest('section');
if (parentSection) {
const parentHeading = parentSection.querySelector('h1, h2, h3, h4, h5, h6');
if (parentHeading) {
const level = parseInt(parentHeading.tagName.slice(1)) + 1;
heading.tagName = 'H' + level;
}
}
});
});
</script>“You asked for more advanced!”
“Yes, but this is way out of my league…”
Gemini to the rescue
As time passed, my search for an ideal solution faded into the background, overshadowed by other priorities and tasks. When the moment came to work on this post, I found myself back at square one, still grappling with my textbox dilemma and no closer to resolving my catch-22. Given the circumstances, I decided to turn to Gemini, hoping that a fresh perspective might provide the breakthrough I needed.
You’re right, sections ideally should have headings to describe their content. Since you want these “explanation boxes” to be nested under different heading levels (h3, h4, etc.) but don’t want to use a heading inside the box itself, here are a few options you could consider:
[Text moved below for clarity]
Remember to choose the approach that best suits the meaning of your content, not just its visual appearance. Let me know if you have any other questions!
Option 1
Using a <div> with a class and visually styling it
This is probably the most straightforward approach. You can use a <div> to wrap your box content and give it a class (e.g., “explanation-box”). Then, you can use CSS to style it to look like a box, and you can use a separate element (like a <p> or a <span>) outside the box, but still within the containing section, to act as your “Box 1” title.
<h3>Section Title</h3> <section>
<p class="box-title">Box 1: Explanation of Something</p>
<div class="explanation-box">
<p>This is the content of the explanation box. It can contain text, images, or other HTML elements.</p>
</div>
</section>
<style>
.box-title { /* Style the title */
font-weight: bold;
margin-bottom: 0.5em; /* Add some spacing */
}
.explanation-box { /* Style the box */
border: 1px solid #ccc; /* Add a border */
padding: 1em; /* Add padding */
margin-bottom: 1em; /* Add spacing below the box */
/* other box styles */
}
</style>This solution, which mirrored my initial thoughts, was too basic and limited in functionality, and obviously not the answer I was looking for. However, Gemini suggested an enhancement to this method by recommending, just as Copilot did, the addition of ARIA attributes—role="region" and aria-labelledby="box1-title"—to improve accessibility for screen readers.
My disillusionment was short-lived, however, as I moved on to the second option.
Option 2
Using <figure> and <figcaption>
The <figure> element is designed for self-contained content like images, diagrams, and boxes. <figcaption> can be used as the caption for the figure. This approach is semantically more appropriate if your “explanation box” can be considered a figure in some way.
<h3>Section Title</h3>
<section>
<figure class="explanation-box">
<figcaption>Box 1: Explanation of Something</figcaption>
<p>This is the content of the explanation box.</p>
</figure>
</section>
<style>
.explanation-box { /* Style the box as before */
border: 1px solid #ccc;
padding: 1em;
margin-bottom: 1em;
}
.explanation-box figcaption {
font-weight: bold;
margin-bottom: 0.5em;
}
</style>The suggestion of using the <figure> element struck me as both simple and ingenious—a perfect fit for my needs. To ensure its suitability, I sought further confirmation from Gemini about employing this element in this particular context:
Yes, based on your initial description, I think the <figure> element is a very good fit for your “explanation box.” You described them as being similar to tables or figures in scientific reviews, which strongly suggests they are self-contained units of content that could be moved around without losing their meaning. This is exactly what <figure> is designed for. It represents a piece of content that is often referenced or cross-referenced in the main text, but which could technically stand alone.
Here’s why <figure> is a good choice in your case:
Self-contained content: Your explanation boxes are self-contained; they provide additional information related to the surrounding text but are distinct from it. This matches the definition of <figure>.
Captions: The <figcaption> element is perfect for your “Box 1,” “Box 2,” etc., labels. It provides a clear and semantically correct way to title your boxes.
Flexibility: While often used for images, <figure> is explicitly intended for other types of “flow content,” including text, diagrams, and even groups of elements. Your text boxes fall under this category.
Semantics: Using <figure> provides more semantic meaning to your HTML than a generic <div>. It tells assistive technologies and search engines that this content is a distinct, labeled unit.
Using <figure> will also make your HTML more readable and maintainable. It clearly separates the explanation boxes from the main content flow.
So, yes, I strongly recommend using the <figure> and <figcaption> elements for your explanation boxes. It’s the most semantically appropriate and elegant solution for your needs.
A hasty celebration
If the content is truly like a figure (self-contained and referenced), the <figure>/<figcaption> approach is semantically the best.Gemini
My initial excitement about the <figure> element blinded me; I didn’t pay attention to the details. You might have already noticed the problem, but for me, the reality struck as I began drafting this post. To my dismay, I realized that the <section> element was missing a heading. Sections should always include a heading! My enthusiasm was abruptly cut short, and it became clear that a different approach was needed. Or was it? I raised the issue with Gemini:
You are absolutely right to be concerned! My apologies for the oversight in the previous example. Sections should have headings. It’s a best practice for accessibility and semantic structure. I mistakenly omitted it in the interest of focusing on the <figure> element.
<h3>Section Title (or whatever heading level is appropriate here)</h3>
<section>
<h4>Related Information</h4> <figure class="explanation-box">
<figcaption>Box 1: Explanation of Something</figcaption>
<p>This is the content of the explanation box.</p>
</figure>
<figure class="explanation-box">
<figcaption>Box 2: Another Explanation</figcaption>
<p>More content for the second box.</p>
</figure>
<p>Some more text related to the section.</p>
</section>
<style>
.explanation-box {
border: 1px solid #ccc;
padding: 1em;
margin-bottom: 1em;
}
.explanation-box figcaption {
font-weight: bold;
margin-bottom: 0.5em;
}
</style>The persistent challenge of the <section> element reared its head once again, leaving me grappling with the unresolved issue of maintaining proper heading hierarchy:
The heading level (<h4> in this example) should be appropriate to the context of where this section appears in your document’s structure.
Victory at last
In practice, the most common use is for captioned images and charts. This makes sense, as “figure” has a meaning in academic and technical writing — an illustration, image, chart, or other visual content, usually captioned, related to the main content but often found separated from it.Adam Wood
Having exhausted the suggestions from both Copilot and Gemini, I decided to take matters into my own hands. Now, this exploration with AI wasn’t fruitless; in fact, the potential solution with the <figure> element might be exactly what I need. So, I delved into research about this element, seeking to understand its functionality and, more importantly, whether it needed to be nested within a <section> element.
Briefly, the <figure> element was introduced in HTML5. It represents flow content that is self-contained and can optionally include a caption (<figcaption>). The <figure> element is typically referenced as a single unit within the main flow of the document. Commonly used for images, illustrations, diagrams, code snippets, and similar content, it allows these elements to be moved to different parts of the document or even to an appendix without disrupting the main content flow. This flexibility makes the <figure> element particularly valuable for content that needs to be organized independently of the surrounding context.
While the content of the <figure> element is related to the main flow, its position is independent of the main flow, and if removed it should not affect the flow of the document.W3Schools
The figure, its caption, and its contents are referenced as a single unit.
While the content of the <figure> element can indeed be varied, one thing became abundantly clear in my research: it was never nested within a <section> element in any of the numerous examples I encountered. In fact, I couldn’t find any information linking the <figure> and <section> elements 3, likely because they are not related at all. This further reinforced my decision to use the <figure> element without worrying about its placement within a <section> element, allowing me to maintain the integrity of my document structure without compromising on accessibility or functionality.
<figure class="textbox" id="box1">
<figcaption>Box 1: TITLE HERE</figcaption>
<p>YOUR TEXT HERE</p>
<p>YOUR TEXT HERE</p>
</figure>By adopting this new approach, I found that the <figcaption> element seamlessly replaces the need for a heading within the textbox. Instead of using <section> to replace <div>, the <figure> element will now be my go-to. Importantly, not only did I resolve my catch-22 dilemma, but I also incorporated the id attribute, making it simple to link directly to my text boxes. This was precisely the motivation behind my “Turning Headings into Link Targets” article.
Armed with this newly refined code, I only need to: 1) update the textboxes in my previous posts (an addendum to my Blog posts housekeeping to-do list), and 2) revise my ‘textbox’ reusable block for future use (and write a post about its inception; part of the CogitActive Saga).
Happy ending! For a change…
1 Why did I choose <h4> initially? Likely because it was low enough in the hierarchy to avoid frequent competition with other headings, and aesthetically, it was more appealing than <h5> or <h6>. However, I should have known better: Use HTML headings for headings only. Don’t use headings to make text BIG or bold.
^
2 Here is Gemini’s response when I reminded it about this: You’re absolutely right to bring that up. You’re back to the original problem of wanting the “Box 1,” “Box 2,” etc., titles to adapt to the surrounding heading level without explicitly using a heading tag inside the box.
^
3 To be absolutely certain, I asked Gemini. Here is the response: Yes, a <figure> element can stand on its own, outside of a <section>, and it will still be treated as a distinct piece of content.
^