-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usability and Accessibility considerations/suggestions #112
Comments
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. |
|
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 |
@stevefaulkner Thanks for the feedback! I've filed a bug to get that implemented |
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. |
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 |
Google's example was heavily animated -- it looked like the animation was part of the browser's implementation of portals.
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. |
Portals looks like a disliked idea from most people over here: 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:
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. |
@j127 Thanks for your feedback.
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.
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? |
I'm not sure which example you're referring to, but I asked to include 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... |
Lighthouse's accessibility audit should help drive best practices around prefers-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. |
My interest was piqued by the
portal
element and through playing with it today I found some issues and provide some suggestions: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.role=link
seems appropriate, with an accessible name of the the title of the page displayed in the portal.<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.For details and a demo accessible working example refer to: Short note on the portal element
The text was updated successfully, but these errors were encountered: