Usability and Accessibility considerations/suggestions

[stevefaulkner]

My interest was piqued by the portal element and through playing with it today I found some issues and provide some suggestions:

• 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 behavior 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 behavior, for demonstration purposes it was necessary to wrap the <portal> element in a div and hang tabindex, role and aria-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).

For details and a demo accessible working example refer to: Short note on the portal element

[jfrazzano]

I am not sure if its the same issue in re:focus on tabs in a nested context that I had using slots and tabs, or something similar to the context issue noted on w3c site in re focus and radio groups nested in toolbars, see: https://www.w3.org/TR/wai-aria-practices/#change_log_2019_january,

I used a tail call on my current array of items to sendfocus to the next region, if predictable, otherwise, I mapped the space and just popped focus to the next region--based on the the direction the arrow pushed and the VISUAL representation--x,y,left,right of the context. With slots, this is more or less essential, as the dom tree can be chaotic.

[lucasgadani]

• You are correct, at this point, we are not supporting input events in a portal. In the current implementation in Chrome Canary, only mouse events are disable, it's still possible to navigate the portal by focusing with the keyboard, but there's a tracking bug to completely disable keyboard events (https://crbug.com/932581). By not supporting input events at this time, we simplify a lot of the potential security issues that must be handled, and allows us to focus on the features that would bring the most benefit to web developers.

• As far as the question of whether the portal contents should itself be part of the accessibility tree (like iframes are), I'm not sure the way we should go. Since they aren't interactive, would it be useful for a screen reader to read it's contents? Or should we treat it more like an image/link?

• For the back button issue, this work-in-progress and current tracked at Portals and Session history #19.

[stevefaulkner]

@lucasgadani

As far as the question of whether the portal contents should itself be part of the accessibility tree (like iframes are), I'm not sure the way we should go. Since they aren't interactive, would it be useful for a screen reader to read it's contents? Or should we treat it more like an image/link?

I wasn't suggesting that the content of the portal page be exposed in the accessibility tree (although it currently is), only that the semantics of the portal element be exposed so it is meaningful/usable for AT users.

[lucasgadani]

@stevefaulkner Thanks for the feedback! I've filed a bug to get that implemented
in Chrome (https://crbug.com/961038).

[j127]

Animation is another accessibility consideration. There should be a way to turn off the animation for people with visual motion accessibility difficulties (including some people with vestibular disorders, autism, etc.). Unexpected animation that simulates physical motion is not accessible.

Overall, the whole idea of portals sounds like "Embrace, Extend, Extinguish" -- it changes the fundamental nature of the Web as linked documents. It looks like it's a Google-only feature that will increasingly make it so that we see "this 'website' only works in Chrome". In my opinion, it's a terrible idea. If people want that kind of awful UI on their site, they should write their own JavaScript code for it.

[jeremyroman]

Animation is another accessibility consideration. There should be a way to turn off the animation for people with visual motion accessibility difficulties (including some people with vestibular disorders, autism, etc.). Unexpected animation that simulates physical motion is not accessible.

The portals feature itself doesn't do any animation. We expect that developers will use them when appropriate, and it would make sense for developers to use the prefers-reduced-motion media query to determine whether to animate their transitions, much like other behavior in their applications.

[j127]

Google's example was heavily animated -- it looked like the animation was part of the browser's implementation of portals.

We expect that developers will use them when appropriate

Developers (and marketers) won't be responsible with this kind of feature. It looks like it's going to be the new "can you open all external links in a frame so that users don't leave my site." That was a regular request from website owners 15 years ago.

[j127]

Portals looks like a disliked idea from most people over here:
https://news.ycombinator.com/item?id=19866584

It's going to hurt small sites the most, because sources of traffic like Google, Facebook, and other large sites will eventually stop linking to websites, and load them as previews in frames ("portals") instead.

Portals are much worse than it appeared from a first glance:

"Google engineers hope that their new Portals technology will take over the web and become the standard way in which websites transition between links."

It definitely looks like a case of Embrace, Extend, Extinguish to the WWW -- "No other browser vendor has expressed interest in supporting the Portals" -- but Google is already releasing it in Chrome anyway.

[lucasgadani]

@j127 Thanks for your feedback.

It's going to hurt small sites the most, because sources of traffic like Google, Facebook, and other large sites will eventually stop linking to websites, and load them as previews in frames ("portals") instead.

Our intention with this proposal is quite the opposite of that. One of the main motivators for this work was a W3C TAG recommendation from 2017: https://www.w3.org/2001/tag/doc/distributed-content/ . Basically, one of the main issues we are trying to fix is the issue of origin attribution for content aggregators, such as Google, Facebook and others.

Today, things like AMP top stories are served from AMP CDN, because the web does not have a way to provide fast, instant preloading of these pages. Providing a way to enable these better user experiences, with faster preloading, animated transitions and proper origin attribution was one of our goals when designing this proposal.

It's very important to keep in mind that once a portal is activated, and the proper origin attribution is displayed in the URL bar, that page is ultimately in control. That includes running script, all aspects of layout and rendering. Essentially, it should behave exactly as if the page had been navigated using an link. That's why I say that our intention is the opposite of keeping the users under the aggregators domain -- we want users to transition to the actual pages, with all of the benefits and responsibilities that comes with it.

"Google engineers hope that their new Portals technology will take over the web and become the standard way in which websites transition between links."

It definitely looks like a case of Embrace, Extend, Extinguish to the WWW -- "No other browser vendor has expressed interest in supporting the Portals" -- but Google is already releasing it in Chrome anyway.

Nothing is being released right now. What we currently have implemented in Chrome canary is a prototype that can be enabled under a special flag, so that web developers can experiment and provide feedback during the development phase, where we can incorporate new ideas to the proposal and improve the current design. We are still in early stages, but we are committed to doing all the development in the open, following the normal standards procedure and welcoming feedback from the web development community as well as the other browser vendors.

I'd be happy to continue this discussion with you if you wish, but would you mind filing a separate issue so we don't hijack this issue which tracks accessibility for portals?

[Malvoz]

Google's example was heavily animated

I'm not sure which example you're referring to, but I asked to include prefers-reduced-motion for the https://web.dev/hands-on-portals/ example code.

It'll be interesting to see how many developers conform to these accessibility practices. Can't help but feel sorry for those with motion sickness...

[KenjiBaheux]

Lighthouse's accessibility audit should help drive best practices around prefers-reduced-motion.
I did a quick check but it seems that there isn't any check for prefers-reduced-motion at the moment. Lighthouse is using https://github.com/dequelabs/axe-core so I'd suggest filing a generic request for audits around reduced-motion.

There could be other opportunities down the road, e.g. making sure that libraries facilitating the use of Portals make good on respecting prefers-reduced-motion.

@j127 when a Portal gets activated, it also gets to decide whether or not it wants to create a composed experience with its predecessor. Similarly, if a website doesn't want to be embedded in a Portal, it will have the ability to say so. The API doesn't force anything on anyone. If the parties involved identify a mutual benefit for their users, then they can choose to collaborate and create these better user experiences.