As an animation platform, Flash launched the web into new directions. But once it became a UX platform, without the structure of web or OS apps, it left millions behind. (thread)
Flash launched (as FutureSplash) in 1995 as an animation tool. It was released as a browser plugin in 1996. And people started to make really innovative animations with it right out of the gate.
The problems started when people tried to make entire sites with it.
You see, Flash had no inherent semantics or structure to it. You made shapes, you added keyframes. They moved around. Then they started over.
But text in Flash wasn't text: it was vectors shaped like letters. And that came back to haunt it.
The biggest joke of the 2000s around Flash was that it was a tool for making restaurant menus. Flash devs made apps that looked the way restaurateurs wanted them, and sold them in bulk. But how they did it was by faking buttons, scroll bars, etc. It was a picture of an interface.
It was that early--maybe 2000-2002--that the horse had left the barn forever. It was easier to make cool-looking stuff across browsers with Flash than with HTML. And virtually nobody cared that it was all inaccessible to blind, low-vision and keyboard users.
Flash added Windows accessibility API support in version 6, in 2002, 7 years after FutureSplash 1.0. But it was turned off by default. Why? Because none of those 7 years of apps had _any_ accessibility info. And to add it, you'd need to rebuild the app from source, at a minimum.
So even if your restaurant wanted to hire somebody to make their menu accessible, they couldn't, because they never got the source code from their vendor.
By the time accessibility did come into focus, there was an ocean of inaccessible Flash out there. And we had to boil it.
I joined Adobe in 2007 as an accessibility engineer, less than 2 years after the Macromedia merger. By that time, we had a UI toolkit called Flex, and I worked with that team to make the framework as accessible as I could, within the limits we had.
It was awful.
As an app inside Flash Player, inside a browser, running on an operating system, you were constrained to a tiny fraction of what the OS gave you for accessibility. And in our case, only on Windows.
Plugin API change? Breakage.
OS update? Breakage.
New browser? Forget it.
We had a plan to bring Flash accessibility cross-platform, but then in 2010, there was the Apple memo. Flash as a UI tool had peaked, and not long after, it was over.
Flash lived out its last years as a great video player with a bunch of legacy content that withered on the vine.
So. What did we learn?
First! Big empty sandboxes are great places to experiment! But you don't build skyscrapers on sand. ANY platform with a goal of reaching the whole world needs a structure it can build on, to allow it to adapt both to users and conditions over time.
Second! Deliverables need to be legible, and changeable by others. Preferably you! If you bought a site you can't edit, all you own is a dependency on the vendor you bought it from.
The only real fix for an inaccessible Flash app was to replace it with a new one. Hopefully HTML.
Finally: if you make the platform, you have an immense responsibility to the people who build on it, and the people who use it. In a very real way, you set the upper limit on how many people get to participate equitably within your ecosystem. NEVER, EVER forget this fact.
FutureSplash came out in 1995, the same year as the first web accessibility guidelines. It couldn't build on the kind of accessibility support that OSes and browsers offer today.
Your new sandbox in 2021 does not have any excuses for being inaccessible. None. Not a single one.
Every framework, library, plugin model, pattern, etc. in the world needs to be thinking, from their very _conception_, how they're going to be accessible, inclusive, equitable, adaptive, future-proof. Each mistake you make limits your future potential, possibly forever.
Today is bittersweet for me. I'm glad the web platform won. "HTML5" was in the first sentence I ever uttered to our CEO, in 2008.
Still, I and many others poured our hearts into boiling the ocean of inaccessible Flash, quixotic though we were.
It could have been so much more.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Hi #a11yScotland folx. Thank you for organizing an amazing conference. I'm home in Seattle but want to share some of the links from my talk for you to have a look. (Thread)
Engineers can't solve #a11y problems that are rooted in faulty business or design decisions. They can _make compliant code_ to cover over those decisions. But it won't result in fundamentally better software if it's not conceived with inclusion in mind.
As an engineer, I spent a good chunk of my career trying to make other engineers my allies. But if they're always directed to the most expedient implementation and never recognized for making it accessible, for them it's a fool's errand. They'll burn out, and so will you.
Weird but important corollary here:
Beware the engineering manager who asks business/design questions (e.g., "how many users are we talking about here?").
Why? THAT IS NOT THEIR JOB. They are likely just giving you their excuse in advance for deprioritizing the work.
THREAD: Captions are one of the greatest inclusive design success stories.
The first closed captioning decoder, made in 1980, cost ~$750 in today's dollars. TV not included.
That provided access to 15 hours a week of captioned broadcasts TOTAL across ABC, NBC and PBS.
Today, thanks to US law, every >13" TV sold since 1993 has a decoder. Every TV show broadcast since 2002 has required captions. Those captions now have to carry over to online distribution. And as of 1/1/19, video games require captions, too.
Not a bad 40 years, I'd say.
Captions help D/deaf and hard of hearing people, obviously. But they also help people who don't speak a language fluently, or don't grok a specific accent, or have other issues processing speech, or, like me, focus better when we can read the words.