New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tdesktop should be screen-reader friendly #476
Comments
Maybe now with the chat background option and using black or white background can do the job? |
the changes u mention might work for visually impaired users that still have sight. that could work imho. but if the user relies on text to speech functionality the speech engine would need to understand that there´s a window with text in it. i had zoomtext to test, but it didn´t even get that the window (of the tdesktop client) contained text. |
Well, for linux you have text mode telegram, idk if that can do the job for you. |
@Aokromes Those are not valid solutions for a non-Linux user, and much less a visually impaired user as well. The application needs to check and comply to address accesibility issues in the UI aspect, using the tools provided by the UI toolkit, focusing on supporting Assistive Tools. Maybe its worth checking this page in order to know how to address this issue, which is not a minor issue in my opinion. |
Guys... The iOS app isn't accessible with VoiceOver on iPhone, this app seems |
@mrkiko on Mac there's an alternative client called Telegram Messenger, you can get it in Mac App Store. It's accessible since it's done in native Cocoa UI. |
Thank you for your hints.
I am not actually a Mac OS X user, but this hint is a good one.
Thank you very much,
Enrico
|
as i ran into this again and seeing only alternatives being discussed: how about making the text messages in the active message window selectable by key strokes? i found that the contacts can be switched by this way there might be a way blind users can select and copy parts of the conversation and have them read from clipboard. right now i do not know how to this without the mouse. that would help imho. the optimal solution would still be a switch in the settings that would allow for more telegram-cli style messaging inside the tdesktop app, implicating that would produce text content readable by Zoomtext, JAWS, NVDA and other solutions. |
I am a blind windows user. One way to make the program accessible, if it is not already, is to make a Miranda NG plugin for it. Does anyone have an accessible windows client that will work with NVDA? |
unfortunately Telegram team is absolutely insensitive to these kind of problems. I contacted many times for having help with the iOs app, and I obtained only a thing: the silence. I'm really angry because I'd like to use it, many friends are there and I can't chat, use bot, because developers are not interested to bring their products accessible for visual impaired. |
@dreinn I'm afraid the only thing I can currently suggest for the desktop is to use web version at https://web.telegram.org, I hope it is completely screen reader friendly (as is the browser it is opened in). |
The web version is not accessible, either, guys, but if you are looking
for an accessible desktop instant messanger Miranda NG is the best way
to go if you use a screen reader.
…On 12/22/2016 11:08 AM, John Preston wrote:
@dreinn <https://github.com/dreinn> I'm afraid the only thing I can
currently suggest for the desktop is to use web version at
https://web.telegram.org, I hope it is completely screen reader
friendly (as is the browser it is opened in).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#476 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMj7zPTJGWoD3NnyKviBTqZ0tr3kjk1Nks5rKq6QgaJpZM4Ddx0e>.
|
#2129 is marginally related, being both a usability and an accessibility issue. |
I can confirm that, as of today (2017-04-06):
I have not tested Windows/Mac versions yet, but I suspect I already know the end of the story. As @mrkiko already pointed out, currently the best choice is to use the plug-in for pidgin, but, as far as I know, it still leaks some capabilities like message replies. I should note that I haven't experienced issues like these when using other messaging apps, including Google Hangouts, Facebook Messenger and even WhatsApp. If we want Telegram to be a great app, then we shouldn't allow this kind of behaviors to happen. |
I can confirm without a shadow of a doubt that the windows application
is not accessible to either JAWS OR NVDA. I have not tried the web
version yet on windows.
|
I have a few little tidbits to add that isn't exactly related to Telegram itself, but comes from my experience with screen readers and GUI frameworks. At my day job I work on a GTK based app (which is of course a completely different technology than Qt), and we worked together with a few blind people to get the UI navigation right. They can't use mice, so there has to be full keyboard access with shortcuts for everything they'd want to use (there can be features a blind person won't want to use), and all the widgets involved must have accessibility metadata on what they are so the screen reader can tell them more than just "Entry.", "Combobox.". Accessibility goes way beyond serving the blind. But even the considerations for the blind users can have a positive impact on those with no visual impairment at all: the shortcuts (even on items a blind person doesn't use, eg. the gifs) make it easier for everyone to access things. There's also a lot of other disabilities that behave rather differently: visually impaired users typically do use the mouse and don't use screen readers, they just need special contrast or really large UI. Physically disabled people might have a bad time with precise pointing with the mouse, so keyboard navigation helps them. Deaf and hard of hearing people have no input hindrances, but they can only use visual alerts. It's an effort, but it's usually worth it. There's a catch though, and that's technological. At my day job we cannot switch from GTK so we're stuck to only supporting screen readers on Linux (Orca in particular) — as GTK is rather... lazy and hasn't implemented interaction with Windows's or macOS's accessibility layer at all. In short, Jaws or NVDA see an empty window and will read nothing beyond that. Qt has taken more care of this (and is actually worse on Linux instead although by default it navigates a lot better with the keyboard than GTK does), but I have no personal experience in how complete that support is; and what little I know about it is about classic QWidget GUIs, not Qt Quick ones. But as I said, there's a lot more to accessibility and usability than screen readers. |
Hey there! We're automatically closing this issue since there was no activity in this issue since 420 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked. Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue. Thanks! (Please note that this is an automated comment.) |
@tdesktop-closer |
Interest wasn0t lost.
|
No, i identified an issue in the code and wrote direct email to a developer.
…On 1/1/22, Vsevolod Popov ***@***.***> wrote:
Hello Beqa,
Thank you for your answer!
I will try that out!
Did you report the issues about webz version to telegram's bug tracker?
I ask that because if the issues were addressed, then it could be a better
way to report bugs there.
Thank you!
--
Reply to this email directly or view it on GitHub:
#476 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
--
with best regards Beqa Gozalishvili
Tell: +995593454005
Email: ***@***.***
Web: https://gozaltech.org
Skype: beqabeqa473
Telegram: https://t.me/gozaltech
facebook: https://facebook.com/gozaltech
twitter: https://twitter.com/beqabeqa473
Instagram: https://instagram.com/beqa.gozalishvili
|
Hi, |
Honestly? You're just hoping, I feel. Put your time and money into accessible apps like TweeseCake or go a step further and suggest everybody you know move over to XMPP and stop using Telegram. Your best bet will be to, either, take it up with your countries accessibility laws, or support third party developers that are actually caring but are not given the money, nor feedback. They had some improvements on iOS, but for years, Blind people had to beg and beg and beg. I'm done begging. I'm gonna file a CVAA complaint in my country soon, because this counts as a communications app. In the meantime, I'll continue to use XMPP. |
@rkingett Unfortunately, I too have long felt that this is just a hope, but to switch to another application, no thanks. Unigram has been working very well for me for a long time now. I just wanted this official app to be accessible, although if they don't care, well, there's nothing to do. |
also, idk c++ i only close duplicated tickets. |
@rkingett I'm really impressed with its accessibility. Downloaded, started using Telegram and really works very well, so thank you for introducing me to this wonderful software. |
Hell, I'd encourage yall to just use Matrix. It can be tricky to set up but at least it works (though it does have a few very minor accessibility problems, but at least Matrix listens to feedback -- there's even a dedicated accessibility room and they're working on assembling an accessibility team with CI/CD integrations). It supports bridging to telegram, but I wouldn't do it if I were you -- the last time I did it telegram banned my number because they somehow thought I was spam (though I have no idea where that logic came from). Good luck @rkingett on the CVAA complaint -- I can't wait to see what happens! |
@ethindp Meh, too lazy to do this, because Unigram works pretty well for me, now this TweeseCake works very quickly, so I really don’t want to give Telegram a reason to ban the number🙂 |
telegram ain't whatsapp or signal, they allow 3rd party clients on their network. TweeseCake works quickly... because for sure it uses web.telegram.org |
Yeah, it was said multiple times that it's very, very, very difficult to do. tdesktop is written with custom widgets and pseudo-widgets (widgets that aren't QWidgets and can't have their own accessibility handling therefore). It's unlikely tdesktop will ever support accessibility as it's probably easier to rewrite entire application than implement accessibility in tdesktop. There's no plans for a rewrite AFAIK, though. |
Here's the thing. Telegram desktop accessibility is actually possible. Using object character recognition, you can read the current text the keyboard is focusing on. Pressing tab in some cases will let you navigate between different tabbed interfaces on a single page. Such as when entering a different country code and phone number to sign in. the problems begin when the intuitive nature of accessibility is broken when reading the GUI using cursor navigation from the keyboard. For example, arrow, tab and applications keys respectively. These bring up related contextual menus that coincide with user choice specific options available based on app features, similar to right click. The problem is not necessarily with the GUI, but with the way in which the operating system, Mac, Windows, Linux, deals with API handling of certain programming interfaces itself. For instance, say you wanted to open a chat window for a user called John. Normally, in an accessible interface, when telegram opens, the first thing you see, is a list of recent chats, where John's name can be located. Then you move your mouse over to his name and left click to open his message window. A keyboard user, would tab to the recent chats list, and then press enter to perform the same action. When a screen reader user does this on a PC, they're interacting with a retrieved short cut list of actions the accessibility API itself sends back to send user as if it were a list of virtual short cuts to commands sent to the program to communicate with the locally stored cached version of possible events a user wishes to choose from, like searching, accessing a menu and so on. The issues of telegram Desktop's accessibility layer, stem from being unable to send data to an accessibility API available to hook into the graphical user interface Telegram Desktop exclusively users to navigate local user options. Like finding John's name in a list of recent chat windows for example. All Telegram would need to do, is like on mobile platforms, add the ability to work with a secondary layer of accessibility support, that grabs onto an accessibility API for screen readers like NVDA, JAWS and Orca, to send the possible list of commands that are locally cached to the screen reader to process. It will then be able to handle user choice through pop up menus, rather than relying on the program to display available options through its own GUI. And this can use the local Linux, Windows and Mac operating system specific system APIs to do this. Freeing up the final result to be sent back into the telegram application itself for processing. This ensures that sighted users can still use the app normally, without any requirement to navigate the computer by keyboard, but instead have separate system APIs to handle mouse and keyboard input. In this way, it may add a bit of extra code overhead, but won't negatively impact the performance of core functionality. Telegram Desktop developers simply have to choose an accessible, localized secondary accessibility layer, to work with their native applications, to ensure compatibility remains up to date. These don't tend to change once they are implemented much, accept for when program libraries and their dependencies update themselves over time. The same is true on the web app side of things. You can choose to have HTML5 elements for the keyboard, and for the mouse, anything using a remote Javascript sequence if you wanted to without losing core functionality. Which is how the web legacy app version worked before K and Z were introduced as more featured, but less accessible client versions of telegram messenger. This can be solved very easily, by allowing for multiple API input support based on different access requirements depending on whether or not a user has a keyboard or mouse. Mobile platforms already utilize this functionality by enforcing this be the case accept for when most gestures are utilizing full screen access, as in the case of games. Telegram messenger for blind people works more like a bot, than a touch screen. Custom keyboard shortcuts are a cheap workaround for this functionality to start with, if an appropriate API can't be found. Yet it is needed to truly call telegram desktop a fully featured client. |
Hey, I am interested to solve this issue for GSOC'24 |
I thought one can solve issues only in affiliated projects of GSoC and Telegram is not one of them, no? |
How do you want to do that? What area of accessibility would you like to look at fixing first? |
Might be easier just to use AccessKit. Build the accessibility tree that way. |
The most logical thing is to use Qt's accessibility features as that's what the widgets are written with after all |
friends, I'm Nalin, representing Zendalona. We're excited to announce our participation as a mentoring organization in GSoC 2024. One of the projects we've listed on our idea list is the development of a Telegram Accessibility feature. If you're interested in working on this project, please reach out to us promptly. You can find more details on our GSoC page at www.zendalona.com/gsoc. |
@Nalin-x-Linux if you want to coordinate with tdesktop, you better reach @john-preston privately via https://t.me/preston as he rarely reads github |
a similar argument was made earlier ...but gn the way the chat widget is designed its considered impossible for screen reader to know the chats...
|
I am interested in resolving this issue...I have already built tele in my system..If anyone has any leads or suggestions on how to resolve this, I would greatly appreciate it... |
Why isn't it possible? I don't quite understand your sentence, 5.15 is greater than 5.11... |
@Aokromes I know they allow 3rd-party apps, but it didn't stop them from banning my number a couple years back for no apparent reason. As for making TDesktop accessible? Sure, you can make the QT ones accessible, assuming you can figure out the QAccessible interface. But if it uses pseudo-widgets as mentioned, have fun trying to implement accessibility for those. Your only real options at that point are to use accesskit or to interface with the low-level OS accessibility APIs, I think, and that may or may not conflict with what QT gives the system (might be wrong about this one). (This is exactly why you should avoid custom/pseudo-widgets in general, IMO... If QT provides what you need, why not just use that? What do the custom widgets provide you that QT doesn't and that you can't just add yourself via subclassing?) |
It provides, yeah, the problem is that's too much of work and apparently the business doesn't give the priority to this (if that's on their board at all, can't know, I'm a 3rd party contributor). Apparently, those user attracting features are way more important to them, and as far as I know, they take more than 100% time of the hired dev (as far as I understand, not all the features get finished at the required deadline) and there's just no spare time to anything else. The main problem with tdesktop is it has lots of technical debt (lacking features released long time ago like secret chats and having problems like the lack of hidpi multi-monitor setups support due to bad UI caching architecture so lots of rewriting is needed, lack of accessibility and etc, etc, etc), not enough contributors for things requested NOT by the business (the ones on github) and it's apparently good enough for the business to ignore those problems. Fixing all of this would apparently mean the business would have to stop releasing new feature releases and allocate multiple months to get all of this fixed which might be not acceptable from their PoV (it might be way easier to drop tdesktop and claim Unigram/Telegram for macOS/Telegram Web A/K in Electron as the only official desktop clients). |
The methods at https://doc.qt.io/qt-6/qaccessiblewidget.html are all virtual, including those like |
hi there,
i´m a very fan of telegram and i use it on lots of devices. great job for the lightweight feel of the messenger.
i wanted to introduce telegram to a blind user but had to realize, the (windows) client is not good to use with a screen reader, i.e. zoomtext of aisquared... the software does not even understand what to do when using the "read this" command and selecting a portion of the telegram chat window.
idk, but maybe this is only a small fix so the chat messages are understood as text inside a frame and the message input field is treated like an textarea (which would be readalout while typing).
it would increase for accessibility of that otherwise modern chat system.
i tried the web version of telegram which is not usably for the blind either. at least the message text is recognized then -> "read this" command reads the chat but still the user would need to select the correct portion of the chat. is there are plain-text only version of the web app available?
best regards
The text was updated successfully, but these errors were encountered: