Projects
-
Accessibility the Easy Way With Deque's Linter
I have been interested in, though never an expert in, web accessibility, for years. I believe common-sense affordances like alt text and keyboard navigability in a website are shining examples of the curb-cut effect, so while I am not (currently) disabled1, I do at least try to make my websites accessible.
But I didn’t know until attending Abbey Perini’s talk at CodeWord last week that I could automate at least some of this work with an accessibility linter.
Wait, a what?
Yeah, my reaction too. But just like Prettier or eslint can enforce code style rules, an accessibility linter can enforce, or at least warn you about, accessibility violations. I immediately downloaded deque’s axe Accessibility Linter plugin for VSCode and it’s already caught a few things on this here blog. (I may have forgotten alt text in a few places…)
Accessibility is much more than automated tools. A site could pass the linter and pass all kinds of other tests and still be difficult to use. But this is one new tool in my toolbox that I didn’t know about before, and I’m glad to have it.
Watch Abbey’s talk for yourself on Youtube.
-
The stats vary, but some say that 1 in 3 Americans will experience a temporary disability of 90 days or more before reaching the age of 65. That’s a lot. ↩
-
-
Who's Touching My Files? Watch Out With Watchman
Is Mr. Game and Watch a watch-man? I don’t see why not.I have a weird setup at work with a lot of interlocking config files. (We sort of halfway support git’s
sparse-checkoutfeature but with an internal tool that’s supposed to keep everything in sync outside of git. Don’t ask. It’s better than I’m making it sound.)Anyway because of this funky setup, I was running into an issue where a file was being modified, incorrectly, when I ran some command. I wasn’t sure which command was causing the ghost line to reappear, because it kept happening behind my back. It was driving me crazy, and I tried all sorts of solutions to ‘catch’ the file appearing.
What finally worked was
watchman, a little file monitor tool that Facebook developed for web development. What it’s supposed to do is monitor a directory for changes, and then run some sort of command on changed files. It runs in the background and automatically remembers your watches even if you reboot your machine, which cannot be said forinotifywaitorfswatchor any of the other things I tried. It also works on Windows, Mac and Linux, because under the hood it hooks into one of the above utils depending on your OS. In other words, it Just Works(tm).The canonical watchman example is running a CSS minifier any time CSS within a certain directory is modified.
watchman watch path-to-dirwatchman -- trigger path-to-dir name-of-trigger '*.css' -- minify-cssIn my case, I don’t need to run any sort of processor on changed files, I just need to know who or what is changing them. Easy:
watchman watch path-to-dirwatchman -- trigger path-to-dir mytrigger 'the-file.txt' -- say "I changed"This was so silly (and for a while my computer was making a horrendous number of annoying noises) but it worked great and helped me track down which unrelated command was changing my config file.
Learn more about watchman from the official docs and give it a shot.
P.S. the official docs have about 3 suggestions for where to find watchman’s logs– I found mine in none of those suggestions, but I was able to run
watchman get-logto find the (quite mysterious) location.