Live data from Hacker News

Automated accessibility testing at Slack

slack.engineering

51–59 of 59 posts

Re: Automated accessibility testing at Slack

#51
post #12

[flagged]

The fascinating thing about accessibility is that (unlike many other characteristics) all of us are going to be at least temporarily disabled at some point in our lives. I've really appreciated the presence of ramps whenever I've injured my foot, or just if I'm rolling a couple heavy suitcases.

Re: Automated accessibility testing at Slack

#52
post #28
post #12

[flagged]

Web accessibility describes specific requirements for people with disabilities to be able to use your website. If you don't implement these features, blind people, colorblind people, people who can't use a mouse, etc., won't be able to use your website. You can make a strategic choice not to support these users for reasons like ROI. But obviously there are plenty of situations where either we make the affirmative cho…

>we should always build on the web with the modern features that support assistive technologies

Or build on the old web without modern features, that supports assistive technologies by default [1] :).

[1] https://motherfuckingwebsite.com/

Re: Automated accessibility testing at Slack

#53
post #32
post #24

Earlier quoted context omitted.

If you consider the real-time text-only chat, maybe. As soon as you start thinking about the side features. they are not comparable.

for example?

You can't honestly suggest that IRC and Slack have feature parity. Slack has:

* A support for sharing images and files

* Rich text formatting

* Can easily share code blocks

* Rich and granular permission system, suitable for a large organisation

* Webhook-based integrations

* A rich ecosystem of existing corporate integrations (like calendar integrations)

* Accessible web application, that provides access to all of those features

* Mobile app (for both android and ios) that provides access to all of those features

* Built-in OAuth/OIDC integration, that makes it easy to put it behind a company proxy.

* User statuses, avatars, metadata (like real name or team name), timezone-awareness

* Adding guests to channels, or bridging channels between servers

* Voice calls

* Search (!) with history, accessible for any device

* Actually, you can write to someone who is not online right now, something IRC doesn't support without a bouncer.

* Project management features (lists etc)

* Well documented and rich API

* Enterprise support

And this is just out of the top of my head.

Re: Automated accessibility testing at Slack

#54
post #46
post #43

Earlier quoted context omitted.

Been running somewhat similar combo few months and toy'd around with taking the screenshots of the selectors axe-core/playwright reports as I didn't notice such feature in neither playwright or its html reporter. Do you happen to know if slack patched this or is this feature available somehow ? And if you are willing to answer some other questions regarding axe-core itself, I might have few.

Screenshots of issues is something we support in many of our paid offerings, but not in axe-core itself. It sounds like the Slack folks implemented their own version of it. If you have general questions about axe-core, the best place to ask is our axe Community slack instance ( https://accessibility.deque.com/axe-community ). If you have a specific issue you'd like us to investigate, try https://github.com/dequelabs/…

Either there's some very long queue or that signup page for slack invite doesn't work.

Re: Automated accessibility testing at Slack

#55
post #45

Earlier quoted context omitted.

It’s made worse by the fact that the search is strictly awful.

Which one? The one bound to ctrl+f or the one at the top of the window? /s Why are these even isolated? That's what parameters are for!

It beggars belief

Re: Automated accessibility testing at Slack

#56
post #53
post #32

Earlier quoted context omitted.

for example?

You can't honestly suggest that IRC and Slack have feature parity. Slack has: * A support for sharing images and files * Rich text formatting * Can easily share code blocks * Rich and granular permission system, suitable for a large organisation * Webhook-based integrations * A rich ecosystem of existing corporate integrations (like calendar integrations) * Accessible web application, that provides access to all of t…

Remember that we are talking about accessibility, so the more images and animations and sound you have, the LESS accessible it is.

Also we're not comparing IRC and slack, but slack used from an IRC client and slack used from an electron client.

Perhaps you didn't completely understand what I was saying?

> Mobile app (for both android and ios) that provides access to all of those features

Nothing stops you from using all the clients you want? Again, I suspect you don't fully understand the thing you're hating on so hard.

> Accessible web application, that provides access to all of those features

Slow, and I'd like a disabled user to comment on that. Also not all features work on firefox.

> Voice calls

Doesn't work, but are you really claiming voice calls are more accessible than text? Have you asked a deaf person how they feel about voice calls?

> Actually, you can write to someone who is not online right now, something IRC doesn't support without a bouncer.

Works fine. Ok I realise you didn't read my comment and are just raging for no reason because you read "IRC" and got mad.

> A support for sharing images and files

Worksk fine with localslackirc. You can directly pipe the output of commands into channels

> Rich and granular permission system, suitable for a large organisation > Webhook-based integrations > A rich ecosystem of existing corporate integrations (like calendar integrations) > Adding guests to channels, or bridging channels between servers > Well documented and rich API > Enterprise support

??? This has absolutely nothing to do with the client??

> Rich text formatting

Not supported

> Can easily share code blocks

Works fine, they're saved into text files

> Built-in OAuth/OIDC integration, that makes it easy to put it behind a company proxy.

Works fine with any authentication

> User statuses, avatars, metadata (like real name or team name), timezone-awareness

Avatar not supported, metadata is supported

> Search (!) with history, accessible for any device

Doesn't work, but it's of course accessible with other clients

> Project management features (lists etc)

If you do your project managing on slack, I'm glad I don't work with you :D

I'm also glad I don't work with someone who just reads 1 word and gets triggered into an OT rant, to be honest.

Re: Automated accessibility testing at Slack

#57
post #26
post #15

Earlier quoted context omitted.

Well it's mandatory to get government contracts. That's the only reason companies do it. They have no interest for disabled people.

Not only government contracts, some very big orgs have accessibility requirements in all their vendor contracts too.

They do because of government requiring them to hire disabled people :)

Re: Automated accessibility testing at Slack

#59
post #18

Earlier quoted context omitted.

Yet there are Teams features that nobody else has emulated yet and which quickly become almost indispensable for business use. I'll name two: 1. Teams automatically creates a chat group for every Teams calendar event. This can include external attendees. 2. Teams is useful for chat & meetings, but Teams spaces are hugely helpful as document repositories, too, and it's additionally easy to add things like Gantt charts…

> 1. Teams automatically creates a chat group for every Teams calendar event. This can include external attendees. This happens in Zoom as well, without the extra Teams downside of external attendees being 4th class citizens. > 2. Teams is useful for chat & meetings, but Teams spaces are hugely helpful as document repositories, too, and it's additionally easy to add things like Gantt charts and other enriched content…

I does also help propagate the other "elephant in the room" problem M365 users face, which is document version control. Since people are constantly sharing actual files -- vs symlinks as with Google Workspace -- nobody ever really knows who has the canonical version of whatever. This is solved in regulated industries with "add-ons" (it's a huge stretch to call it that) like Veeva Vault that enforce formal document control workflows, but it doesn't help normal business users at all.
Post reply on HN