Thanks to the power of Antibiotics I’m back on my feet and back working on the Unity Accessibility Plugin. This week, I implemented support for popup dialogs.
If you want to start reading about the plugin from the beginning, you can find the first post here.
Popup Menus and Overlays
Not all user interfaces in an app are full screen menus with one clear list of items. There are also partial screen overlays and popup menus. Just think of a level end screen that grays out the game screen in the background and overlays itself in the front. In an app for seeing users this is easy to achieve. Simply put a full screen panel behind the popup and voila – the buttons and elements below it cannot be pressed.
Automatic vs. Manual Setup
However – the accessibility plugin can’t know that a button cannot be pressed because something is laying over it. Yes, I know, I could do raycasts and see if there is something blocking it. But that wouldn’t end up being a very clean solution. I would have to do those checks every frame on every UI component – and even then it might be tricky in special cases (which every project always has). It also would contradict the ideally very small footprint the plugin should have.
When a popup menu or dialog window opens, the expected behavior is very clear. The input should focus to that window, and that window alone.
The simplest solution I found was to simply add a little checkbox to my UI Container component: [ ] IsPopup.
This tells the plugin that the other UI elements on the screen are no longer accessible for as long as this popup is open. The plugin will then push all those elements onto a stack, and then restrict focus to the newly opened dialog. It will then get those elements back once the popup closes. All of that happens automatically. The checkbox is the only manual action needed from the developer. Seems like a fair trade off between performance, clean functionality and required manual setup.