7 ms·

> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and

by bramd 9y ago

> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team. Not just that, but it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days. So yeah, I take this promise with some skepticism. So either this is a lack of priority and disrespect to a part of their users or some level of incompetence. I might sound harsh about this, but imagine being a blind software dev that's supposed to work with Slack to participate in teams. Every day you sign on to your team it's possible that the Slack devs break something and you can't function. And now they closed the escape hatch.

ivm 9y ago
Not to mention that Chromium takes a performance hit when accessibility is on – that's why it's off by default. But both Safari and native Mac apps are always accessible.
- bramd 9y ago
  Well, in this case I was quite glad that they have targeted the web platform. At least that allows me to code my own stopgap solution using userscripts and stuff. That's harder for native.
  - saagarjha 9y ago
    With native apps, you don't need to. Good accessibility solutions are the default.
    - deleted 9y ago
      [deleted]
komon 9y ago
> it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days A userscript hammered out in a few days is not really that comparable to incorporating accessibility in a flexible and sound way across a codebase. Where one is dependent on the current representation and types of features in the app, the other touches pretty much everywhere in a code base that might be split across different people or teams that have other business goals to accomplish. The scale of work is not really as comparable as they may seem at first glance. So, contrary to what you said about lack of priority and disrespect, I think it's admirable that they take the time to add these necessary accommodations in a way that ensures that they'll be appropriately maintained and present with future iterations.
- Hello71 9y ago
  assuming this claim is valid, that it took "few days" to implement what took them "months", then they could rewrite the entire user script from scratch every time a change is made, and this could be repeated dozens of times, which, assuming major UI changes are made once every few months, would take several years.
  - milesvp 9y ago
    But, but, but, then I'd have to touch the same code twice... /s There is definitely a poison in our profession, I definitely have to fight the urge to make sure no future changes will break something, instead of just budgeting time to fix breaking changes later. Especially since no one seems to remember when we all agree something doesn't need to be bullet proof. Just today there was an expression of disbelief when I reminded people I'd built a tempermental UI for some internal tool. Never mind that it was a conscious decision to prioritize a better UI later if we found the tool useful and found the UI was causing problems.
    - amarkov 9y ago
      These are not unrelated observations! The same people who expressed disbelief that your UI is temperamental will react the same way if Slack releases a temperamental UI. The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.
xkcd-sucks 9y ago
can slack plausibly cause ADA compliance problems re: visually impaired people? or would it end up as "use the browser client with a screen reader and be glad you can do that"
- jjeaff 9y ago
  The ADA only applies to certain types of "public" private businesses. Like grocery stores and bakeries, hotels, etc. I have never heard of it applying to any private software (that isn't government related). You can always use some other chat software or none at all. However, I would imagine that as a company, if you require employees to use specific software as a condition of employment and no accommodation can be made, you might run into trouble as an employer.
  - dotancohen 9y ago
    Then why would an employer risk such troubles when non-snowflake (sighted) employees could be employed?
blindgeek 9y ago
So much this! I happen to be a blind software developer who has had just this sort of experience in years gone by. Web apps mean that you are at the mercy of the developers. Something can work one day and break the next. This is even more true for blind people than it is for the general public. Even if there is accessibility testing, I doubt that it covers my particular toolstack. I'm on Linux. So I'm doubly a niche user. The web (and web apps) are all about providing an experience. I don't want an experience, I want a reliable tool.
- DrJokepu 9y ago
  Out of curiosity, what is your toolstack?
  - blindgeek 9y ago
    I use emacs with emacspeak for programming and a good many other things. For pure terminal interaction outside of emacs I use a console-based screen reader called Speakup. For graphical applications, I use a screenreader called Orca. I don't use a whole lot of graphical applications, but I need Firefox for most of the "modern" web. I've also used Chrome with Chromevox over the years. Honestly I prefer text-mode browsers when I can use them, but that ship has mostly sailed. I've been involved with the development of edbrowse; the author is a friend of mine.
- welder 9y ago
  Besides building accessibility into frontend/React component toolkits, how do we automate testing for accessibility? I've turned on text dictation and tested apps with a blindfold, but that doesn't scale and I'm not even sure if it's how people really use an app without sight.
  - abugher 9y ago
    Tangent: I think you should really have someone who hasn't seen the app test with the blindfold. Is that double blind, or just single blind plus literally blind?
Cambridgeport90 9y ago
As a developer community, we need to get to the point where accessibility is not an afterthought, not even something that has to be considered at all; that just is. I'm stating this from experience; I'm blind myself, so I know exactly what is being referred to. My group used to use Slack, and we stopped using it for this very reason. It's not hard to fill out the accessible label field. If it's present in the framework, then it should be taught and enforced.
- jareds 9y ago
  What do you use instead of Slack? I'm a blind developer and find it usable enough, but I'm also on a fairly small team with out a tun of slack traffic.
  - Cambridgeport90 9y ago
    We use Microsoft Teams, and for our public interface, Discord. Though I just set up a team on Keybase as well. Look for OpenCAD on Discord and StormlightTech on Keybase if interested.
noobermin 9y ago
As someone who doesn't use slack, why did we ever move away from chat programs and protocols that worked fine? I don't know why I need to use slack, hangouts, discord, etc, that are just reinventing irc and/or the garden variety instant messaging platforms that already exist.
- rb666 9y ago
  Discord is amazing, there really isn't a good replacement right now. Before that it was a mess/mix of IRC/Skype/Teamspeak/Whatsapp, now you can combine all that in one great client from a company that actually seems to care about its users. It's my favorite monthly Paypal charge!
  - yorwba 9y ago
    When I combine the feature set of IRC/Skype/Teamspeak/WhatsApp, I come up with text chat + voice/video conferencing, which e.g. Skype already provides. Is the difference that the client is great?
    - rspeer 9y ago
      Yeah, a feature set doesn't matter if the features are bad. I would never want to use Skype as a platform for an ongoing text chat. (Does Skype even have persistent channels?) Also now that Discord exists, I would never do a voice chat in Skype either. A substantial portion of every Skype call I've ever been on was people apologizing to each other for the bad audio. Discord apparently just has better signal processing.
      - Jaruzel 9y ago
        > Does Skype even have persistent channels? Skype for Business does. But... not the Azure/Cloud version; you have to host it on-site, and MS are rapidly replacing Skype with the less feature rich (if that's even possible!) 'MS Teams'.
    - e12e 9y ago
defined 9y ago
I hear you. I worked with two blind systems people for close to 5 years - we were all working remote, so initially I had no idea they were blind - and subsequently learned from them about their struggles and frustrations dealing with shitty or nonexistent accessibility features. And with assistive devices’ drivers that were broken, or not updated since Windows State of the Ark version, or not available on Linux or Mac, and so on. These two people dramatically improved the accessibility features of the smartphone product that the company sells, by reporting the issues they found while dogfooding it. They raised the awareness of many people, including me, of the challenges of the blind, particularly in technology settings. As a result, I learned ‘dot’ (graphviz) pretty well, and became much more text-centric in other ways (e.g. using markdown, avoiding images when possible, adding alt text). Slack has done the community a disservice by dropping support for open protocols like IRC and XMPP, which support text-based interfaces that work well with screen readers.
- c4h8o3del 9y ago
  It might be only tangentially related to your point, but there are Slack API-based clients for [emacs][1] and [weechat][2]. So screen-reader usability is still a thing. The fact it's not using a proper standard open protocol is a problem. [1]: https://github.com/yuya373/emacs-slack https://github.com/yuya373/emacs-slack [2]: https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack

by bramd 9y ago

ivm 9y ago

Not to mention that Chromium takes a performance hit when accessibility is on – that's why it's off by default. But both Safari and native Mac apps are always accessible.

bramd 9y ago
Well, in this case I was quite glad that they have targeted the web platform. At least that allows me to code my own stopgap solution using userscripts and stuff. That's harder for native.
- saagarjha 9y ago
  With native apps, you don't need to. Good accessibility solutions are the default.
  - deleted 9y ago
    [deleted]

komon 9y ago

> it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days A userscript hammered out in a few days is not really that comparable to incorporating accessibility in a flexible and sound way across a codebase. Where one is dependent on the current representation and types of features in the app, the other touches pretty much everywhere in a code base that might be split across different people or teams that have other business goals to accomplish. The scale of work is not really as comparable as they may seem at first glance. So, contrary to what you said about lack of priority and disrespect, I think it's admirable that they take the time to add these necessary accommodations in a way that ensures that they'll be appropriately maintained and present with future iterations.

Hello71 9y ago
assuming this claim is valid, that it took "few days" to implement what took them "months", then they could rewrite the entire user script from scratch every time a change is made, and this could be repeated dozens of times, which, assuming major UI changes are made once every few months, would take several years.
- milesvp 9y ago
  But, but, but, then I'd have to touch the same code twice... /s There is definitely a poison in our profession, I definitely have to fight the urge to make sure no future changes will break something, instead of just budgeting time to fix breaking changes later. Especially since no one seems to remember when we all agree something doesn't need to be bullet proof. Just today there was an expression of disbelief when I reminded people I'd built a tempermental UI for some internal tool. Never mind that it was a conscious decision to prioritize a better UI later if we found the tool useful and found the UI was causing problems.
  - amarkov 9y ago
    These are not unrelated observations! The same people who expressed disbelief that your UI is temperamental will react the same way if Slack releases a temperamental UI. The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.

xkcd-sucks 9y ago

can slack plausibly cause ADA compliance problems re: visually impaired people? or would it end up as "use the browser client with a screen reader and be glad you can do that"

jjeaff 9y ago
The ADA only applies to certain types of "public" private businesses. Like grocery stores and bakeries, hotels, etc. I have never heard of it applying to any private software (that isn't government related). You can always use some other chat software or none at all. However, I would imagine that as a company, if you require employees to use specific software as a condition of employment and no accommodation can be made, you might run into trouble as an employer.
- dotancohen 9y ago
  Then why would an employer risk such troubles when non-snowflake (sighted) employees could be employed?

blindgeek 9y ago

So much this! I happen to be a blind software developer who has had just this sort of experience in years gone by. Web apps mean that you are at the mercy of the developers. Something can work one day and break the next. This is even more true for blind people than it is for the general public. Even if there is accessibility testing, I doubt that it covers my particular toolstack. I'm on Linux. So I'm doubly a niche user. The web (and web apps) are all about providing an experience. I don't want an experience, I want a reliable tool.

DrJokepu 9y ago
Out of curiosity, what is your toolstack?
- blindgeek 9y ago
  I use emacs with emacspeak for programming and a good many other things. For pure terminal interaction outside of emacs I use a console-based screen reader called Speakup. For graphical applications, I use a screenreader called Orca. I don't use a whole lot of graphical applications, but I need Firefox for most of the "modern" web. I've also used Chrome with Chromevox over the years. Honestly I prefer text-mode browsers when I can use them, but that ship has mostly sailed. I've been involved with the development of edbrowse; the author is a friend of mine.
welder 9y ago
Besides building accessibility into frontend/React component toolkits, how do we automate testing for accessibility? I've turned on text dictation and tested apps with a blindfold, but that doesn't scale and I'm not even sure if it's how people really use an app without sight.
- abugher 9y ago
  Tangent: I think you should really have someone who hasn't seen the app test with the blindfold. Is that double blind, or just single blind plus literally blind?

Cambridgeport90 9y ago

As a developer community, we need to get to the point where accessibility is not an afterthought, not even something that has to be considered at all; that just is. I'm stating this from experience; I'm blind myself, so I know exactly what is being referred to. My group used to use Slack, and we stopped using it for this very reason. It's not hard to fill out the accessible label field. If it's present in the framework, then it should be taught and enforced.

jareds 9y ago
What do you use instead of Slack? I'm a blind developer and find it usable enough, but I'm also on a fairly small team with out a tun of slack traffic.
- Cambridgeport90 9y ago
  We use Microsoft Teams, and for our public interface, Discord. Though I just set up a team on Keybase as well. Look for OpenCAD on Discord and StormlightTech on Keybase if interested.

noobermin 9y ago

As someone who doesn't use slack, why did we ever move away from chat programs and protocols that worked fine? I don't know why I need to use slack, hangouts, discord, etc, that are just reinventing irc and/or the garden variety instant messaging platforms that already exist.

rb666 9y ago
Discord is amazing, there really isn't a good replacement right now. Before that it was a mess/mix of IRC/Skype/Teamspeak/Whatsapp, now you can combine all that in one great client from a company that actually seems to care about its users. It's my favorite monthly Paypal charge!
- yorwba 9y ago
  When I combine the feature set of IRC/Skype/Teamspeak/WhatsApp, I come up with text chat + voice/video conferencing, which e.g. Skype already provides. Is the difference that the client is great?
  - rspeer 9y ago
    Yeah, a feature set doesn't matter if the features are bad. I would never want to use Skype as a platform for an ongoing text chat. (Does Skype even have persistent channels?) Also now that Discord exists, I would never do a voice chat in Skype either. A substantial portion of every Skype call I've ever been on was people apologizing to each other for the bad audio. Discord apparently just has better signal processing.
    - Jaruzel 9y ago
      > Does Skype even have persistent channels? Skype for Business does. But... not the Azure/Cloud version; you have to host it on-site, and MS are rapidly replacing Skype with the less feature rich (if that's even possible!) 'MS Teams'.
  - e12e 9y ago

defined 9y ago

I hear you. I worked with two blind systems people for close to 5 years - we were all working remote, so initially I had no idea they were blind - and subsequently learned from them about their struggles and frustrations dealing with shitty or nonexistent accessibility features. And with assistive devices’ drivers that were broken, or not updated since Windows State of the Ark version, or not available on Linux or Mac, and so on. These two people dramatically improved the accessibility features of the smartphone product that the company sells, by reporting the issues they found while dogfooding it. They raised the awareness of many people, including me, of the challenges of the blind, particularly in technology settings. As a result, I learned ‘dot’ (graphviz) pretty well, and became much more text-centric in other ways (e.g. using markdown, avoiding images when possible, adding alt text). Slack has done the community a disservice by dropping support for open protocols like IRC and XMPP, which support text-based interfaces that work well with screen readers.

c4h8o3del 9y ago
It might be only tangentially related to your point, but there are Slack API-based clients for [emacs][1] and [weechat][2]. So screen-reader usability is still a thing. The fact it's not using a proper standard open protocol is a problem. [1]: https://github.com/yuya373/emacs-slack https://github.com/yuya373/emacs-slack [2]: https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack