Custom and Embedded Content
Standard viewtemplates have documented behavior. Project content, external systems, and generated HTML do not automatically share that behavior, so they need their own review.
The WebContent reference describes its documented configuration and rendering behavior.
Review embedded content
Embedded content is most appropriate when a standard viewtemplate does not meet the need. A clear purpose lets users understand whether they remain in the ADITO workflow or are working with a separate system. Reviewing it on every supported device variant helps identify differences early.
External or generated content benefits from its own review of keyboard operation, focus, labels, text alternatives, contrast, language, and feedback. ADITO accessibility behavior does not automatically extend inside an IFrame or to project HTML.
Suitable use
Embedded content is appropriate for a clearly bounded capability that a standard viewtemplate cannot provide. It should contribute directly to the current user task rather than duplicate an existing context or view.
A standard viewtemplate is the preferred starting point. It provides documented client behavior and reduces the separate review required for embedded content.
Responsibilities
Each project team is responsible for the embedded content it provides. This includes accessibility, data protection, security, availability, and user-facing error feedback.
The project team identifies the contacts who coordinate these topics and confirms the requirements that apply before the content is released. When content originates from an external system, the team coordinates with that system's owner.
Presentation context
Content can remain in the client when it is a short, integrated part of the current task and works reliably within the available space. Users should be able to recognise that they are still working in the ADITO workflow.
A separate browser context is the better choice for an independent system, a longer workflow, or content that requires browser capabilities outside the documented WebContent behavior. The action that opens the content identifies the target clearly so that users understand when they are moving to another system.
A usable fallback
Embedded content can be unavailable or too large for its intended area. In these cases, the surrounding ADITO screen provides feedback that explains the issue and, where possible, an alternative route to the information or task. An empty IFrame or a control that keyboard users cannot reach does not provide an adequate fallback.
The fallback is designed with the same roles and device variants as the embedded content. For example, a link that opens the external system in a separate browser context can provide access when the embedded view is not available or does not fit the device.