776 karma · joined March 24, 2011
I got interested in accessibility some 30 years ago, when I got to visit the lab at University of Washington. Its unbelievable the progress that has been made. And AI is having a huge positive impact as well.
I'll also say that if you can get a chance to go to a place like a google accessibility lab for a demo or even better watch a live usability test with disabled users, do it!
I put a line in my CLAUDE.md that says "If a test doesn't pass, fix it regardless of whether it was pre-existing or in a different part of the code."
* it was painful to program compared to Windows
* it required a lot more hardware (and thus money) to achieve the same level of performance.
* the UI was terrible
The bugs were definitely Adobe's fault: as with most tech companies, they were far more interested in expanding the feature set than they were on fixing the bugs and stabilizing the platform.
Now that you have a spec, task it out, but tell the LLM to write the tests first (like Test-Driven Development, but without all the formalisms). This forces the LLM to focus on the desired behavior instead of the algorithms. Be sure to focus on tests that focus on real behavior: client apis doing the right error handling when you get bad input, handling tricky cases, etc. Tell the system not to write 'struct' tests - checking that getters/setters work isn't interesting or useful.
Then you implement 1-3 tasks at a time, getting the tests to pass. The rules prevent disabling tests, commenting out tests, and, most importantly, changing the behavior of the tests. Doesn't use a lot of context, little to no hallucinating, and easily measurable progress.
That said, the other big benefit for me is it breaks a lot less often than hyprland and its ecosystem seems to (and I don't just mean bugs here, I also mean things like config file format changes). And this isn't a slam on hyprland - I was only ever mildly annoyed by its breakage.