Slack also has other problems that have been totally ignored and neglected for years. One of them is accessibility. The app is impossible to work with without a mouse. They say it is "keyboard driven" and they keep adding features that ignore keyboard completely. Have you ever tried to jump to a thread without using the mouse? Or copy a link to the last message? Or share it? Or ask Slack to remind about it? Or snooze all notifications? They could at least put them in the main menu. People with disabilities who rely on things being in the menu, they can't do any those things. Can you imagine having to hire someone and they'd be like: "Ah sorry, I have to tell you something. I cannot use Slack app. I hope that's not a deal breaker". I wouldn't be surprised if someone sues SlackHQ for being discriminatory.
Blind user here. I find Slack impossible to use. With more and more communities moving from IRC to Slack, I also feel the exclusion these days. Technologies/Companies like Slack make me wonder how long I will be able to usefully participate in the tech online. Watching how accessibility is systematically forgotten these days, I am not very hopeful.
I spend at least a few hours every week talking & gathering feedback from customers with disabilities. What I've learned, beyond the fact that our screen reader experience is not great (yet), is that we're not doing a good-enough job communicating the a11y improvements we've made. And because of this some users (particularly screen reader users) are sticking with the work-arounds from back in the day when our a11y support was indeed worse.
If you feel like it please write in to feedback@slack.com and we can set up a meet. I'd love to learn what we're doing wrong and potentially go through the support & improvements we've built.
This article should help as well. It's documenting not just the shortcuts but also how to perform different flows.
How accessible are open-source slack competitors like Mattermost?
I feel for you. I'm blind in one eye and am at a pretty high risk of going blind in the other because of it. I do my best to make sure the things I build are accessible; it's a real shame that accessibility is typically an afterthought.
We made a bot for slack which provides voice summary for web pages, it is invoked by @larynxBot [URL] to get the audio summary of web content right inside slack[1].
I didn't specifically target this as utility for visually impaired users(as we weren't able to test with such users), but was under opinion that it would help them if someone from the team shared links with our bot.
Reading your comment & that of others reg accessbility on slack makes me wonder if even when audio summary of URLs is received, whether someone with accessbility issues can click the player button.
Blind users already have their favourite screen readers. There is almost zero need for custom audio summary or alike features. Those are feature from sighted people for sighted people. But they have almost zero relevance to people relying on accessibility.
To answer that, I'd need to know what you actually mean by summary. Most screen readers present an overview of the number of HTML elements in a page when it just loaded. Something like "5 headings and 28 paragraphs".
Why would you want to provide audio summary of a page in the first place instead of providing a text summary? Reading text is about 2.5 times faster than listening to speech. And regardind accessibility, blind people can use their screenreader to get an audio version of the summary.
On the same topic: your landing page does a bad job of displaying what your app does and why it is useful for me as a user. I had to watch the "how to use" video to get an understanding.
larynxBot is part of the larynx platform, where one could share any content along with their own voice.
Users who received larynx content said they liked the voice summary of web content which their contacts sent to them & asked for a feature to summarise web content on-demand.
Hence, we released it as bots for Messenger, Telegram, Twitter & slack. I agree that the website portion of larynxBot can do a better job at explaining it.
Hi mlang23. The Slack screen reader experience isn't perfect but we've made significant improvements that it's usable, according to our testing & talking to screen reader users working for our customers. My colleague, and until recently our biggest critic, has documented our accessibility journey here (from a user's perspective, of course): https://marcozehe.wordpress.com/2016/01/16/status-of-the-acc...
I would like to flog a (still live) horse and point out that Discord is even worse. I would even go as far as to say that Discord’s design is aggressively thoughtless for the visually impaired.
My company uses Discord for comms and I’m active in several Discord communities, but my vision impaired co-worker isn’t. Not because of a lack of want, but because Discord has been coasting on accessible design for years. https://www.reddit.com/r/discordapp/comments/4tn00z/when_wil...
Everything takes more resources than we expect, but surely a theme for their client (we do have some proof that it is theme-able) that is friendlier for screen readers shouldn’t take more time than an entire games store?
For me, the big takeaway from hearing about Slack’s issues and contrasting it with Discord is that people just don’t seem to care. And that’s often the status quo until an Apple comes along. We forget this, but back before the resurgence of Apple, design was an afterthought, not a forethought even though there were obvious gains to be had and a better future to lead towards. But the vast majority of companies avoided the obvious win until Apple’s stock price shocked them into caring.
A significant fraction of everyone’s user base (including the core users) would benefit from accessible and thoughtful design, because like the article says, we’re all disabled sometimes. Now, we just need to figure out which company will have to show the world how to do it.
Discord also has a record of cracking down on 3rd party clients, so if someone wanted to make a more accessible text-based replacement for their electron app, they can't.
Most UI designers don't care about accessibility either. In fact, I would say that many designers have aesthetic preferences that are actively hostile to accessibility.
> I would even go as far as to say that Discord’s design is aggressively thoughtless for the visually impaired.
I'd take that further. Discord's UX drives me to despair. It's like no other chat app (which is my basic use-case). Multi-party voice is awkward, much of the interface doesn't lend itself to self-explanation, etc.
edit: The reason for using discord vs anything else is the need for a voice chat app in-game since some party members have issues with steam, and what other decent options are there that don't require self-hosting?
My name is George Zamfir, I'm the Accessibility PM at Slack. I recorded a quick gif that shows how Slack works by keyboard, which covers the scenarios you mentioned as well.
Here's a quick description of what's happening in the recording:
The following is all you need to get around Slack by keyboard (and as an extension, with a screen reader):
F6 to jump around the large UI sections, TAB for going through focusable elements, UP/DOWN for reading through messages in the message list / threads pane / Search / All Unreads / Threads, PGUP/PGDOWN/HOME/END to scroll through messages.
And lastly Search (`Cmd / Control + F`) now also allows jumping to users / channels / workspaces / etc. on top of regular search.
Thank you for this comment. Indeed it shows that you guys do care. I did not know about <F6>. Can I make a few suggestions?
- Would it be possible to duplicate <F6> so it can be initiated without having to move one's hand? Also latest Macbooks don't even have F-keys.
- When in F6-mode, would be nice if it was possible to navigate using h/j/k/l (Vim users would appreciate)
- Also would be nice to be able to start (jump to) a thread in F6-mode by pressing a key, maybe <T>, or react with emoticon by pressing <R> maybe? Having to press <Tab> multiple times is not only annoying, it's inconsistent - when you are in a thread there are different actions compared to when you are not.
---
I have played with F6-mode and tried navigating with it. It is still quite difficult to use the app and you are still forced to use the mouse. And I'm not even visually impaired. Can you imagine how hard it is for people who are?
In general, I wish PMs at SlackHQ were forced to use Slack app once a week without a mouse - where only keyboard is allowed.
Indeed. I worked with a fully blind colleague(who ironically did accessibility testing..) - it made me so sad he couldn't participate in all the stuff on Slack. I mean yeah he'd get an email if it was important, but surely he must've felt excluded frequently.
> Indeed. I worked with a fully blind colleague(who ironically did accessibility testing..)
I don't know that that's ironic. Doing accessibility testing without significant impairment is very, very difficult, because you take shortcuts an impaired user doesn't get to use without even realising it. An impaired user can "just" try to use the software and they'll smash their face straight into all the roadblocks and sharp edges.
For blindness it is relatively easy to simulate for a sighted person as long as the blindness they are trying to simulate is total rather than partial, just turn the screen off.
But a sighted user will be much less proficient at using anything like that, so it is probably better to find someone who isn't sighted and so does everything like that. Otherwise it will take far longer to recognise any issues
> But a sighted user will be much less proficient at using anything like that
Not only that, but they'll be stumbling around not really knowing how vision-impaired users actually work with their devices, so they would have issue an impaired user would not have, and not hit issues an impaired power-user would.
They're big enough for this to become a legal issue at some point. It's a shame if it had to come to that, but the broad adoption would create a strong case. Personally, I take pride in developing applications that accessibility-friendly. Because even I don't want to use a mouse sometimes -- it benefits sighted users too, and anybody who wants to work more productively without the mouse.
Before a case like this would ever go through and have a positive effect, thausands of vision impaired people worldwide have already lost their job or could not begin a new one because of lack of accessibility of these platforms. The damage has already been done / is ongoing. And disable people already have a hard time finding a job. So this damaging to those that already have a hard time to cope in our society. Slack and Discord are actively toxic. And nobody cares / waits for a court ruling. That is why I said I dont see much light here. The tech industry is in the process of selecting out those that have visual disabilities. Not just because of Slack and Discord. The general trend of moving everything ith browser is death by thausand cuts for people with visual disabilities. It doesnt matter if I am forced to use Slack or SharePoint, or your favourite commercial issue tracker. Almost all modern pwb based products reduce my productivity to almost zero.
You wouldn't be suing your company. You'd be suing the company the makes the software your company uses. There'd be no political risk at your employer.
I'd imagine the first step would be a quiet word with HR. If they are in any way good at their job, they will do the work for you, as their job is to protect the company from tribunals.
Press Ctrl+K or Ctrl+j shortcut to go to a chat, then the text field isn't even focused! FFS what's the point of the shortcut then, if I have to grab the mouse to click on the input anyway, just to get back to the keyboard immediately.
> Tab gets you there. maybe not fast, but it does.
People choose keyboard-centric workflows:
a) For efficiency (if it takes a few milliseconds to press a key, why would you even reach for the mouse?)
b) For accessibility
Your point is not helpful for any of these cases. Asking to try to use Slack App with a blindfold might be a bit extreme, what if I suggest you to try to use it for a few hours without touching the mouse? How's that for a challenge? Try that and maybe then you'd feel how it supposed "to get you there" for people with disabilities.
> The app is impossible to work with without a mouse.
It is, in fact, not.
I disagree that it's super difficult, but even if so, difficult is substantively different than impossible.
You, on the other hand, decided to pretend I said something I didn't so you could be indignant and tantrum at someone who... doesn't work on Slack and makes zero decisions about what to implement in the Slack app.
Alright. You are right, I re-read my reply to you, my tone indeed looks indignant (wasn't my intention), you haven't said anything that merits such tone, I apologize for that. But I stand by my words: Slack app is impossible to work with without a mouse for people with disabilities. The very first reply to my original comment confirms that.
Slack dev here. We've actually fixed quite a few accessibility issues over the last year or so. There's still a ton to do, but if you haven't used Slack with a keyboard recently, give it a whirl.
I used recently and it's impossible to use with keyboard only, you can try yourself.
During duty shifts I was helping our support. The incoming flow of requests had peaks of ~3-4 situations per minute, all as messages in Slack channel, needed to be responded in newly created thread each. I've come up with a flow, but I cannot avoid mouse at all.
Slack just does not have enough key bindings to be used without mouse! Slack was a bottleneck for me.
If you are not willing to invest into UX that's fine to have gateways for people to use whatever client UI they need. But you just cannot wear to hats by both removing gateways and avoiding investing into your client UX. Result is plainly awful.
Nothing personal, I am actually hate using Slack, sad to say that. I will avoid using Slack in current state at all cost whenever I can.
Good luck to you! Hope you will make your product better!
SlackHQ, we are software developers, devops and QA engineers, data scientists and IT support specialists - we are your biggest user base!
When we say it is not working, please, listen to us.
Please, do try using your app without the mouse and maybe then you will see what we are talking about.
It is not a baseless demand, our companies pay to use your service. If your codebase was open-sourced we would've fixed this issues ourselves.
Please, don't make us hate you. When you just started you were awesome, but now you are slowly turning into Atlassian.
If you're allowing your client to be multi-protocol then why is Slack's protocol unsuitable? You can use weechat with the Slack API right now and it works great.
The market for 3rd party applications using Slack is huge.
We need a federated communication protocol, similar to email, where we can have real-time communication with people and groups on various networks and using differing software.
You really should be building with a11y in mind from the get-go. It's 2019. The tooling is much, much better than it was in years past. It shouldn't be impossible for any enterprise to make a reasonably accessible application.
Nobody even expects 100% perfectly, semantically correct HTML documents. And it takes relatively little work to get reasonably good support. Like anything, the investment has diminishing returns but the 80/20 rule applies.
>Have you ever tried to jump to a thread without using the mouse? Or copy a link to the last message? Or share it? Or ask Slack to remind about it? Or snooze all notifications?
I'm not sure these are issues?
* Not sure what "jump to a thread" is referring to, but you can step through top-level messages with the cursor keys and use <Tab> + <Enter> to activate the "n replies" link.
* You can focus the relative timestamp link (it's got a sensible tab ordering) with the keyboard and then trigger the browser's context menu to achieve this.
* The message's context menu is also tab accessible. The "More actions" link is aria-label'd as you'd expect. You can navigate the subsequent context menu using the keyboard to select "Share message".
* Snooze/remind are accessible via commands, as well as menus which are accessible as described above. The commands are documented in the help.
Have you actually tried using Slack App without a mouse or a trackpad? I mean when I said "impossible" I didn't mean literally. Keyboard driven workflows are meant for fast, precise actions that are suitable for situations where you can rely on muscle memory. That's why POS terminals usually built with a keyboard focused interface. Can you imagine a cashier, holding a whole line because it takes her several minutes to undo a transaction, because she tapped/clicked with a mouse on a wrong item?
SlackApp, unfortunately doesn't allow you to be efficient, because it's not meant to be used without a mouse. Telling that it is, because you can press <Tab> multiple times and get where you want to be - isn't a solution. First, it is inconsistent - number of times you need to press <Tab> varies from the context you are in. And because of that it is not only inefficient, but it is also limiting for people who have no choice but to stick to using keyboard. And for people with disabilities it's pretty much literally impossible.
>Have you actually tried using Slack App without a mouse or a trackpad?
Yes, I tried before I wrote my comment :) My experience informed everything I said.
>SlackApp, unfortunately doesn't allow you to be efficient, because it's not meant to be used without a mouse.
I don't disagree it's probably primarily built with mouse users in mind. But nobody here is concretely discussing what Slack (and by extension, all web apps) can do to make their applications more accessible.
>First, it is inconsistent - number of times you need to press <Tab> varies from the context you are in.
Surely this applies to every application? The number of tabs it takes to get to the address bar in my browser varies based on the current element that has focus. Same for my word processor. How is this supposed to work?
In browsers you can install extensions that can help to navigate efficiently, but Slack App is not extensible that way. The purpose of the app is to allow an efficient exchange of textual information. Not being able to quickly jump to any thread using keyboard - defeats the sole purpose of the app.
Can you imagine to have a code editor that doesn't allow you to change its color scheme? Some may say: "it's not important", but for many people something like that would be a deal breaker. Fortunately we have many IDEs or editors to choose from, but we can't opt out of the Slack app - if the company is using it, you stuck with it.
