Short note on the portal element
There is a potential new HTML element on the scene and its name is <portal>
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=link
seems 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 adiv
and hangtabindex, role
andaria-label
attributes 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: