Closed fuck-shithub closed 7 months ago
Krzmbrzl
commented
2 years ago When you say "tabbing" you literally mean "pressing the tab key", right?
Afaik all of what you describe is the default Qt behavior, since I don't recall us doing anything special in terms of word completion and/or how to navigate chat messages via error keys.
Hartmnt
commented
2 years ago since I don't recall us doing anything special in terms of word completion and/or how to navigate chat messages via error keys.
Interesting. There seems to be a name auto complete feature, if you press TAB in the chat bar. Even in version 1.3.4. I have never noticed that before in Mumble.
The chat messages are indeed completely unreadable with a screen reader (at least the gnome default one). You can not "select" single lines or messages, so the screen reader only notices that you tab into it but nothing more.
One can get out of the chat line by pressing Shift+Tab. I have no idea if that is the standard behavior for UI, though.
Generally, this is a topic I and probably other developers in various projects are really interested in improving, but lack the knowledge and, of course, first hand experience to properly pull off. Quickly glancing at the Qt docs, they do not seem to provide a comprehensive guide. I wish this could be handled better than fixing these things as they are reported.
Krzmbrzl
commented
2 years ago I think what would be needed to improve this situation would be a direct collaboration with a hand full of users that actually make use of such accessibility features. That way we could identify issues and try to fix them and immediately get feedback on whether the fix is any good. As it stands, we're pretty much left guessing whether or not a particular change improves the situation or not.
LeeAStone
commented
2 years ago Hi I'm also attempting to use mumble with a friend using a screen reader and they are unable to see when it prompts for a password. He has experience with using and developing a11y software will attach a screen shot. The screen reader doesn't recognise the password field theres no lable for it.
He is using Ubuntu 20.04 and mumble 1.3.0
He's happy to assist in any development or testing needed.
fuck-shithub
commented
1 year ago Generally, this is a topic I and probably other developers in various projects are really interested in improving, but lack the knowledge and, of course, first hand experience to properly pull off. Quickly glancing at the Qt docs, they do not seem to provide a comprehensive guide. I wish this could be handled better than fixing these things as they are reported.
Yeah, some time ago I was making a graphical program using a GUI toolkit called IUP. After finding out it doesn't play that nicely with screen readers, I wanted to try and manually add a11y to the program, but looking around for documentation on a11y APIs from both Microsoft and GNOME has been completely helpless. The documentation is awful from both sides. No examples. Nothing. Only some vague descriptions of what each function does. Literally no one gives a fuck about a11y and it's so sad. Qt and wxWidgets devs are the only people who understand a11y APIs in this world, I bet. wxWidgets is also used by NVDA so I think they really know what they're doing. I used wxWidgets for a bit, and it automagically assigns related elements together like a label and textbox so that you don't have to do object navigation in your screen reader to get an idea what a textbox is for, which is what happens with IUP. Qt also has a11y support for both Windows and Linux, but it can get really flaky for some programs like Mumble. GTK only has a11y on Linux and is completely unusable on Windows. So I come to the conclusion wxWidgets is the only toolkit that did a11y right, probably because it uses the underlying native GUI of the OS, and probably more attention to details that IUP just can't compete with.
I've had the idea on my mind to make my own Mumble client to solve this once and for all, but there is so little choice in Mumble libraries. And since I'm a C developer, it sucks to see there's no maintained C library for Mumble.
Hartmnt
commented
1 year ago it can get really flaky for some programs like Mumble
I bet that is because the people who worked on it (including me) have only a flaky idea of a11y. This is not supposed to be a 100% commitment statement, but if I find the time in the near future to work on this for mumble, I will give it a shot. If any of you who have actual experience in using screen readers or other a11y tools would help me test any changes, that would be great.
fuck-shithub
commented
1 year ago I would love to test, although I can only test for Windows as a11y is broken on Linux (and maybe entire Unix) because GNOME is a horrible organization to manage something like this, yet they have a monopoly on X11/Wayland a11y. I really wish I could use a screen reader on Linux because as I am typing this my eyes are exhausted, oh well.
The biggest issues with Mumble's a11y at the moment is being unable to read chat history (sanely) and the settings window being completely inaccessible. When my blind friend is on my mumble server we have to come up with a different method of sending links or he has to type it manually because he can't read the chat. Also he has to use the audio wizard to make any changes to Mumble because regular settings is not accessible. I think that's because of the weird sidebar. TeamTalk uses tabs for the settings. Also iirc on TeamTalk you can read chat just by using arrow keys. It's just a big text field and not some weird read-only control like in Mumble where you have no cursor.
albertotirla
commented
1 year ago hello there! first of all, I'm glad people are trying their best to make mumble accessible, we really need an open source alternative that scratches the itch of TeamTalk, TeamSpeak and similar software. second, while I wouldn't put Linux on the highest pedestal for the 2022 accessibility awards or something, I would certainly recommend people cut it some slack. The current accessibility infrastructure we have is community maintained for so long now, basically since Sun fired their accessibility team, twitter vibes anyone? So yeah, Linux has to work with an accessibility system that's hard to work with and mostly undocumented, full of heuristics becuz there wasn't anything better at the time perhaps, over engineering hearkening back to the java days where everything was something andd then something else, etc. However, even with this system that can't entirely be replaced yet because of how many toolkits have to re implement a11y again, we're trying to make the best out of it before its time truly comes. For example, me and a couple of other people are working on a Linux screen reader called Odilia which is supposed to give the user advanced features like the windows and mac competitors, we already have some proofs of concept, not yet ready for use though. Back to mumble and the recent accessibility related patches I've seen appear in here, where can they be tested? are they in any windows or linux build? For linux, I use the flatpak, is there a channel where the new changes will be pushed? If so, I have a friend willing to test it on windows if you can tell me where to find a build with the patches, and I can try it on Linux provided there is a flatpak with them incorporated.
Krzmbrzl
commented
1 year ago @albertotirla the new changes are tracked in #5984. There is a CI that runs every time an update is made to that PR and for Windows this CI run also produces usable binaries that can be downloaded from Azure Pipelines. For Linux however, we currently don't produce any usable artifacts as we currently have no way of creating one of the static packages (AppImage, Flatpak, Snap), nor dynamic packages for that matter. Therefore, Linux users wanting to test the new changes would have to compile Mumble themselves for the time being.
albertotirla
commented
1 year ago hello, it seems the windows builds are failing, from what I've seen from the gh actions status. Of course, this means the binaries aren't uploaded anywhere, right? in that case, how would a windows build be made? I could build a Linux version which I've been trying to do for some time today, but I can't build windows binaries at all.
Hartmnt
commented
1 year ago @albertotirla Hi, I am working on the accessibility patches on and off in my free time. The branch might sometimes contain a non-working state. Anyway, there is still a lot to do and I am not sure, if we need multiple people testing the current state of the patches. But I will, if you like, ping you and others here on GitHub, once the branch is in a state that feels like a "release candidate" or something. I could then also link to the correct pipeline build and/or maybe also upload a Linux executable somewhere myself, if that is something people are interested in.
albertotirla
commented
1 year ago @Hartmnt perfect! I totally understand that, probably it's for the best in this faze, since otherwise if people don't see awesome accessibility or whatever, they might criticize mumble for deceiving people into believing that it'll become accessible while it's not what they hoped, ignoring the fact this is just a WIP for now. So yeah, sure, once thingsare stable enough, please ping me and give a link to the artefacts, at least my friends on windows can test it from automated builds. Afterwards, if you won't be able to provide Linux binaries at that time, probably I'll manage to build mumble from the sources of that branch, it was an out of memory error that got me last time anyway, so I know that tweeking the build a bit will probably fix it. btw flatpak support, if you're interested in making the CI build publish flatpaks, probably in a less frequented channel such as bleeding edge or something per pr, on demand or whatever, here's a gh action that does what you want, if you tweak it a bit https://github.com/marketplace/actions/flatpak-builder
albertotirla
commented
1 year ago any progress on this? I see the updates for mumble on flathub, however there are no accessibility fixes as far as I could see, including the fix where tab would bring me out of the chat bar, in stead of trying to suggest participants. Furthermore, the servers treeview is not tab focusable, is this a recent regression? think so, as I don't remember it from earlier versions.
Hartmnt
commented
1 year ago Hi @albertotirla
The accessibility changes are tracked in this pull request: https://github.com/mumble-voip/mumble/pull/5984 which should fix the chat-tab-problem and make navigating the server tree much better. (However, I do think it should be tab-focusable in the current version though)
The updates you see on flathub are sadly not accessibility related, but rather dependency updates as the current stable version of Mumble is still 1.4.278. The accessibility patches will land in 1.5 at the earliest. Sadly, the 1.5 release is still TBD as we had some blocking problems and one of the core maintainers did not have enough time to get around some of them. I was planing on rebaseing the accessibility changes on 1.5 once it was release, but maybe I am going to fix up the stuff that is missing for the settings page and rebase it ASAP. So at least some changes may already land in the first stable 1.5 release. I can not promise too much though, as I am currently very busy IRL and have been for the last few months.
But rest assured, the accessibility problems have not been forgotten. Sorry for the long wait. I will @ you here on GitHub once I have a prototype for testing.
albertotirla
commented
1 year ago @Hartmnt ok, thanks! I brought this up because I thought it was forgotten, glad that's not the case. Also, would it be possible to make the log area a readonly edit box or something like that in stead of a label? reading messages line by line is important, so is opening links and so on. If not, not a big problem, thought I'd ask, with the occasion
Hartmnt
commented
7 months ago a11y improvements are merged into master and will make it into the next release :tada:
If you find any other accessibility problems in the next stable release of Mumble, please each one in a new issue.
Description
Using Mumble with a screen reader is very unintuitive, making Mumble an infeasible open source alternative for blind people.
The main issues I found is that you cannot tab around the UI correctly. Once you're in the chat input field, you can't get out because tabbing will induce name completion. Getting back to the channel view is very hard and requires trial-and-error every time. Meanwhile, on TeamTalk (a very popular conferencing program very similar to Mumble and TeamSpeak that a lot of blind people use), you can get around the UI just by tabbing around: chat input, chat, channels, and menu. That's how easy TeamTalk's UI is. No weird name completion stuff that disturbs the navigation. It just works.
Also, reading chat messages is very cumbersome with a screen reader. In Mumble, you can't just move up messages with arrow keys. If I remember correctly, you had to use the numpad or some special way of going between elements (on NVDA). Meanwhile, in TeamTalk, scrolling between messages is a breeze and very intuitive.
I used to use Discord, but because Discord is spyware and centralized, I've removed my Discord account and set up a Mumble server for me and my friends. Sadly, my blind friends cannot join my Mumble server because the client is not accessible enough, and very hard to navigate with a screenreader. My blind friends are stuck on Discord and TeamTalk, but sadly I cannot get TeamTalk to compile on Linux, for some reason. TeamTalk used to be 100% proprietary, but some parts have been open sourced, yet they still cannot be compiled, so I'm guessing the developers are either still somewhat hostile, or are deliberately complicating the build process, or it's just badly coded.
It's also surprising Discord is nowadays accessible for blind users. I remember it being very hard to use with a screen reader back in the day. Wasn't it a lawsuit that forced Discord to be more accessible? Still, now with Discord being more accessible, blind users are getting trapped in the proprietary cancer.
My recommendations for Mumble would be using as much standard controls as possible, and making the UI more easily tabbable (remove name completion, or detect if user is using screen reader and then automatically disable name completion?). If you're on Windows, I recommend you to take a look at TeamTalk and their UI for inspiration on how to do it right. Please use the classic accessibility version of TeamTalk and not the Qt version. Blind people prefer to use the classic accessibility version, so that's the one you should test.
Steps to reproduce
Another challenge: Try going into the chat box and read different chat messages
Update: I recently found out from a blind friend that pressing F6 once or twice allows you to switch between UI elements just like what Tab does in TeamTalk, meaning you can move between channels, chat history, and chat input by pressing F6. The Mumble settings window and chat history are still inaccessible though.
Mumble version
No response
Mumble component
Client
OS
Windows
Reproducible?
Yes
Additional information
No response
Relevant log output
No response
Screenshots
No response