Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
v8: Ensure all other elements can't be focused while infinite editing is active (Focus/Tab lock) #4526
If there's an existing issue for this PR then this fixes: #4525
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.
…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
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
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/
I hope all of the above makes sense - Looking forward to any comments you may have
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
I have refactored the functionality into a "focusLockService" instead of a directive. So the following has happened
The final thing I need to look into is how to avoid reaching the address bar - I think that the 24ways.org site I referenced previously is also using the same polyfill but on their site when the menu is open focus never reaches the browser address bar.
Apart from that I'd say this PR is finally ready!
I have refactored the original POC from a directive into a focusLock service. The service is injected into the overlay.service and the umbeditors.directive where the necessary methods are being called from.
In the refactor I'm not using jQuery and the timeouts have been eliminated to only one, which is needed in order to ensure that DOM is ready and translucsions have happened.
I have checked with W3C recommendations and it is recommended to lock the focus within the open overlay. For some reason I had got it into my head that the polyfill addressed that but it does the heavy lifting of inerting/disabling background elements - Therefore a function to capture the first and last focusable element has been added.
I'm eagerly looking forward to receiving your feedback on this