There is a potential new HTML element on the scene and its name is
It's currently only implemented in Chrome Canary (behind a flag), but once you enable it it works pretty well.
What about accessibility wise?
Unsurprisingly it does not look like a whole lotta thought has gone into accessibility considerations as yet:
- The element is not keyboard accessible so its behavior can only be invoked via clicking or tapping
- It does not expose any useful semantics in the accessibility tree
- If a
tabindex="0"is added to make it focusable, so keyboard users can interact with it, something odd occurs. Focus is passed to the page displayed in the
<portal>, and the user can tab through the page content, but the behaviour of the portal element itself cannot be invoked with the keyboard. I am guessing that this interaction is not intended as mouse/touch users cannot interact with page content.
- In terms of how it could be represented in the accessibility tree,
role=linkseems appropriate, with an accessible name of the the title of the page displayed in the portal.
- Due to the previously described keyboard behaviour, for demonstration purposes it was necessary to wrap the
<portal>element in a
aria-labelattributes off that in order to illustrate how the element could be represented in a useful and meaningful way for users other than those who it is currently available to.
- When the page in the portal opens, the user cannot currently get back to the original page (breaks the back button).
- Usability and Accessibility considerations/suggestions issue filed on the Portal spec
Anyway here is a pen for your amusement, demonstrating what has been described: