A presentation at Boston Ember.js Community (August Meetup) in in Boston, MA, USA by Melanie Sumner
a reasonable approach to inclusive development
Do you all know that story of the Russian cosmonaut? I’m gonna paraphrase it a bit, so bear with me if you know it already. So there’s this cosmonaut, and he’s finally up in space, his life-long dream come true And he’s filled with awe and wonder He can’t believe he’s there, experiencing this amazing thing And all of a sudden, he starts to hear this clinking noise. But he can’t find it, he can’t stop it, it keeps going A few hours into this, it begins to feel like torture Because What’s he gonna do? He’s up in space! So the cosmonaut decides that the only way to save his sanity Is to change his relationship with the sound. Instead of hating it, he has to love it.
I started out with Static Sites, which led to Editing Blogger CSS, which led to WordPress, and of course that’s a gateway drug to WordPress Plug-ins and multi-site WordPress installations. This led to learning how to create Custom PHP web-based applications for event management and internal department reporting and grant management. This led to a brief stint in .NET development, which led to C# development for university donor CRMs and such. But then I was talked into JS framework development (Backbone > Angular > Ember), which is what I am working on now, working on accessibility in Ember.js thanks to LinkedIn. So I’m telling you this to focus on the last bit- the JS framework development.
But of course, JavaScript doesn’t have things that other languages have, things that I depended on for order and rule in the universe. Like private classes or interfaces. JavaScript provided a way to make these things- but they aren’t enforced, and that was a bit of a nasty surprise. It felt like every time I built something, the other person who used it always did some kind of workaround to disfigure the piece of software I’d designed. It was so immensely frustrating to feel like I was finally doing the thing that I was good at and also didn’t involve death, yet still somehow chaos ensued.
But of course, JavaScript doesn’t have things that other languages have, things that I depended on for order and rule in the universe. Like private classes or interfaces. JavaScript provided a way to make these things- but they aren’t enforced, and that was a bit of a nasty surprise. It felt like every time I built something, the other person who used it always did some kind of workaround to disfigure the piece of software I’d designed. It was so immensely frustrating to feel like I was finally doing the thing that I was good at and also didn’t involve death, yet still somehow chaos ensued.
I very nearly gave up. But as it turns out, unless it’s FF8, I’m not really the giving up type.
I realized that much like the cosmonaut, the way to survive was to re-frame my perspective. So I started to remind myself why I chose my career in front end development.
I wanted to be a front-end developer because I wanted to remove frustration in the world. There is tremendous potential for in front-end developer space. We have such great capacity to create delight. And maybe if I created a great interface, the people using it would be happy after leaving work, and then they wouldn’t honk so much or have so much road rage driving home. And maybe they’d be nicer to everyone, and maybe the world would be a nicer place.
So I chose to change my mind about the things I perceived as weakness in JavaScript. I chose to see this perceived weakness as flexibility.
But I think front-end development can all feel a bit too much at times, we’re always chasing some new thing, but in most cases the new thing turns out to have the same problems as the thing we already had, and there’s all this churn and uncertainty.
And I think it doesn’t help that too many front end devs spend a significant portion of their early career learning from anti-patterns and “just hacking things together”.
Because those devs never come to understand that the thing they learned how to hack together is really an anti-pattern. To them, they are just patterns.
And then those developers go on to build addons and librarys and modules and they are super useful! They get praised for them. Promoted even!
But ultimately they are not useful because they are not accessible and there’s this moment of intense disconnect for the front end developer.
Why is an accessibility engineer telling them that their super useful thing that they were praised for and promoted because, why is that thing wrong? Bad?
After all the things they have learned and how much work it took to get to that point, realizing that they know absolutely nothing about the things that are BASICS in accessibility can feel really disheartening and even demoralizing.
It feels bad. Really Bad.
So then the ninja rockstar unicorn starts to perpetuate the myth that accessibility is hard, as a means of self-defense
This is problematic because at a large scale, it feeds into the cycle that supports faux innovation.
They become the people who are the driving force of what we think of as innovation are not helping us to innovate anything new, but rather ”giving” us things we already had. I have two examples of this – first we have AMP – splashy façade to convince those who don’t know better to add extra markup just for Google. Second, a recent announcement by google to make developing forms easier- “more capable form controls,” we are promised. The crux of the need for this innovation? “We can’t style native controls, so let’s hand over the API to be attached to whatever you decide to make instead.
We already had the solution to these problems though. We have HTML. Semantic HTML resolves the issues many javascript “innovations” attempt to “solve”.
And so that’s what I really want to talk about, because the idea that we’re willing to re-write what’s available in HTML simply to make it more like JS absolutely baffles me.
I think a more reasonable approach to consider some of the choices we have and what those choices mean.
to demonstrate what I mean about the choice of developing in isolation, I want to share with you some real things that have been said to me.
“HTML is a dead language. Just use a div, it’s more flexible anyway. Besides, our users don’t need accessibxility.” “Why do I have to care about less than 5% of my users as the default, rather than the other 95% who can see the page?” “This is all internal-facing anyway, so we don’t have to care about accessibility.” ”If I was blind, I wouldn’t use the internet.”
These are all examples of developing in isolation. And again, it’s a choice that could be made. But there’s the other side to this coin, another choice.
“I joined a non-profit to provide public services, and I really believe in the mission. The problem is, no one on our team knows how to write accessible code. We spend all of our time trying to figure out how to use React as the front-end of our CMS, and that uses AMP, too. On top of that, we’re trying to figure out how webpack was configured by the previous tech lead and there’s a custom Bootstrap integration too- miles of styles for days. One of the leads got frustrated and wrote his own bespoke CSS framework, but now we all have to take time to get familiar with that. There’s just no time for innovation or learning because we are too busy trying to ship for deadlines.”
Think about other developers when we create new platform features.
Think about our users who are blind and also use the internet to do the things we do on a daily basis and don’t even think about, like having a job, or banking, or paying utility bills.
This leads to inclusive development.
One choice we could make is to copy/paste from places like stack overflow.
“Modern software engineering seems very much like going out on the internet and finding little bits and pieces of code and putting them together with a little glue and it might work….and it got me thinking about my children. What if they ended up wanting to be software developers? What will their coding be like? Will they enjoy making a good design and implementing it, or will they be the kind of coders who hack away at something and hopefully it works and if it doesn’t they try again or give up and move on to another project?”
So let’s consider another choice we could make for how we create. We could choose to craft with intent.
Let’s look at how we could craft with intent.
A new feature request comes in. They’d like a radio button with options for the new form. But they don’t want any old radio buttons, they want fancy buttons. Oh and it’s easy right? So can you ship it today?
So you start to think about the radio button, and get interrupted with an updated request- can you ship it yesterday, actually?
So we stop thinking about radio buttons and think about how we could ship it yesterday, and we’re ninja rockstar unicorns so we can absolutely do that. I know! We’ll just find one that already exists to save time!
So we find something online that’s made by BigTech Co, and it looks nice, so it must be great!
But we are choosing to craft with intent, so let’s actually examine what BigTechCo produced for us.
It will cost us 30k in JavaScript, 10k in CSS, and way too much markup that isn’t accessible. So this cost is too high. What else could we do?
So we go read trustworthy resources, and discover that we can produce semantic html which will be fewer lines of code AND it will be machine-readable code, which means users with screen readers will also be able to use it. Win!
What about the “fancy” part of the request? that’s not possible, is it? Wait, it is! Using CSS properties that already exist, we can get improved styling! So we’ve produced less markup that is semantic and therefore accessible, and satisfied the requirement of a more stylish radio button with CSS that we already had. This is crafting with intent.
This is just one tiny example of all of the choices that will go into our work- and out into the world for our users. When you think about it that way, it gives you a bigger perspective into the choices you make, and what those choices mean.
This is a choice we can make. If you look at my Twitter feed you’ll notice the occasional “AMP should die in a fire” tweets. (I get really amped up about AMP).
and there are so many terrible things in the world to be vocal about!
OR we could choose to amplify what we think is excellent. by positively highlighting the kind of behavior we want to see more of, we are spreading good feels- and let me tell you what, humans are attracted to good feels. It might not be as sensational as the negative, but it will have better long-term results.
And there are so many delightful things we can amplify! - encourage newbies - praise colleagues - express gratitude for good management - thoughtful self-reflection - Ember Octane!
By remembering that we always have some level of choice, we can craft better experiences and be more inclusive in our development. I encourage everyone to create the space for deep thinking to occur, because this is where we create the environment for ourselves to genuinely excel and produce long-lasting value.
If you enjoyed this talk, please let me know! You can find me on twitter - @melaniersumner.
There are some things we already know about performance and a thousand other technical decisions that go into making an application- yet still sometimes forget. By the end of this talk, you’ll be reminded of the things you have perhaps forgotten, be reminded of some choices you can make that can create space for inclusive development, and take a peek into the landscape of the unexplored future of web development.
The following resources were mentioned during the presentation or are useful additional information.
To attend the event, RSVP on the Meetup page!
by Eric Bailey
