I am one of the maintainers of the axe accessibility testing engine the Slack team is using. It's awesome to see such a detailed writeup of how folks are building on our team's work!
We publish the engine (axe-core) and the "core" playwright integration library Slack is using (@axe-core/playwright) as open source, but if you're interested in what the Slack team has described in this blog, we also have a paid offering called axe Developer Hub (https://www.deque.com/axe/developer-hub) that offers a similar workflow to what the Slack folks describe here: It hooks into end-to-end tests you already have to add in accessibility testing without needing a ton of code changes to your test suite.
It's very enlightening to see which features the Slack folks prioritized for their setup and to see some of the stuff they were able to do by going deep on integration with Playwright specifically. It's not often you are lucky enough to get feedback as strong as "we cared about <feature> enough to invest a bunch of engineering time into it".
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.
>A few developers gave us early feedback and requested screenshots of the pages where accessibility violations occurred.
It's amazing how much a screenshot will do for my motivation to fix a frontend bug. Visually identifying severity is much easier than reading and making a mental judgement.
I like using video as well. The whole "picture is worth 1000 words" adage is true, and it makes all kinds of bugs far easier to recognize.
I'm sure other tools are great too but I find Cleanshot on macOS makes it super convenient to do it, so there's no excuse not to document reports with images and/or videos.
I do the same with pull requests. Words are almost always essential, but demonstrating bugs/changes/features directly through accompanying visuals is hard to beat.
If you don't need to edit the screenshot, Command+Control+Shift+4 will bring up crosshairs that will put the screenshot selection in your clipboard and won't save it to disk. It's super handy for doing a ton of quick, one-offs.
I dreaded videos for a few reasons, some of which could have been fixed, but some were human nature.
First, they didn't play in all browsers at the company I worked at. That meant I had to either download it, or use a different browser for that.
But even then, it was a game "guess what the CSR thought was wrong" in the video. Usually after watching a rather long intro sequence before getting to the actual bug.
If the company is trying to replace written bug reports with videos for speed or convenience, it's a nightmare for the devs.
If it's just an add-on to show the specifics, then it might actually be good. I rarely got those.
Article about accessibility - code snippets added as images. And what about alt text? It just broadly summarizes what is displayed in image. I think there might be a tiny little problem here.
The text is also quite small and low-contrast (which matters a lot for accessibility!)
Also, more subjectively, the snippets don't really match the aesthetics of the rest of the site. The pseudo-macOS rendering inside the black borders is strange, as is the choice to use different monospace fonts for filenames and code snippets.
Slack have a rather good a11y experience. The few bugs that I've reported had been addressed rather promptly. The ux is also good with obvious consideration given to keyboard navigation. There are a few annoyances which separate it from perfect, but I rather like the app, especially compared to teams.
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 and other enriched content types through add-ins.
And a bonus one:
3. The ability to seamlessly transfer a Teams meeting connection between arbitrary devices (laptop -> desktop, phone -> laptop, etc).
Cypress has an excellent turn-key accessibility tool if you already use their product, and don't mind paying a lot for the accessibility feature. It uses your existing tests and makes evaluations based on that, with zero additional work.
They still have that 3-4 second delay during login though. I open Slack directly from a browser, I login from a browser, yet I have to wait until they decide to ask me if I really want to continue with the browser I've been using for literally all the steps so far.
It's not much but it feels like when I'm on YouTube with a device that doesn't have adblock and a short ad plays before the video.
It's not related to accessibility, but it's still UX.
My bad, I thought that rule was about the medium (i.e. the post itself). I didn't it also applied beyond that (e.g. commenting about Slack's UX on a post whose topic is a subset of Slack's UX).
Here is a way to get around this annoying behavior: Type “sla” in your address bar (or however many characters of “slack” it takes to get it to autocomplete with Slack URLs). Cursor down into saved URLs for actual Slack channels. Hit return. Skip all that bullshit.
Discord does the same bullshit and this works there too.
(This assumes you’re not logging out when closing the slack/discord tab. Sometimes it just doesn’t work with Slack and you have to do a full login.)
Readit News
We publish the engine (axe-core) and the "core" playwright integration library Slack is using (@axe-core/playwright) as open source, but if you're interested in what the Slack team has described in this blog, we also have a paid offering called axe Developer Hub (https://www.deque.com/axe/developer-hub) that offers a similar workflow to what the Slack folks describe here: It hooks into end-to-end tests you already have to add in accessibility testing without needing a ton of code changes to your test suite.
It's very enlightening to see which features the Slack folks prioritized for their setup and to see some of the stuff they were able to do by going deep on integration with Playwright specifically. It's not often you are lucky enough to get feedback as strong as "we cared about <feature> enough to invest a bunch of engineering time into it".
If you're interested in building these sort of accessibility tools, my team is hiring! https://www.deque.com/careers/senior-accessibility-tool-deve...
And if you are willing to answer some other questions regarding axe-core itself, I might have few.
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/axe-core/issues
It's amazing how much a screenshot will do for my motivation to fix a frontend bug. Visually identifying severity is much easier than reading and making a mental judgement.
I'm sure other tools are great too but I find Cleanshot on macOS makes it super convenient to do it, so there's no excuse not to document reports with images and/or videos.
I do the same with pull requests. Words are almost always essential, but demonstrating bugs/changes/features directly through accompanying visuals is hard to beat.
First, they didn't play in all browsers at the company I worked at. That meant I had to either download it, or use a different browser for that.
But even then, it was a game "guess what the CSR thought was wrong" in the video. Usually after watching a rather long intro sequence before getting to the actual bug.
If the company is trying to replace written bug reports with videos for speed or convenience, it's a nightmare for the devs.
If it's just an add-on to show the specifics, then it might actually be good. I rarely got those.
Also, more subjectively, the snippets don't really match the aesthetics of the rest of the site. The pseudo-macOS rendering inside the black borders is strange, as is the choice to use different monospace fonts for filenames and code snippets.
Pretty sure just about every other option is pretty likeable compared to Teams!
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 and other enriched content types through add-ins.
And a bonus one:
3. The ability to seamlessly transfer a Teams meeting connection between arbitrary devices (laptop -> desktop, phone -> laptop, etc).
But yet they hijack the standard Cmd-Z “insert link” shortcut for search, so you have to use their non-standard alternative. Not good.
Great to see Slack using a similar combo!
We didn’t have a dedicated accessibility team though, so I paired it with a shit list which the team worked through in less than a year.
It's not much but it feels like when I'm on YouTube with a device that doesn't have adblock and a short ad plays before the video.
It's not related to accessibility, but it's still UX.
https://news.ycombinator.com/newsguidelines.html
I'll keep it in mind, thanks.
Discord does the same bullshit and this works there too.
(This assumes you’re not logging out when closing the slack/discord tab. Sometimes it just doesn’t work with Slack and you have to do a full login.)