Matthew As far as I understand technically element is also verry accessible on the web, on the desktop and on android. However people from the community are hoping for a change regarding timeline ux when using with the keyboard and screen readers on the web and on the desktop. Other main stream apps such as facebook messenger, slack, discord, microsoft teams and similar other chat apps allow navigating on the timeline either with arrow keys or dedicated keyboard commands. Element web and Element desktop is designed in a way so this functionality is not addressed in the app and instead screen reader users are advised to use screen reader features for this. And unfortunatelly this approach turns out not to be generally acceptable by the most of screen reader users. It's great most of them are gently saying Element is more difficult to use than the other chat apps instead of saying they don't like that aspect.
From my perspective it's very tough point as we do really appreciate all the work guys working on Element are doing for us. And I don't want to show any kind of disrespect or other negative feetback as there in deed is not one we would just need to make sure this thing is going to be acknowledged and reconsidered at some point.

yes, the biggest gripe rn I have with the element clients is what has previously been mentioned, and what I tryed to outline a solution for in the past, however because I don't know frontend development, I'm not sure if it could be fezable.
The disability community is impacted by efficiency issues everywhere, simply because the context window when using a screenreader is relatively poor. Also, screenreader specific commands work, that's true, but they have been designed for mostly static web page content, so the more complicated a web app becomes, the harder it is to keep doing so and making that argument to others.
In the days of native apps, we had it relatively well, there were lots of keyboard shortcuts for things, the navigation patterns were mostly the same everywhere, and the alt menu /global menu bar made it so that most of us didn't have to navigate the whole UI to find what we wanted.
Furthermore, when using a tool which can only read one line at a time, as I said, context window is small, efficiency and eas of interaction should be a priority nowadays, because it being technically accessible is no longer enough. It may be for websites, portals you use rarely and so on, but your messaging platform on which you spend most of your free time, no, and that's why people will pick even a proprietary platform, if it's more accessible and hassle free than the free software alternatives. Not that I necessarily agree with them, I believe the foss principles are also important and a bit of pain is worth it for that, but I'm explaining why it happens.
that's why the efficiency boost back then allowed us to do things at most twice as slow as a sighted person, but rarely slower than that. Menu interactions, navigation, order of most important elements in the accessibility tree for people using the keyboard, certain most common shortcuts, etc were standardised in a way, while perhaps not by an official standards body, at least by some kind of community consensus combined with what's called prior art on the subject.
Now, what can you standardise about when opening an electron app? well, probably nothing. Sure, aria live regions, standard go by X element structurally, probably is the same everywhere as on the normal web, but the thing is, nothing more than that is known. The result, you're trying to identify elements in a drawing using python's turtle, to make an analogy.
That's why vscode and such things try to behave like native apps, so that the sr user should rarely find themselves in the situation to leave focus mode, because every time we do that, we lose on efficiency, and the importance of that not happening can't be understated.
It was one thing when we had to deal with mostly static content, blogs and such, because then we could learn where stuff is for a specific website, and navigate as fast as users with their mouse.
With dynamic, single page apps, the story changes, especially when infinitely scrollable lists are involved.
Besides the size and ram complaints, that's the second most evoked reason for which some of the community is so condescending about electron, because ever since that, apps became more and more of a slawg to navigate through, and that in turn impacts our efficiency, and even if we're not in a corporation/capitalism context, being fast at what one does, even for entertainment purposes, can't be valued enough in my opinion.
After all, no one wants to sit in front of an electron app for minutes on end just to be able to chat with their friends, play a game, edit system settings in some cases, etc. Or, to use the previous analogy, would you use the python turtle to identify controls in a screenshot of the element UI? Or, would you do the same if you had to use a monitor which is only one line tall?
About element, I want to support this here community as much as I can, plus I believe matrix to be the future, so that's why I'm recommending people to use matrix, and by that logic, element, in my community as much as I can, though a lot of people still don't want to do that because electron, they say that they have to work through that bullshit at work as well, so why should they put up with it outside that too?
So then, I do have to recognise the dedication of element to a11y as well, because except for the message list, I don't have to leave focus mode, and as such, I can claw back a bit of the efficiency from that alone, and again, that's the most important thing when designing web apps to be accessible. Does the current system work? Yes, I'm living proof of that, same for others. Is it the most efficient? probably no, and if you want to improve the element a11y, imo that should probably be the next goal.
Discord does this, I don't know about slack because I don't use it, mastodon too, and therefore I believe there should be some kind of shortcut which fixes that. Or, if it is to be screenreader commands, I recommend you make it so that the message itself is announced and nothing else when that shortcut is pressed. For example, if links would be the thing by which we should navigate through messages, then let links only show the message boddies, because otherwise, we lose on efficiency more and more, till people get tired of it and switch back to something like discord, which has the feature previously mentioned.
This is another thing I've been trying to make people understand, most probably do anyway, but still. People choose corporate platforms because it's more convenient for them, be that the discord platform, or, in the case of element, the comercial element matrix services offering. Foss should, imo, be more user centric, and recognise where the user's needs are justified, and therefore should be prioritised more. Be that with accessibility, or matrix e2ee issues, or stuff like that, barriers and friction is what prevents a lot of people from jumping ship, besides lock in of course, which is undeniably happening as well.

In conclusion, element works relatively well as it does now, but if you want to make it even better, here are afew things which should be done:

• make arrows, or some other shortcut, navigate focus between messages.
• let the applications key and shift+f10 on a focused message, activate a popup where the options of the message toolbar are displayed, or even better, switch focus to the message toolbar for that message
• make the message toolbar have vertical navigation, if the second option is chosen above
• when clicking more options on a message, then share/forward, I get to an inaccessible dialog. The inaccessibility stems from the fact that the names of the rooms are not shown, only the room avatars. This makes it impossible to share a message from one room to another
• when outside the message list, aka when I exitted a space and returned to home, alt+down arrow, etc doesn't work to switch rooms. Perhaps do that? that is one of the most important things for me when navigating unread rooms, and I guide my self by the unread counter in the window title
• speaking of that, threads...those are very inaccessible over all. I don't know what thread is unread, I just get a stuck unread counter. I don't get what room is the unread thread in, no option to jump to it, when marking a room as read, the thread should be too, and the whole interaction around threads in general is...I dk if technically accessible, but very hard to do in practice. Honestly, at this point, I'd disable threads if I could
• most widgets in a room are obscured and have to be accessed from the room info menu, then the dialog for the widget has to be dismissed explicitly by pressing on the close button, and if the widget has many buttons and such, it's a problem. Perhaps make that part overall easier to access for everyone, and also the widget dialog to be closed with a specific shortcut when done?
• screensharing has no sound. I don't know whether you can influence this, but when I screenshare in a call, I don't get the option to share with desktop audio, which is very important for us, because that's one of the ways we show stuff to each other, via calls and screen sharing with sound, because the video component is useless to us. Hmm, perhaps allow one to share no screen at all, at which point only computer audio will come through, if possible?
• since I mentioned that I use the go to next/previous unread room a lot, when the unread counter gets stuck in a room, the room shows as "unread messages" in the treeview, without saying how many. Then, the * symbol is replacing the unread counter in the title bar, and that's misleading because then I dk if I do or don't have unread messages. Perhaps ignore that state altogether?
• on android, when keys for an e2ee room are taken from key backup, and the shield symbol appears for sighted people, we can't read the message at all, because it gets replaced by something like this message can't be decripted because...something about the authenticity of the sender can't be proven. Perhaps make tb say the message first, and that the warning? since after all, the user can't do anything about the shield, and sometimes, everyone knows it just happens out of the blue because of past issues on the topic, so perhaps don't obscure the actual message by that?
• scrolling: whenever I navigate by link or whatever to read earlier messages, if I go too far in either direction, element web and desktop scrolls eratically, sometimes depositing the focus far in the past, or on the message edit box, or...anywhere within that zone basically. There are issues for that, but for the sighted, I wanted to mention the fact that it affects us too

That's about it. I'm sorry for the rant and the long list, but I sincerely hope that's everything, and that those small issues could be fixed soon enough. Then, I could recommend this to more people, and who knows, maybe some of the community could leave our specific technology behind, and switch to this instead

bgt lover Fractal addresses a lot of these as I am running it for a few days now. Are you running it too?

In reply to @pvagner:pvagner.tk

bgt lover Fractal addresses a lot of these as I am running it for a few days now. Are you running it too?

In reply to @pvagner:pvagner.tk
Although frankly speaking Fractal now has an opposite issue. There's no way on how to read a message by word, by line and similar.

In reply to @modulus:matrix.org
@bgtlover:stealthy.club: Overall agree, my solution to this is Thunderbird, but that's missing a lot of matrix capabilities.

In reply to @modulus:matrix.org
Yes, also much more responsive to the screen reader.