Presentational markup used instead of semantic elements

What is this issue?

The page contains <b> or <i> elements. Neither carries inherent semantic meaning for assistive technology on its own. <b> is defined in HTML5 as text to draw attention to stylistically, without implying it’s more important than surrounding text, and <i> as text in an alternate voice or mood (a technical term, a foreign phrase, a ship’s name) without implying emphasis or stress. Where the actual intent is to signal genuine importance or emphasis, <strong> and <em> are the correct elements instead, since those specifically carry that meaning into the accessibility tree.

This rule flags every <b> and <i> element on the page for review; it does not attempt to determine which specific instances are already correct, stylistic uses and which should be <strong> or <em> instead. See “How RedFlag Detects This” for why that judgment is left to a human reviewer.

Why does this matter?

<strong> and <em> expose emphasis and importance directly to the DOM (the tree structure the browser builds from your HTML, representing every element and how they nest), which is what assistive technology actually reads, not the visual rendering. <b> and <i> render identically on screen (bold and italic, by default) but carry none of that semantic signal through to a screen reader by definition.

For content where emphasis genuinely changes meaning (a warning inside a sentence, “do not submit twice”, or a word that changes a sentence’s intent if stressed differently), a sighted reader picks up the visual weight instinctively. A screen reader user relying only on <b> or <i> markup for that same content may get no equivalent signal at all, since neither element is guaranteed to announce any different than plain text. The meaning conveyed by styling alone doesn’t reliably reach every reader.

Who is affected?

• Screen reader users: may hear no distinction between emphasized and non-emphasized text when <b> or <i> is used where <strong> or <em> was intended, since presentational elements aren’t guaranteed to change how assistive technology announces the wrapped text.

What users experience

Wei uses VoiceOver on her Mac to read a medication instruction page. A critical warning is marked up as <p>Take with food. <b>Do not exceed 2 tablets in 24 hours.</b></p>, visually bold and clearly set apart to a sighted reader, but semantically no different from the surrounding sentence to VoiceOver, which reads it in the same flat tone as the rest of the paragraph. The dosage limit that a sighted user’s eye is drawn straight to blends into the rest of the instructions for Wei, with no vocal cue marking it as the sentence she most needs to catch.

How do I fix it?

Review each <b> and <i> element and decide, based on what the text is actually doing, whether <strong> or <em> better matches the intent, then switch to whichever element actually communicates that meaning. This works because <strong> and <em> are semantic elements (HTML elements chosen for what they mean, not just how they look) that expose importance and emphasis directly to the accessibility tree, giving assistive technology a real signal to act on instead of only a visual style.

Not every instance needs to change. If the text genuinely is a stylistic label with no real importance or emphasis behind it (a product name, a keyword in a definition list, a ship’s name in a story), <b> or <i> remains the semantically correct choice as defined by HTML5, and switching it to <strong> or <em> would be inaccurate in the other direction. For text that’s purely a visual effect with no semantic intent at all, use CSS (font-weight or font-style on a <span>) instead of reaching for either pair.

Code Examples

<p>Please <b>do not</b> submit the form twice.</p>
<p>The event is on <i>Friday</i>, not Thursday.</p>

<!-- Genuine importance: use strong -->
<p>Please <strong>do not</strong> submit the form twice.</p>

<!-- Genuine stress emphasis: use em -->
<p>The event is on <em>Friday</em>, not Thursday.</p>

<!-- Legitimate b/i use: a stylistic label with no real emphasis -->
<p>The <i>RMS Titanic</i> departed Southampton in 1912.</p>

<!-- Visual-only styling with no semantic intent: use CSS -->
<p>The product is <span class="brand">RedFlag</span>.</p>

The first two examples genuinely need emphasis conveyed to assistive technology, so they switch to <strong> and <em>. The third keeps <i>, correctly, since a ship’s name is exactly the kind of “alternate voice” HTML5 defines <i> for; it isn’t emphasized, just conventionally styled. The fourth drops semantic markup entirely in favor of CSS, since brand styling carries no meaning that belongs in the accessibility tree at all.

Common Mistakes

Mistake: “b and i are deprecated, so any use of either is automatically wrong.” HTML5 explicitly redefined both elements with legitimate, non-deprecated meanings rather than removing them: <b> for stylistically-set-apart text with no extra importance, <i> for an alternate voice or mood. A blanket “always replace with strong/em” rule is itself a misconception; some <b>/<i> uses are already correct as written.

Mistake: “Since strong and em look the same as b and i by default, switching elements alone changes nothing.” The visual rendering staying identical is exactly the point: the fix is purely about what gets exposed to the accessibility tree, not about changing how the page looks. A sighted user testing the page visually won’t notice any difference at all after a correct fix, which is expected, not a sign nothing happened.

Mistake: “RedFlag flagged this b element, so it must be wrong.” This custom detector flags every <b> and <i> on the page unconditionally, with no attempt to distinguish a legitimate stylistic use from one that should be <strong> or <em>. A flagged instance is a prompt for human review, not a confirmed defect; some flagged elements will turn out to already be correct.

How RedFlag Detects This

Custom automated: RedFlag’s own DOM detector, runs on every scan. This check lives in extension/content.js’s runCustomRules() function (check 7): it selects every <b> and <i> element on the page with document.querySelectorAll('b,i') and flags a violation for each one found, with no further filtering or context analysis.

False positive: this is the dominant risk for this specific check: a <b> element correctly used for a stylistic label with no real importance, or an <i> element correctly wrapping a foreign phrase or a ship’s name per HTML5’s own definitions, gets flagged identically to a genuine misuse, since the detector makes no attempt to distinguish the two. Expect a meaningful share of flagged instances on any content-heavy page to be legitimate as written. False negative: the check only looks for the literal <b> and <i> tags; a <span> styled with CSS to look bold or italic, used in a context where <strong> or <em> would have been appropriate, isn’t caught by this rule at all, since it never uses either flagged element. Manual step: read each flagged element in its surrounding sentence and judge whether the text genuinely carries importance or emphasis (switch to <strong>/<em>) or is a legitimate stylistic label (leave as <b>/<i>).

Manual Testing

1. Open the page’s rendered HTML in browser developer tools and search for every <b> and <i> element.
2. For each one, read the surrounding sentence and judge whether the wrapped text is meant to signal real importance or stress emphasis, or whether it’s a stylistic label like a product name, keyword, or foreign phrase.
3. Load the page with NVDA or VoiceOver running and listen to whether any vocal change occurs when the screen reader reaches each flagged element (support for an audible difference on strong/em varies by screen reader and verbosity setting).
4. If a flagged element genuinely needs to signal importance or emphasis but doesn’t use <strong> or <em>, the check fails for that instance; a legitimate stylistic <b> or <i> use passes even though the automated scan flagged it.

Related WCAG Success Criteria

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation must also be available programmatically. Visual emphasis conveyed only through <b> or <i> styling, with no equivalent semantic markup, is exactly this failure: the emphasis is visible on screen but not reliably exposed in the underlying structure.

Related Issues

List contains an element other than li and List items are not contained within a list element share this rule’s core theme: visual structure that looks right on screen while the underlying markup doesn’t carry the matching semantic meaning through to assistive technology.

Definition list structure is invalid and Definition list item used outside a dl element cover the same “choose the semantically correct element, not just the visually convenient one” principle, applied to definition-list markup instead of inline emphasis elements.

References

• W3C Understanding 1.3.1: Info and Relationships
• MDN: The Strong Importance element
• MDN: The Emphasis element
• MDN: The Bring Attention To element