Performance, generality, and accessibility
- Most software does a lot more than analogous software did in previous generations. This adds "background complexity." (Here is a good discussion of this.)
- Background complexity is usually bad for performance, both because it makes software do more (which takes time and uses resources directly) and because complex software is less modifiable.
- Internationalization and accessibility often add background complexity. (This will be obvious to many but not all readers. To get a flavor of the problem, pick a medium-complexity application that involves text and consider what is required for it to work work just as well with right-to-left and left-to-right text.)1
- So, some pining for the old days of leaner, less bloated software is pining for software that emphatically did not "work for everyone." (To be clear: only some! Most software bloat has nothing to do with accessibility.)
- Performance isn't just people wanting video games to be snappy; it's a basic aspect of all software use. Many aspects of performance are most important for users (i) who have older or lower-powered devices, (ii) who have slower and less steady connections, and (iii) who are more easily confused by software (for reasons of, e.g., familiarity, cultural difference, neurodiversity, or cognitive decline).
- Accessibility and internationalization initiatives, therefore, sometimes involve subtle tradeoffs not just between those and other values, but even within those values. If a given accessibility fix makes a payload 2% larger or a core operation 2% slower, what should one do?
- Companies sometimes use accessibility checklists or have "accessibility experts" with dictatorial powers. These are often poor ways to make good accessibility decisions. (And yet, they might be the best ways companies have. Wise decisions about subtle tradeoffs are tough for organizations, and here there are extra legal and ethical complexities.)
- To be clear: a lot of accessibility and internationalization work (i) is nearly costless and/or (ii) improves the software for everyone. Our software would show more robustness, care, and basic decency if we paid more collective attention to accessibility.
- But, again, not all the lunches here are free. Some accessibility work adds complexity, and complexity tends to hurt performance, but performance is an important part of accessibility.
If memory serves, I once read something from a WSL developer saying, approximately, "yes, keyboard input is very snappy now, but it won't last, because we're about to implement a bunch of internationalization stuff." But I can't dig this up, and who knows how reliable my memory is. (It might be related to this.)↩