accessibility: element call embedded widget not in a modal dialog
Steps to reproduce
- on element logged in, go to a direct message room, or a public room but a dm would be best
- Press the video call button
- Press on element call, not legacy call
Outcome
What did you expect?
the iframe should instead be a modal dialog, either with a native html element or by using divs with the proper aria roles and navigation patterns. In particular:
- it must immediately gain focus
- pressing a close dialog button should minimise the call widget and allow us to return to chat
- the regular interface of the app beyond the modal should not be visible, to the screenreader I mean
What happened instead?
The embedded widget appears in a container, but which blends in with the UI. This may or may not look good from a visual point of view, but it makes the application harder to use
For screenreaders which support navigating by frame, this is relatively easy, go to the top of the window and press the shortcut to get there. Otherwise though, it's not a pleasent experience and makes the user interface seemn more cluttered than it already is. Furthermore, not all screenreaders support navigating between all containers, especially frames because those aren't very common, so many screenreader vendors don't think it necesary to implement a shortcut for that.
Operating system
arch linux, but that shouldn't matter
Browser information
firefox latest, updated yesterday
URL for webapp
No response
Application version
Element version: 1.11.100 Crypto version: Rust SDK 0.10.0 (3cc301d), Vodozemac 0.9.0
Homeserver
synapse, version is not applicable
Will you send logs?
No
I don't think that is feasible as the app cannot guarantee what you get when you click call is "Element Call" - the call solution is configurable in the config file, and some are just external tools with zero idea what Element is (e.g. Teams, Jitsi, etc) so you would end up with a modal which you cannot escape as the close function to jump focus back out would need to be inside the iframe.
I mean specifically the flow of hitting video call and then element call on the menu that opens, instead of legacy call, for the instances where element call as an embedded widget is configured. Also, the iframe could be inside the dialog if the iframe must be kepped, and then the close button is added by element as part of the dialog, like it does with settings. If the outline of the iframe and dialog together would be a visual issue, perhaps it could be blurred with css?
I'm not sure it'd be valid, as then you may end up with a nested dialog scenario, given Element Call has its own modal UI for settings etc. Nesting focus locks is likely to break things.
hmm, never thought of that! is it possible that such a thing would cause focus to not be recovered and essentially dropped on the floor? hmm, then perhaps the best thing that could be done in that situation is focusing a control inside the element call iframe once that menu option is pressed? because right now, what happens is focus is dropped on the floor pretty much, and it's not easy to get to the frame if the assistive technology in use doesn't support navigating by frames. Or maybe add skip to call, skip to chat, etc buttons at the top of the window, the same way we have skip to main content and similar for web pages? but yeah, that last one is most likely for another issue, I brought it up because it came to mind as a potential solution for the future
focusing a control inside the element call iframe once that menu option is pressed?
This would need to be done by EC, due to CORS we have no access to any DOM inside the iframe, it is a black box for security/sandboxing, it runs with a null-origin so that it doesn't have access to your cryptographic secrets.
Due to how the Element Call integration currently really relies on an iframe, I'm uncertain what exactly can be improved here. Do you think that the ability to pop out the Element Call widget into a separate tab or window would help make the application behave more like you're expecting?
yes, a pop out window, similar to what discord has, would be useful in this case
Thanks for the feedback, I'll look into the Discord feature (unless you have some screenshots or video or description you could share).
In the meantime I have attached this ticket to our internal product feature tracking list and we'll look to prioritising 'pop out calls' as soon as we are able to (hopefully early next year)