4 ms·

Or they have evaluated their potential solutions without understanding the choice they are making. For example, they have only considered how something looks, n

Or they have evaluated their potential solutions without understanding the choice they are making. For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). If you look at a screen produced by, say, Flutter and compare it to Aplpe's native toolkit you might conclude that you can produce the "same" thing with Flutter as you'd get with Apple's native toolkit. To boot you can do it in less time. The thing to consider is: Did you really produce the same thing? Maybe you produced two things that look the same, but aren't even close to equivalent in many other important ways.

jackcviers3 5y ago
This is the answer. This is always what happens. You use the fastest thing that will get the feature done or the bug fixed. To do that, you choose the components that provide the things you need to match your task's requirements. If the requirements don't list accessibility, then you do not care. Your job isn't design, it's implementation. The senior people are supposed to think of that stuff. You have enough work just keeping up with all the things you have to do at that scale. In the initial meetings where you talk about making new component libraries, someone who worked on the old one says, "We reinvented the wheel last time, then standards changed, and we couldn't keep up. We need to take current standards into account before doing anything new, including accessibility." And the new boss says, "That's a good call-out, but accessibility isn't a problem if nobody can even load the component list and scroll to the thing they want, and with the current ux and stats, we're getting close to using most of the available memory on devices just to scroll our content. We don't want to change the content we can scroll, we just want to make scrolling more efficient. Everyone agrees the current design is at its limits. We need to start over at the beginning. Accessibility is step 3. We're at step 0. Let's focus and move forward." And while they are right, they need to demo an map to an abled-person boss, so accessibility gets pushed farther back as technical things take priority. Often, this leads to teams over time producing lots of things without accessibility, and you build new things from old things, and it just snowballs. Suddenly a user appears, and they aren't served, and now a whole new bunch of juniors are scrambling to add accessibility to old things without breaking current usage.
sangnoir 5y ago
> For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). When Sun or Google created their own, non-native toolkits designed to run on Mac OS/iOS, they were fully aware of what doesn't work. However, they balanced that con against the pros of the ability to write cross-platform code once (ground floor engineers), and on strategic level, they wanted to commoditize Mac OS/iOS into a dumb pipe (one of many other dump pipes to deliver code/content to), rather than a platform with inherent value - they consciously considered this to be more important than users' griping at the weird scroll-speed curves. One can create a shim for native widgets like QT does, but you'll be at the platform owners mercy when it comes to release cadence. It's good business practice to commoditize your complement - seen in that light, the decisions are far from "not smart". Not great for some users, for sure, but they come from deliberate decision-making over control.

jackcviers3 5y ago

This is the answer. This is always what happens. You use the fastest thing that will get the feature done or the bug fixed. To do that, you choose the components that provide the things you need to match your task's requirements. If the requirements don't list accessibility, then you do not care. Your job isn't design, it's implementation. The senior people are supposed to think of that stuff. You have enough work just keeping up with all the things you have to do at that scale. In the initial meetings where you talk about making new component libraries, someone who worked on the old one says, "We reinvented the wheel last time, then standards changed, and we couldn't keep up. We need to take current standards into account before doing anything new, including accessibility." And the new boss says, "That's a good call-out, but accessibility isn't a problem if nobody can even load the component list and scroll to the thing they want, and with the current ux and stats, we're getting close to using most of the available memory on devices just to scroll our content. We don't want to change the content we can scroll, we just want to make scrolling more efficient. Everyone agrees the current design is at its limits. We need to start over at the beginning. Accessibility is step 3. We're at step 0. Let's focus and move forward." And while they are right, they need to demo an map to an abled-person boss, so accessibility gets pushed farther back as technical things take priority. Often, this leads to teams over time producing lots of things without accessibility, and you build new things from old things, and it just snowballs. Suddenly a user appears, and they aren't served, and now a whole new bunch of juniors are scrambling to add accessibility to old things without breaking current usage.

sangnoir 5y ago

> For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). When Sun or Google created their own, non-native toolkits designed to run on Mac OS/iOS, they were fully aware of what doesn't work. However, they balanced that con against the pros of the ability to write cross-platform code once (ground floor engineers), and on strategic level, they wanted to commoditize Mac OS/iOS into a dumb pipe (one of many other dump pipes to deliver code/content to), rather than a platform with inherent value - they consciously considered this to be more important than users' griping at the weird scroll-speed curves. One can create a shim for native widgets like QT does, but you'll be at the platform owners mercy when it comes to release cadence. It's good business practice to commoditize your complement - seen in that light, the decisions are far from "not smart". Not great for some users, for sure, but they come from deliberate decision-making over control.