Problem
The dotCMS Angular SDK Block Editor renderer (DotCMSBlockEditorRendererComponent) wraps every content block in a custom element around the real semantic tag. The recursive dispatcher element also renders between a <ul> and its <li> children, breaking the required list → listitem parent/child relationship.
An accessibility scanner on a customer page flagged this as excessive nested wrapper elements, violating semantic HTML and creating accessibility barriers — most visibly in list rendering, where expected <ul>/<li> structures are buried under multiple custom element layers.
Current output for a bullet list:
<dotcms-block-editor-renderer-bullet-list>
<ul>
<dotcms-block-editor-renderer-block>
<dotcms-block-editor-renderer-list-item>
<li>
<dotcms-block-editor-renderer-block>
<dotcms-block-editor-renderer-paragraph><p>text</p>Expected (clean semantic HTML, as the React SDK already produces):
<ul><li><p>text</p></li></ul>
Because this is a published SDK (@dotcms/angular), the rendered DOM is effectively a public contract — changing the existing component's output would break customers who style or query those wrappers. A new, opt-in component is needed rather than modifying the existing one.
Goal
Provide an accessible Block Editor renderer that emits clean, standards-compliant semantic HTML (no custom-element wrapper layers between semantic tags), so customer pages pass accessibility scanners and work correctly with assistive technology — without breaking existing SDK integrations.
Demo Expectations
In the demo, we will render Block Editor content (lists, headings, paragraphs, blockquote, code) using the new renderer and inspect the DOM to show clean semantic HTML (<ul><li><p>…) with no dotcms-block-editor-renderer-* wrappers between semantic tags, and show an accessibility scan with the wrapper/list-nesting findings resolved.
Acceptance Criteria
Links
- Affected component:
core-web/libs/sdk/angular/src/lib/components/dotcms-block-editor-renderer/
Problem
The dotCMS Angular SDK Block Editor renderer (
DotCMSBlockEditorRendererComponent) wraps every content block in a custom element around the real semantic tag. The recursive dispatcher element also renders between a<ul>and its<li>children, breaking the requiredlist → listitemparent/child relationship.An accessibility scanner on a customer page flagged this as excessive nested wrapper elements, violating semantic HTML and creating accessibility barriers — most visibly in list rendering, where expected
<ul>/<li>structures are buried under multiple custom element layers.Current output for a bullet list:
Expected (clean semantic HTML, as the React SDK already produces):
Because this is a published SDK (
@dotcms/angular), the rendered DOM is effectively a public contract — changing the existing component's output would break customers who style or query those wrappers. A new, opt-in component is needed rather than modifying the existing one.Goal
Provide an accessible Block Editor renderer that emits clean, standards-compliant semantic HTML (no custom-element wrapper layers between semantic tags), so customer pages pass accessibility scanners and work correctly with assistive technology — without breaking existing SDK integrations.
Demo Expectations
In the demo, we will render Block Editor content (lists, headings, paragraphs, blockquote, code) using the new renderer and inspect the DOM to show clean semantic HTML (
<ul><li><p>…) with nodotcms-block-editor-renderer-*wrappers between semantic tags, and show an accessibility scan with the wrapper/list-nesting findings resolved.Acceptance Criteria
<ul>directly contains<li>)blocks,customRenderers,class,style)@deprecatedand its output is left unchanged (backward compatible)Links
core-web/libs/sdk/angular/src/lib/components/dotcms-block-editor-renderer/