v8: Ensure all other elements can't be focused while infinite editing is active (Focus/Tab lock) #4526
Conversation
… way of doing this for easy reuse in ordinary overlays too
|
Thanks for this WIP @BatJan We'll take a look when you're ready for us. Em |
BatJan
changed the title
…verlay is triggered then we figure out how to "hide" those that should not be tabable and ensure that the current one is
… clear difference between infinite overlays and modal overlays. Also adding the start of method trying to add focus to the "previous" infinte overlay in case we have multiple open and close the active one
…red but it will do for now
…e" object is returned
|
@nielslyngsoe @nul800sebastiaan @emmaburstow Ok so it's time for at little update on my progress with this one. Currently I have a working POC that acts and behaves in a better way - However I'm relying heavily on jQuery and I have 2 setTimeout functions in order to make sure I can run some DOM operations when the nodes I need to target have been set/updated - I need to find another way of doing this and I hope to have it refactored during the upcoming sunday - Fingers crossed 🤞 As mentioned I'm using a polyfill for the "inert" attribute, which is in "incubation" state currently. It's my understanding that over time this will mean it will make it into the HTML spec at some point and that browser vendors will start implementing the attribute. It's not a big polyfill so even if the attribute may not make it into the official HTML spec in the future I think it's still a valid approach to use it since it handles setting aria-hidden="true", which will hide the entire section this attribute is setup on for screen readers and furthermore it sets tabindex="-1" on each interactive element child of the parent element where the inert attribute has been placed. I have added a "focustrap.service.js" file, which contains functions for adding and removing focus traps on both "infinite overlays" but also on "modal" overlays. It turned out to be quite quick to add the method in the overlay.service.js file while I was at it anyway 😃 and locking the "tabable" fields to those in the overlay matters in both scenarios so we might as well fix it all in one go. So when using the inert attribute the default behavior is that tabbing outside the overlay is allowed in the sense that it's possible to tab to the browsers address bar so they're not completely locked to the overlay when tabbing - It's possible to break out if you want to browse somewhere else. But I'm wondering if perhaps we should add some functionality so one will not be able to tab out into the browser address bar? The current functionality is a lot better than what we currently have but I can't make my mind up about whether or not to lock tabbing to only the open overlay. I think I might like how the menu at https://24ways.org/ better - Try opening the menu by clicking the right side burger icon and then start tabbing - You're trapped in the overlay and not able to get to the browser address bar. What do you think @nielslyngsoe ? Should we aim for this or should we leave the current solution as is? (I still need to do some refactoring though) 😃 It's not possible to see it on the video when I enter the browser bar since it's cut off from the recording area so to get a sense of what it works like it might help to check out the inert attribute demo page tabbing through it? https://wicg.github.io/inert/demo/ Before Now I hope all of the above makes sense - Looking forward to any comments you may have 😃 |
…tead, which seems to be the more correct solution. Therefore removing calls to the focusTrap service while leaving the service for refernece while doing the directive
|
Good evening! Just a little update - I decided to refactor the code into a directive instead of a service since that felt more appropriate and more reusable than having a specific service that could not really be reused. But functionality wise nothing has changed in the way this affects the accessibility of infinite editors and regular overlays 😃 |
BatJan
changed the title
|
@nielslyngsoe If you have some time, might be good to provide any feedback you have on this one |
…ould have focus in case it's not setup using umb-auto-focus for instance
|
@nul800sebastiaan @nielslyngsoe - I have updated this service so it's able to put focus on the first element it finds in case no elements have been focused using the umb-auto-focus directive for instance. Fingers crossed this will make it into Umbraco 8.3.0 🤞 😉 |
# Conflicts: # src/Umbraco.Web.UI.Client/package-lock.json # src/Umbraco.Web.UI.Client/package.json
|
@nul800sebastiaan Just had a talk with Jan, he would like to solve a few issues found by Poornima before we review. |
|
Ehm... why is this closed? It's still under WIP??? 😄 @nul800sebastiaan @nielslyngsoe |
|
@BatJan Oh, sorry I guess it's my fault. We have a system that automatically closes an issue if it's being referred by a task that gets closed. I had a task on following up on this one that I closed today. But we would still love to see this begin done :-D Open again! |
|
@nielslyngsoe Thanks Niels 😄 |
|
Ok...So the last time I worked on this PR back at the UK fest in November stuff worked... But since that's nearly 6 months ago a lot of stuff has happened in the core obviously and it's not working like it used to. I think I will park this idea for now since more work will need to be done before this can be achieved in a consistent way across the entire UI. Currently it's a bit hackish as well. So this needs to be rethought so it will be simpler to make this work for every possible type of overlay that we have in the backoffice. I will therefore close this PR - But keep a link to it for reference so I can see what I did initially to load the At some point I will try to fix this again since it's really nice to be able to keep tabbing around in the overlay that is open not losing the focus - It's a huge win for UX and accessibility but with overlays being triggered from various places currently it's not easy to do well. So I think efforts should be spent aligning the overlays and where in the source they're being triggered from. And I'm of course happy to help out with this as well 😃 |
|
Hi @BatJan It would be nice to have your hint on what the challenge/difficulty is, would be a good future note. :-) Thanks in advance |
|
Forgive me if some of my comments don't make sense for the time being - They probably reflect my sleep deprivation currently 😅 What I mean is that I will be spending some time getting an overview of how many types of overlays that exists within the backoffice and then do some small PR's to align where they live in the source code, which I have already done in some PR's from last weekend's #codeconhackathon - For instance the infinite editor overlay was inside the the content area we want to "inert" - It's now living outside the content at the same place as the regular overlay making it easier to add the focus lock and inert the stuff that should not be available to screen readers etc. So in short I'm breaking this PR down into smaller ones hopefully ending up achieving the same thing in a much more solid fashion and for the benefit and joy of us all 😄 When I find some time my next move will be to add a focus-lock directive on the regular overlay and then another PR for dealing with how the directive should act when used with the infinite editor. From a quick look I think we have the overlay service and the infinite editor overlays that are widely used and then a few places seem to still be using the I hope my intentions are more clear now 😄 |
|
@BatJan No worries, and congrats with the little one, If I remember correctly... Sounds good, and thanks for spelling it out. :-) I'm all in for your plan, in general, it's all better to keep things smaller. And then we can even share the work. When you have shown the way with one of them, we can create up-for-grabs issues and then others can pick it up. Regarding the different overlays, it would be good to clean them up and simplify their usage. Feel free just to focus on the main ones, and then we should properly look into getting rid of the old ones. Making things simpler. Let me know if you need anything. |
|
@nielslyngsoe You do 😃 She is 2 months old already... And she is not to keen on sleeping 😅 You're welcome - Glad that it made sense now. I will shout if I need something and I will only focus on overlays initiated by the overlay service and the infinite editor ones 👍 (When time allows). Cheers! |
Prerequisites
If there's an existing issue for this PR then this fixes: #4525
Description
The intend is to make sure that it's not possible to tab out of the infinite overlay at first - I aim to make some reusable code, which could also be used for normal/ordinary overlays so we keep focused trapped in the overlays until they're removed again. For further details please see the description in the referenced issue.
This item has been added to our backlog AB#3405