Unclosed element “span”.

The <span> element does not have a currency attribute. Consider using custom data attributes instead, like data-currency.

The attribute displayText is not allowed on <span> elements.

This issue is commonly caused by an old integration of ShareThis via Drupal or other CMS - the old code used invalid attributes like displayText, st_url and st_title which were later changed to HTML5 custom data attributes.

The attribute st_title is not allowed on <span> elements.

This issue is commonly caused by an old integration of ShareThis via Drupal or other CMS - the old code used invalid attributes like displayText, st_url and st_title which were later changed to HTML5 custom data attributes.

The attribute st_url is not allowed on <span> elements.

This issue is commonly caused by an old integration of ShareThis via Drupal or other CMS - the old code used invalid attributes like displayText, st_url and st_title which were later changed to HTML5 custom data attributes.

A span element that conveys special meaning or interactive state must have appropriate ARIA attributes or role to be accessible and pass validation.

The span element is a generic inline container with no semantic meaning. To make it meaningful for assistive technologies (such as screen readers), ARIA attributes or a role attribute should be used when the element represents states, properties, or interactive features.

For example, in the following code the span is used to visually indicate a required field with an asterisk *, but it lacks additional semantic information:

<span class="required" aria-required="true"> *</span>

To address this, add role="presentation" (to mark it as purely visual), or use aria-hidden="true" (to hide it from assistive technology), as the asterisk does not have semantic value for screen readers. Only use ARIA required (aria-required="true") on the form control (e.g., input), not on the decorative indicator.

Recommended HTML (decorative asterisk not announced):

<span class="required" aria-hidden="true">*</span>

Alternative (if you want to announce “required”): Announce “required” with visually hidden text and use the actual aria-required="true" on the input.

<label for="name">
  Name
  <span class="required" aria-hidden="true">*</span>
  <span class="visually-hidden">Required</span>
</label>
<input id="name" name="name" aria-required="true">

This approach ensures accessibility, semantic correctness, and W3C HTML validation compliance.

When the validator reports “Unclosed element ‘X’”, it means an opening tag like <div> or <p> was never terminated with its required closing tag </div> or </p>, or it was closed out of order. HTML parsing then tries to auto-close elements, which can reshape the DOM in ways you didn’t intend. This often happens with nested structures, copy‑paste edits, or when mixing void elements (which never have closing tags) with normal elements.

Leaving elements unclosed can break layout and styles, confuse assistive technologies that rely on a well-formed structure, and cause scripts or CSS selectors to behave unpredictably. It also harms portability between browsers and tools, and makes maintenance harder because the rendered tree differs from what the source suggests.

To fix it, ensure that:

• Every non-void element has a matching end tag: open <section>, close with </section>.
• Nesting is properly balanced: the last opened element is the first one you close (LIFO).
• You do not add closing tags to void elements like br, img, input, meta, link, or hr. These must not have end tags in HTML, and you don’t need a trailing slash.
• Self-closing syntax (<br />) is permitted but treated as <br> in HTML; do not rely on it to close non-void elements.
• Use your editor’s bracket/tag matching or formatter to spot mismatches, and validate early.

Examples

Example that triggers the issue (unclosed element)

<!-- Problem: <div> is never closed, and <p> is closed after a new <div> starts -->

<div class="card">
  <h2>Title</h2>
  <p>Some text
<div class="footer">
  <p>Footer text</p>
</div>

Fixed: properly closed and correctly nested

<div class="card">
  <h2>Title</h2>
  <p>Some text</p>
  <div class="footer">
    <p>Footer text</p>
  </div>
</div>

Example that triggers the issue (out-of-order closing)

<!-- Problem: <em> is opened inside <strong> but closed after </strong> -->

<p><strong><em>Important</strong></em> notice</p>

Fixed: close in reverse order of opening

<p><strong><em>Important</em></strong> notice</p>

Example that triggers the issue (incorrectly “closing” a void element)

<!-- Problem: void elements must not have end tags -->

<p>Line one</p>
<br></br>
<p>Line two</p>

Fixed: use void elements without end tags

<p>Line one</p>
<br>
<p>Line two</p>

Full document example with a common pitfall (lists and paragraphs)

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Unclosed Element Fix</title>
  </head>
  <body>
<!-- Problem avoided: do not nest <li> across paragraph boundaries -->

    <ul>
      <li>
        <p>Item one title</p>
        <p>Item one details</p>
      </li>
      <li>
        <p>Item two</p>
      </li>
    </ul>
  </body>
</html>

Tips to prevent “Unclosed element” errors

• Keep indentation consistent; it visually reflects nesting.
• Close tags immediately after opening, then fill content.
• Use linters/formatters (e.g., HTMLHint, Prettier) and run the W3C validator regularly.
• Be cautious when mixing templating logic; ensure conditionals don’t skip required end tags.