| Comparative Feature | element | element | element | | :--- | :--- | :--- | :--- | | Semantic Definition | Represents the content that has been added to a document. | Represents a range of text that has been deleted from a document. | Represents content that is no longer accurate, correct, or relevant. | | Use Case | New edits in a code, in a text, tracked changes | Document edits, tracked changes, or visual/structural revisions (often paired with ). | Outdated information, deprecation notices, old prices, or sold-out items. | | Accessible Code Pattern | The meeting is on previous date: Monday new date: Wednesday. | The meeting is on previous date: Monday new date: Wednesday. | Original price: $100.00 | | Visible Representation | The meeting is on Monday Wednesday | The meeting is on Monday Wednesday | ~~$100.00~~ $34.99 | | Unique Attributes | cite (URL pointing to the explanation of the deletion)datetime (date/time of the deletion) | cite (URL pointing to the explanation of the deletion)datetime (date/time of the deletion) | None | | Default Browser Style | By default, it has an underline but it can be changed to a bold style, put a background green to show insertion, etc. | Renders with a visual line-through (strikethrough) | Renders with a visual line-through (strikethrough) |
The and tags map to the accessibility role of deletion (and to insertion). Sighted users see these as struck through or underlined, but screen reader support for announcing these changes is inconsistent.
Under the W3C Accessibility API Mappings, these tags are programmatically mapped to specific accessibility roles that browsers expose to the OS accessibility tree: maps to role="deletion" (see HTML-AAM mapping and Core-AAM deletion role map). maps to role="deletion" (see HTML-AAM mapping and Core-AAM deletion role map). maps to role="insertion" (see HTML-AAM mapping and Core-AAM insertion role map).
These mappings instruct the browser's accessibility engine on how to expose the semantics to assistive technology. However, screen reader support is inconsistent:
Natively Announced: VoiceOver + Safari (iOS) NVDA + Firefox TalkBack + Chrome Not Announced: NVDA + Chrome TalkBack + Firefox VoiceOver + Safari (macOS)
How we provide context for combinations without native support on the Accessibility Tree
To make up for the lack of support, we should add a visually hidden text (e.g., using a .sr-only class) to provide more context about what is happening with the information.
By framing the visually hidden text as natural contextual descriptors (e.g., "previous date:" and "new date:"), the output will be more coherent and meaningful across all assistive technologies. It is recommended to avoid redundant labels like "deletion" and "insertion".
On unsupported systems: Announces "previous date: Monday, new date: Wednesday". The semantic change is fully communicated through the descriptive context. On supported systems: Announces "previous date: deletion, Monday, new date: insertion, Wednesday". This reads as a coherent, descriptive sentence without redundant verbal stuttering.
You can customize the visual representation of , , and tags to match your design system using standard CSS text-decoration properties, as well as define a utility class to hide screen-reader context labels.
To hide descriptive contextual labels (like "previous date:") from visual users while keeping them accessible to screen readers, implement a standard visually-hidden CSS class:
Clarification on MDN's Pseudo-Element Solution: MDN suggests using CSS generated content (::before / ::after) to announce which text was deleted and which text was inserted. However, I opted for another also valid solution. According to my tests, using visually hidden DOM nodes is much more reliable and stable to ensure a clear context.