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.
[ Speaking Spanish ]
Automated accessibility testing at Slack
41–50 of 59 posts
Re: Automated accessibility testing at Slack
#42Article 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 things you are asking would be done in 2028 under "Grounds up refactoring for Accessibility First Engineering"
Re: Automated accessibility testing at Slack
#43I 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…
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.
Re: Automated accessibility testing at Slack
#44Accessibility testing is important and great. However I wish Slack would put as much effort into general testing.
Some of their recent releases have left a lot to be desired.
Re: Automated accessibility testing at Slack
#45Earlier quoted context omitted.
I'm strongly of the opinion that 1. is an anti-feature. It creates a ton of clutter.
Indeed. Instead of a dedicated set of channels for a topic... we have this breaking things up. This 'feature' absolutely kills focus. The old ways - curating channels - are the best ways.
It’s made worse by the fact that the search is strictly awful.
Re: Automated accessibility testing at Slack
#46I 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…
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/axe-core/issues
Re: Automated accessibility testing at Slack
#47Earlier quoted context omitted.
Indeed. Instead of a dedicated set of channels for a topic... we have this breaking things up. This 'feature' absolutely kills focus. The old ways - curating channels - are the best ways.
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!
Re: Automated accessibility testing at Slack
#48>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…
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.
Re: Automated accessibility testing at Slack
#49ok cool but how about we get syntax highlighting for common programming langauges in code blocks?
Re: Automated accessibility testing at Slack
#50Article 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.