Accessibility and Ouija Boards

Nathan Curtis: We're going to be hearing from Sorin Hamby.

They are a recovering font collector, who specializes in inclusive UX design and accessibility operations, in particular on leading equitable teams who center on shame reduction and mentoring.

In addition, Soren writes about UX for inside design, modus UX Planet, with writing in the areas of accessibility, diversity, inclusivity, and building a strong and diverse team.

if you could please help me welcome Soren Hamby.

Soren Hamby: I'm Soren.

is my mic working good?

Oh, it's not.

Am I, am I working now?

Oh, just speak up a little.

Okay.

There we go.

Alright.

Hi everybody, I'm Soren.

sometimes I get a little nervous speaking, so on three I want everybody to just yell your name.

Ready?

One, two, three.

[audience shouts] Oh my gosh, we're not strangers anymore, I know all of you.

It's so nice to be here, I'm so excited.

I wanted to talk really quickly, just setting the stage.

What are we calling accessibility?

Because a lot of people have a lot of different opinions about that.

accessibility for our purposes is the process of removing access barriers, providing the right support to fit people's access needs, including and especially people with disabilities.

I'm sure all of you have heard this statistic.

It kind of changes from year to year, but 19 percent of the U.

S.

population has a disability.

But what we don't really talk about as much is that 34 percent of the working U.

S.

population has a disability.

34 percent is huge, and that kind of controls for different, age related conditions, and also, children, really spoil the numbers sometimes, I don't know.

so let's talk about, a little bit about Ouija boards.

I chose this because I wanted to, one, we're close to Halloween, have the creepy theme.

but the other thing is that Ouija boards are based in mystery and exclusivity.

when you are using a Ouija board, the purpose is to talk to the other side, whether that be like ghosts or spirits or whatever, religious system you believe in, you might think that there is something on the other side of death.

And to do, any kind of communication, you need some sort of medium.

You need a translator.

it's very superstitious.

There's this feeling of, ambiguity.

There's a veil over the subject.

Like, how do we define accessibility?

How do we, do it?

and then there's this select few.

So there's this idea that accessibility people are set apart and that there's like all this interpretation and that it's actually inaccessible to a lot of people that practice, design and development.

This leads to a lot of common pitfall pitfalls.

Excuse me.

I call this the accessibility bottleneck.

So if you are getting started in accessibility.

your company is let's do it, we're bought in, let's hire someone.

We need one person to serve five scrum teams.

And that causes the accessibility bottleneck.

It's where you can't take a vacation, you, can't get anything done because you're constantly running from place to place, and you are the bottleneck, the accessibility professional.

Another common pitfall is just low commitment to people, processes, and policies being inclusive.

so this can turn up in we don't use inclusive products to actually do design systems.

We don't use them to make designs.

the employee experience for people with disabilities is, very bad, which leads to the third pitfall, which is no involvement of disabled people at any stage.

that's one thing that happens really, frequently, and unsafe environments for disabled accessibility specialists.

what tends to happen is that, we have this unsafe environment where people deprioritize accessibility, and so they then speak over people that are disabled that are saying, this is important, and this does matter.

And what this leads to, this exclusivity, this select few kind of mentality, and also just the demoralization of, disabled people is that the whole team gets demoralized about accessibility.

These are things that I hear all the time.

I don't feel like I understand accessibility.

There's too much ambiguity.

I'm used to being good at my job.

And that is the one that stands out the most to me.

Because that says, you take people that have years and years of development, design, or product experience, and you tell them, you're doing everything wrong, do it better, and they don't know how.

accessibility operations is the remedy to this.

It accounts for the needs of all your users, and involves all roles, not just a designer, a developer, a QA person in providing accessibility and it shifts the burden from one or two people to making everyone equally responsible.

This also supports different levels of learning and people that are at different stages in their accessibility journey.

And I say accessibility journey because it is not a checklist.

It's not a destination.

It is a process that you're always on.

I can't really talk about this very much without mentioning maturity models for accessibility.

this is the digital accessibility mat maturity model, which covers, five stages.

Initial awareness.

That's where you are like, oh cool, accessibility is a thing, let's do it.

Managed is that you have some policies, standards, and processes defined.

This usually looks starting to do a remediation project, getting a vendor, putting together some guidelines, putting documentation into your library.

but you still are usually reliant on outside labor and you get a lot of bottlenecking at this stage because it's managed.

Somebody else is doing the accessibility as a layer after all the other work is done.

defined is the third stage where processes are starting to be implemented across the organization.

quantitative is where you start focusing on measuring accessibility.

And optimizing is working on process improvement and culture.

I've I simplified these for our purposes, which is awareness is the first stage, UI or design system accessibility is the second, accessibility and service design is the next.

once you start moving across the accessibility maturity model, you start thinking of accessibility as more than just, we have to make our UI work with assistive tech.

You start thinking of it as, how can we design products with requirements that consider accessibility?

The next one is operationalizing, and we're going to talk a little bit more about this.

But operationalizing is when you start delving into things like design ops, dev ops, where you want repeatable and also consistent across an organization.

that's when you start operationalizing.

And then the last one is a culture of accessibility.

So this is just a little bit easier way to digest the maturity models and to think about accessibility.

one of the things about having an accessibility practice is you usually are supporting a lot of different levels of learning.

So you have people that maybe just went through boot camp.

You have people that have been working in accessibility for years.

You have people that are experts that have been doing this for, 15 years.

And so I have a couple of different models that I've named.

these names are very optional.

You do not have to call them this.

But, The ringer is that when you have a few knowledgeable people, again, bottlenecking.

The mean girls is this exclusive kind of group where you might have like a council or you might even have some people that are guiding the process, placed strategically, but you don't have deeply knowledgeable people throughout your organization.

World Peace.

This one is my least favorite because everyone is responsible, one size fits all, and nobody really knows how to execute it.

They're like, what are we doing?

I don't know.

And then the sled dog is my favorite one, which is distributed and varied.

So when we think about a sled dog team, I don't know if you've seen the movie Balto, but Balto really got all the credit for that.

There's a lot of different positions on the sled dog team, and you can't really have more than, a couple of, dogs in a team without having a varied set of skills on the team.

And what I mean by this is, you usually have one or two lead dogs, uh, but if you had all lead dogs, then the sled would not work, because you don't have people to carry, the back end to pull most of the weight, and you don't have what's called swing dogs.

A swing dog is the dog that helps the whole thing turn.

so this is very strategic positions when we think about accessibility.

and then you have team dogs, which you have to have a certain number of team dogs for how many pounds you're carrying.

I, just love that there's a baseline expectation that everybody is on the team.

And then you have the wheel dog.

And these are the heavy lifters, in accessibility this is going to be your deeply technical people.

It's going to be the people that are in the weeds every day as ICs.

But I can't leave out the musher.

A good musher will, is our select dog driver.

It's someone that runs along the side.

But often times you do have some people that just stand there and yell directions at people.

This is probably my most optional position in the accessibility dog sled team.

but if you have a good musher, they can actually really help you avoid obstacles.

They can shout commands, keep the team all on the same track.

what does this look like when you start thinking about accessibility roles?

You could have a position where it's just your role, I am a senior design manager, plus having accessibility knowledge.

And that is where you expect everyone to have a baseline knowledge, and you've got to provide that training.

accessibility specialty IC roles would be like a subject matter expert, or a coach that's helping everybody upskill.

And accessibility leadership roles is where you have a program manager, an accessibility director.

And I've even seen VP of Accessibility or a Chief Accessibility Officer, which is fantastic to start seeing in the field, just like we see like a lot more CDOs or CXOs.

And it's effective teams have room for everyone on them.

If you've seen this diagram before, the golden circle, the what is the outside, the how is the middle, and the why is the center.

And this supports our theory about design systems having a lot to do with accessibility because it supports staged learning and T shaped knowledge.

And what I mean by that is when you have a design system with documentation, you can dive really deep into just the smallest component.

And you can learn everything that you want to learn about forms.

You can really look at it and say, I'm going to get really good at accessibility for forms.

And it doesn't expect that you will know the entire breadth of everything that accessibility can touch in a product development cycle.

Uh, this creates repeatable outcomes in execution and when you're defining work.

if you tell somebody what to do, Hey, I'd like you to change this button.

It doesn't meet contrast requirements.

Then you're just giving them the solution to that problem.

It's the whole teach a man to fish sort of thing.

If you tell them how to do it, you're helping them learn a skill, but if you tell them why to do it, and explain your thought process.

Then you're creating someone that can then apply that knowledge to a different problem and not just the problem that you've told them how to solve.

I highly recommend listening to Anna Cooke's, Auditing Design Systems from last year's Clarity.

And we also will have Homer Gaines talking tomorrow about, more about accessibility and design systems.

And I made this slide before we had another accessibility person speaking, but, we'll have another talk tomorrow as well.

The last thing I want to talk about is building a culture of accessibility.

if there's no priority, and it's not even being considered by leadership, then it's not going to happen.

A lot of people are just like, oh, we'll add it to the backlog.

But I have things that have sat in backlogs for two years.

If you don't create space for it in your regular product development cycle, just like tech debt, just like design systems, it's not going to happen.

And then it's also not consistently applied across products, people, and, I'm sorry, I have products twice there, products, people, and procedures.

That is really important because in these larger organizations, you need consistency because if something isn't consistent, then it isn't going to be accessible across the board.

The other thing, which we talked about pitfalls, was protecting disabled people inside of accessibility and design teams.

I actually have a vision disability and I have run into so many designers that are like, you are the first person I've ever seen that is vocal about having a visual disability and being in design.

And that just astounds me because I do know so many people that have said this.

But they're afraid that they will be viewed as not being able to do their work if they disclose that they have a visual disability.

I've also heard the same thing about people who are going through hiring processes and thinking about, I need an ASL interpreter.

And it's not offered.

It takes a lot of time sometimes to put these things in place.

And it leads to poorer job prospects and less employment.

the disability professionals explicit attitudes, and implicit attitudes survey that was done recently showed that while we say explicitly, oh yeah, I have no problem with people that are disabled, or no preference, that, there actually is a large number of people that explicitly say, I do prefer non disabled people.

Which, to me, that would, that's just wild to say, that you would explicitly admit that.

But the implicit is even worse.

We see that there's a lot of people that have a strong preference for non disabled people, or have no preference.

And the preference for disabled people in accessibility is really low.

And so this is what this looks like overlaid.

different kinds of prejudice that people in accessibility and working with disabled people face.

being a disabled person, which it seems like that would be a very good basis for understanding the work that you're doing.

So I wanted to talk a little bit about combating ableism.

this QR code takes you to the Harvard implicit bias test, test your own bias.

You don't have to report on it.

it's just a good way to check yourself.

There's also a lot of other tests on the same website, that test implicit bias on many different facets of people's identity.

hire and promote more disabled people.

One thing that I've seen is that, people don't make great use of job boards that are out there.

and they also tell me that they don't get considered for leadership roles.

And so we see a lot of people that have a lot of privilege, in a lot of different ways, and then also are not disabled people leading accessibility teams and making some of the same mistakes of Not having a good culture around accessibility over and over again.

also we talked a little bit about accommodations, one of the best things that you can do for hiring an employee experience is to offer things without people having to request them.

It's always really nice when I go to an event and they say, do you need any accessibility supports or accommodations?

But what if you didn't have to disclose that?

What if every meeting you could turn on captions, or there was an ASL interpreter at every event without someone having to ask for it?

That is the ultimate in kind of including your employees with disabilities, and thinking about having that in the hiring pipeline as well.

A culture of accessibility is comprised of attitudes and actions, and so some of those things can be remote work without accommodations.

So Why, should I have to disclose my disability in order to, be able to work remotely when most of our work can be done remote?

I find that the hybrid model often limits people that are disabled because even if they do get an accommodation and they say, I want to work from home, I need to work from home because, I, these reasons, they still don't get promoted.

They still are excluded as part of the team.

And, in order to change this culture around accessibility, we need to start including more disabled people in accessibility.

Also, under culture, compliance.

we have a, this balance between compliance and inclusion.

compliance is about legal standards.

it protects companies, it's not very flexible, and it often only takes one disability into account at a time.

Yesterday in the workshop, somebody brought up the stairs that are built into a ramp.

And that often is really great for people that are using wheelchairs, but it's not so great for people with visual disabilities.

compliance is only looking at, is this ramp, wide enough?

Is it tall enough?

Is it, not too steep?

It doesn't look at, would someone with a visual disability be able to use this?

Would someone with, any other kind of disability be able to use this accommodation?

but inclusion looks at intersections of disability.

It allows for subjective criteria.

like things like alternate text on images are often, just spit out.

Like we, we really think about the objective criteria of do we have it, but not about the subjective criteria of is it good?

and then also inclusion allows for designing employee experiences.

So when we think about how do we, start thinking more about accessibility, it's intrinsically tied with inclusion.

It's intrinsically tied with having more diverse teams.

But let's keep the magic.

Ditch the mystery behind accessibility and start getting people hyped about it.

One of the things that I think has been the best tool for me is memes about accessibility.

developer memes out there, you have like I'm about a div, but I will have somebody put one in one of my discords that's you wouldn't download a div and things like that just are really fun and get people hyped to be in on the idea.

if they don't know what it is, explaining it is, it's a really great way to get people interested in accessibility in a way that's not just like here, read this incredibly dry set of guidelines.

Also, making it fun, having transparency and support groups are really great for that, and staggering it around different types of learners.

so that's really all I have for right now.

I do have, some resources.

The A11y project is a great place to go for open source resources, and also you can always check my website for stuff.

thank you all for having me.

Nathan Curtis: Soren.

I have a number of questions here, and I want to start with a little bit of role play, because I found myself in almost opposing situations, and I'd be curious how you'd react as a manager or a driver of design system work.

The first is when a owner of a design system that you're trying to establish says, Accessibility really doesn't matter.

And everybody on the team, other than going, uh, needs to make a choice about what they do.

What would you react to say to that, stakeholder?

Or, what would you say to the team after the stakeholder walks away?

Soren Hamby: the first thing I like to do is to find out what's important to them.

So if they say accessibility isn't important because it's the right thing to do, find out what would change their mind.

So there's a bunch of different models of thinking about accessibility as, not missing out on the target market that disabled people provide.

there's the, innovation model where you're thinking about things that have come from design for accessibility, like Siri.

Segways, like all these different things that were created to support accessibility are now things that we use every day and have been just amazing innovations in the market.

So just digging into some of those different models, I could go on and on, but, finding out what's important to your stakeholders and then speaking directly to that.

legal compliance is, often, not my favorite thing, but it is effective with getting stakeholders to care, because they don't want a lawsuit, and they don't want that kind of risk hanging over their head.

Nathan Curtis: Yeah, that's actually a trigger of the opposing, question that I have.

One time I actually left Clarity, had a new client, and the trigger of funding the design system was when the VP of product said, oh, this is going to help us address accessibility.

Sold.

only because they're looking to mitigate the risk, that they fear.

but then there becomes the impression that now that we've had the design system address accessibility, it's a solved problem.

And so how do you help people distinguish what's incorporated into the system from the work left to do?

Soren Hamby: Sure.

I think that maturity model that I went over, where you're thinking about, okay, we've fixed the UI, but that's only really the second level of maturity.

You've got many more levels to go.

Like, how do you retain people with disabilities?

How do you even attract them?

You have to make things more of a culture around it, rather than just Okay, we checked the box.

We made the website that's published right now accessible.

But, I think that service design portion at level four is also just really important.

I worked with Waymo for a while on trying to create features for people with disabilities.

And having that kind of insight into, all right, we're going to take this whole entire list of features, and we're going to figure out what are the three top ones that would help people with disabilities to implement in the next few months.

We did testing a lot of thought into what people need on the whole journey, and that's where Service Design, I think really comes in.

And it carries a lot of the weight because design systems, like we've been talking about, are meant to support people and they're meant to support the people that use them and the people that are the recipients of them.

But you can't design, you can't fit everything that could possibly happen into a design system because you're going to have to keep updating it.

If you bring in a new feature, you might have to bring in a new component as well.

So all that has to be considered and constantly changed and just kept up to date.

Nathan Curtis: So if I'm a, uh, one of the leaders at an organization that can scale, and we're at level two, the sort of UI design system level that you talked about, and the subsequent levels are, I think it was service, then operations, then, culture.

Can you paint a picture for me, whatever number of years down the road, if we get to level five, which step is the highest step?

Which one takes the most effort or is going to be the most difficult to surmount to level up to the next one and why?

Soren Hamby: I think the majority of people that I've talked to, either just, about design systems as practitioners or companies that are looking to hire a consultant.

they're at, level one or level two.

there's also been a bunch of different, design maturity surveys.

when I used to work for InVision, we put out that every year and that kind of work, I see the same trends.

with regards to maturity, UX maturity, that's another area that people show like really high maturity levels in like the first two levels, but then the last three are how do we get there?

And I think that's what, operationalizing things really gets you is you have someone that's in charge of kind of steering the ship.

otherwise it's just okay, I have this grass grassroots kind of thing where I'm just talking to everybody about accessibility.

And you have to be in the know, you have to know that okay, yeah, I go to Soren for that, or I go to this person for that.

And again, you get into bottlenecking because they don't take responsibility for learning about it themselves.

They're just going to this like managed option where it's okay, I do this work and then I give it to you and you do the accessibility.

but really building into your argument, the idea that like, you can save so much time if you have a culture around creating accessibility throughout the process and not just tacking it on the end, I think is really powerful.

Nathan Curtis: Where are the boundaries of our program's responsibility?

What burdens do we bear versus are legitimately bared by other parts of the org?

And our relationship with design ops sometimes gets overlapped, misinterpretations.

I wonder, in terms of your maturity model, relating design systems to accessibility, does the design system program's burden begin and end at level two?

Are they, is it the design system that's responsible for elevating to level three, four, and five.

How does that relate?

Soren Hamby: That's a great question.

for me, the design system also supports a lot of knowledge, which I could go really deep into, but we touched on it.

Because you can dive into those components, you can provide documentation for people.

And so it can be a vehicle for learning.

And it can be a vehicle for saying, accessibility is part of our culture because we don't exclude it, we don't leave it in like some other tab.

it's part of the usage documentation that we put together.

And so every component is designed for a feature that's accessible.

Every component is designed to be accessible by assistive tag, but then we're making it easy for people to learn about design systems and also to learn about accessibility at the same time.

Nathan Curtis: I didn't write this question down, but you totally made me think of a basic and perhaps in the weeds nerdy question.

You've got this component documentation page.

You just said it's not on another tab.

And that's sometimes a way that people say we've got our examples tab, our code API tab, our design guidelines tab, and our accessibility tab.

And that's a way to structure the content.

But I hear you saying, not only should it be a part of the design guidelines and code API tabs and woven in there, but it's not a section at the bottom of those tabs, is it actually just woven in everywhere, and in which case, how do I do that?

is that too nerdy a question, or how would you structure that to tell the story?

Soren Hamby: I would say that once you start on this accessibility journey as a corporation trying to upscale things, it's really about, trying to find ways in which you can make accessibility part of your definition of done, your definition of ready, and your definition of excellence.

having a lot of different people work together on this, let's say you don't know how to do that.

If you have somebody in your organization that can help you with starting to learn, like, where do I look for things?

what kind of things do I need to be considering?

Then they can go and repeat that process.

So you're like upskilling each other as you work together on a design system, which I think is, really beautiful and really powerful.

And it's how I personally love to work on accessibility is through design systems language because it's just, it's a really powerful statement to say accessibility isn't separate.

It's part of everything that we do.

And it's part of even the documentation that we make.

Nathan Curtis: As a last question, how would you advise someone whose ceiling of scale is a lot lower.

I oftentimes bring my perspectives managing large design system programs and then somebody's like I'm just one designer and I'm making a design system and you have this maturity model that involves two different groups of different types of leaders and I want to ask well, how would you prioritize or order those things, but maybe even more simply If they have a ceiling of scale of people, how do they lift accessibility into their org if they don't have that level of scale of roles and investment?

Soren Hamby: I think the best place to start is At home.

so if you have a design team at one of one, you start figuring out like what are some of the, low hanging fruit that I can, pick, like I can make sure that I'm trained, like I have control over that.

another thing is to just be able to say, okay, what is the roadmap like?

That's what our workshop was diving into yesterday was.

What do I need to get to that next level and just even breaking it down and say Okay, these are the ways in which I feel like we're not there and these are the steps I need to take to get it is a really powerful way to, to show, people, if you don't have that option to say oh yeah, I'm just going to go get some budget, we're going to hire some people, you can at least say Hey, I need more time to do this, or I need to have a bigger estimation of effort assigned to accessibility.

So there's like little things that you can do to, put accessibility in if you have a smaller team.

And sometimes just like giving people an idea of the scale of the problem is incredibly powerful because if you take it to them and you say, Hey, we have a backlog of so many accessibility issues.

And when we run the scans, we're still not accessible.

And when we do manual testing, like the customers are unhappy.

So you start adding all these little data points in, and then it becomes okay, this is something we can't ignore.

And I've seen these, like this triangle diagram of you have some immovable points of like effort, money, and time.

So you can move usually at least one of them.

But the other two sometimes are fixed.

So it affects how you decide to either spend effort or spend time if you don't have the money to hire more people.

Nathan Curtis: That's great advice.

Thank you so much.

Thank you.

Please, a hand for Soren.