Should <portal>s be exposed to accessibility technology as buttons or links?
domenic opened this issue · comments
Currently we have exposed them as buttons (no formal spec yet, but https://github.com/WICG/portals#accessibility explains it).
Since we added default activation behavior in #223 which activates the portal, one could instead argue that they behave more like links: i.e., activating them will (by default) make the current browsing context "navigate" to a new URL. I think this meets the definition of the ARIA link role: https://w3c.github.io/aria/#link
However, as of now they fail to behave like links in some other ways. The biggest one is that they cannot currently be opened in a new tab (#215), but there are probably other minor ones, most of which are outside the realm of specs but may influence accessibility technology users' experiences. For example, hovering over them does not cause the URL to appear at the bottom of the browser, and they do not have link-like context menus.
I suppose we could fix these in a hacky way. For example we could allow opening in a new tab easily if we just ignore the prerendered portal contents and load a new tab with URL equal to the portal's current URL. (Or to its original src=""?) Similarly we could make the hover behavior/context menu behavior work by just keying off the appropriate URL.
On the other hand, I'll note that the button ARIA role does not seem to prohibit using button for link-like things, so maybe sticking with button is safest... https://w3c.github.io/aria/#button
I guess another thing we could do to make portals more link-like is changing the default cursor when hovering over them...
For example we could allow opening in a new tab easily if we just ignore the prerendered portal contents and load a new tab with URL equal to the portal's current URL.
That would be compatible with the <portal prerender> behaviour in #215 (comment), which is nice.