Entice 'em

Getting engineers
excited about accessibility

Hi, I'm Prae, a Thai woman with shoulder length dark hair. I'm wearing a large pair of dark full-frame glasses and a mint coloured shirt.

I've been a UX focused front-end web engineer for 9 years.

But I actually started my career as a designer. Hence my deep appreciation for design craft, especially UX parts of it.

I love coding up designs in a responsive manner, and improving usability of those designs through code.

I spent most of my career focusing on how to make UI design and UX pattern scales.

I've done that while collaborating closely with designers, to ensure that there is reasonable consistency between implementation and designer's vision. I rely heavily on in-house pattern libraries and design systems to do that.

I owe a lot of my career to the UX designers and researchers I've worked with. That's apparently most of you.

You have constantly reminded me of who my users are, and their needs. You've helped me understand our user's feedback after features have been released, and collaborate on a way to incorporate that feedback.

In the last few years, I've gone even deeper into my front-end craft, and have been focusing my efforts on creating and advocating for accessible interfaces.

As I advocate, I noticed a different level of enthusiasm for accessibility among all roles. Some are really enthusiastic about it, and some, not so much.

Over and over, I come accross a theme of sentiments...

Engineers are less engaged with accessibility

If true... Why is that?

Engineers as a user

traditional & non-traditional background

From my humble understanding of the user centred design practice, you start by empathising with your users. In this case, you'd ask:

Who are the engineers?
What do they need to do their job?
What do they want?
How they currently do things
How they'd like to do them

[Next] First, who are the engineers?

At a high level, my job is to implement the best possible technological solution to a problem.

Like any user group, engineers come from diverse backgrounds. They could be neurodiverse, disabled, didn't finish high school, was a doctor and switched career, and etc.

But the aspect that I want to highlight, is that not all engineers had formal education related to programming.

For programmers with a traditional background, they took a degree that taught them nothing about design, and everything to do with how to break down problems and solve it using technologies.

A lot of the programming concepts taught in university is very much backend and data focused, so it's usually safe to assume that they're better at that aspect of software development.

For engineers from non-traditional like myself, my skillset was mostly developed by tasks that my workplace prioritise, and teaches me.

I happen to work in a place with a lot of UI focused work, and interactions with designers. So I am stronger with that aspect of programming.

Unless the engineer was taught or worked closely with design and research, they wouldn't understand how to proactively approach these subjects.

Responsible for...

Creating, testing, & maintaining software
in a usable, secure, privacy focused, responsive, scalable, testable, maintainable, performant, efficient, resilient, safe, accessible, and 100+ manner

In most companies, engineers are expected to create, test and maintain software.

That's pretty reasonable right?

The trickier thing, is the manner in which they're expected to engineer software

[Next]

We have to engineer software, in a usable, secure, privacy focused, responsive, scalable, testable, maintainable, performant, efficient, resilient, safe, accessible, and 100+ manner

Not a very readable slide is it? It just goes to show what is on engineer's mind when they're writing that 10 lines of code.

This is why, writing code is a team sport. And why there'll always be more engineers than designers.

It's not possible for 1 engineer to be able to write code in all the ways we expect our software to be. It takes different types of engineers with different specialities to make up a team of people, who can collectively do all of this.

Having multiple team members will help remind each other to be accountable for different aspects of software engineering practice.

Need to learn...

In order for us to engineer web application in such ways, many of us will have to learn and use a lot of these tools and concepts

They may be a front-end focus engineer like myself, a backend person, or a full-stack which covers both side of these learning paths.

Where does accessibility fits into all this? Well... here [next]

But as you can see, it's a rather small part of the front-end engineering toolkit and practice.

If your developer is backend focused, or is a full-stack, they're less likely to even be aware of accessibility. It isn't taught in most courses

Even if you're a front-end developer, it takes a certain types of clients or products that focus on it so strongly.

And because there's so many things to learn and keep up-to-date with, we prioritise learning the things our work and our team cares about.

Want...

Priority, process, simple

Since engineers like myself is responsible for so many things and have to constantly learn to keep up with the technologies, I want 3 things in this particular order: Priority, process, simple

First, I want to prioritise things that are more important or pressing.

If I don't understand, or am not aware of the context or user problems of a particular solution, I will rely heavily upon what designers and product managers tell me what are important things to work on and why.

If assistive technology use isn't a part of the things product functions prioritise, I'm less likely to think about supporting it.

Second, I want processes to help them manage my load

This comes in the form of all sorts of methodologies. Often scrum and its family of ceremonies like standups, backlog refinement etc.

Lastly, I want to simplify as much as possible

Not because I do not want to do the work. Far from it. But breaking down into simplest and smallest units help me ship things out faster, and reduce the amount of in-progress things I need to think about.

Unfortunately, this also means that things which are not explicitly mentioned in the requirements or definition of done, can be easily missed.

Workflow management

Engineers

Solve problems via code
Lack experience with UX practice
Continuous learners
Cognitive load & time poor
Want clear priority, process, simplify where possible

How do you talk about accessibility?

Compliance? 'extra' work?

How do you work with engineers?

Often, not closely enough

Include
engineers in UX

Show, don't tell

As I highlighted, I gained appreciation for design not just because I was a designer, but by working so closely with designers. By falling in love with customer problems.

When I fell in love with customer problems, I go above and beyond to find ways to help resolve their issues.

Work stops being a pure code problem, fix this and upgrade that. The work starts being more... human and meaningful. I feel more engaged with any solutions because of that.

I'd encourage you to ask yourself...

How often are you talking about customers research to your engineers?

How often are they involved in your research and ideation sesions?

When was the last time they talked to a customer with you?

Do you talk about accessibility as you walk through your designs?

Do you annotate your designs with accessible copy and keyboard interaction order?

Do customer support raise accessible issues and does that issue gets prioritised?

Include and show engineers your process. It makes us want to go the extra mile now that we understand where you came from.

Lead by example

Embed accessibility in your practice

excited about accessibility
=
excited about design

@PraeSongprasit and @WebAccessClub

It's important to remember that accessibility isn't a standalone thing that you can test in isolation.

It's a mindset of creating a usable experience for everyone.

It still needs humans to work together to create something truly inclusive.

What are you, designers and researchers, doing, to get engineers involved in your processes?

Inclusive and accessible design only happens when we truly understand our users, and that the culture and processes reinforces the focus on that understanding.

When engineers are involved in the design process, it's easier for them to consider accessibility. It's just a part of writing good code and making useful software.

You thought you came to a talk about getting people interested accessibility. But in the truth is, they need to first be interested in design, and fall in love with the customer problems as hard as you do.

It is UX' job to advocate for users in both your designs, and to your colleagues.