Developer tools · HTML WYSIWYG editor
strong vs b and em vs i: Why Semantic Inline HTML Matters for Editors
· Why it matters
html accessibility contenteditable
Explains the practical difference between semantic and presentational inline elements, what assistive technology and search engines do with them, and how to check what your editor emits.
Bold is not always importance — choose meaning before appearance
A product code may be bold only so readers can find it quickly; a warning may be strong because its importance belongs to the sentence’s meaning. Those two intentions can look alike in a default stylesheet. Choosing solely from appearance makes the markup ambiguous when CSS changes or another reader consumes the structure.
ToolAcre’s toolbar labels its actions Bold and Italic, while the sanitizer normalizes legacy b and i elements to strong and em. That is a useful default for emphasized prose, but an editor must still decide whether the selected words genuinely carry importance or stress rather than decoration.
What the HTML specification says today — summarises the current meaning of strong, em, b and i
Strong represents strong importance, seriousness or urgency; em represents stress emphasis whose placement can affect interpretation. The b element can draw attention without adding importance, while i can mark text offset from surrounding prose, such as a term, voice or convention, without asserting emphasis.
The practical lesson is not that two tags are forbidden. It is that visual sameness does not erase semantic differences. ToolAcre’s narrow output chooses strong and em, so content requiring a merely stylistic offset may need review or a different destination workflow rather than an invented toolbar capability.
Assistive technology may expose semantics differently; this repository proves no announcement
Assistive technologies can use element semantics, but exact spoken treatment varies by product, mode and user configuration. The repository contains no screen-reader compatibility suite, so this article does not promise that strong will always be announced with a particular voice or that b will always be silent.
Structure still matters because it gives software information that a styled span lacks. Test representative pages with the assistive technologies in your support policy. A semantic element creates an opportunity for meaningful interpretation; it does not guarantee one universal audible effect across every environment.
Search effects are outside this editor’s evidence; semantics still improve document structure
Search engines can parse document structure, yet no local source proves ranking changes from swapping b for strong. Avoid turning semantic HTML into an SEO formula. Search visibility depends on content, links, technical accessibility and many systems outside this editor.
The defensible reason to use semantics is clarity and interoperability. Authors, browsers and downstream transforms can identify intended importance or emphasis without reverse-engineering a style declaration. Any search consequence should be described only with evidence from the relevant platform, not inferred from a local formatting button.
Lists that are really lists — extends the argument to <ul> and <ol> versus dashes and manual numbering
The same principle extends to lists. Three lines beginning with hyphens are ordinary text, while ul and li represent a collection of peer items. Number characters typed before paragraphs are not equivalent to ol, whose sequence and optional start value are part of the structure.
ToolAcre exposes bulleted and numbered list commands and allows ul, ol and li through its filter. Browser command behavior can vary, especially for nesting, so inspect source after building a list. Correct list semantics do not excuse missing labels, confusing order or unsupported depth in the destination.
Worked example: ToolAcre maps b to strong and i to em during filtering
Type “Stop the deployment before changing the schema,” select “Stop the deployment,” and press Bold. The browser command may initially create b, but the sanitizer’s alias map emits strong. Italic follows the same pattern from i to em. Source mode reveals the normalized result.
Now select a product label that is only visually highlighted. ToolAcre has no b-only or class-based attention control, and mark is allowlisted only through direct source editing rather than a toolbar claim. Decide whether strong is accurate; if not, use destination-specific styling outside this constrained workflow.
What this does not cover — ARIA attributes, full accessibility audits or heading structure, which is covered separately
This article does not cover ARIA, complete accessibility auditing, heading hierarchy or exact search-engine behavior. It also does not claim every allowlisted inline element has a toolbar control. Source mode can retain u, s, sub, sup, mark, small, code, kbd, samp, var and abbr when valid, but visual commands expose fewer choices.
Filtering semantic tags does not sanitize arbitrary hostile HTML for publication. ToolAcre’s tokenizer has an explicit parser-differential limitation. A server rendering untrusted submissions needs a suitable parser-based sanitizer and policy, while accessibility review must examine the final destination rather than this isolated preview alone.
Takeaway: format for meaning, then check — summarises the habit and how ToolAcre's HTML WYSIWYG editor exposes the exact elements produced
Format for meaning, then inspect. Strong and em are valuable when the prose genuinely contains importance and stress; they are not universal substitutes for every bold or italic visual. ToolAcre makes its choice visible by exposing the filtered HTML after each action.
Use the visual control for drafting, source mode for verification and destination CSS for appearance. When the desired presentation has no accurate semantic element, do not force a misleading tag merely because it resembles the design. Preserve the author’s intention in a system capable of representing it.