Webflow Design
Published in

Webflow Design

Accessibility for Everyone: an interview with Laura Kalbag

Laura Kalbag talks to me about her recently published book on accessibility.

What role does accessibility play in your design practice? Are you thoughtful about barriers that keep someone from accessing your site? Can you name them? Are you on the search for solutions? I sat down with Laura Kalbag, author of Accessibility for Everyone, to discuss why and how you should make accessibility a focus of your design practice.

With more and more designers pushing the envelope of web design, it’s important to remember the purpose our sites serve and that the best designs are accessible to anyone wanting to experience them. It’s time to push ourselves, our teams, and the design community to prioritize and incorporate accessibility as an inclusive and fundamental approach to design and development.

In her book, Accessibility for Everyone Laura Kalbag breaks down some of the most common myths about accessibility on the web and shows us how we can start making small changes — right now — that will have huge impact for the people using our sites. If you haven’t snagged your copy of Accessibility for Everyone — what are you waiting for? It’s a must-read for anyone working on the web.

I’m thrilled we had the chance to chat with Laura, and we’re equally excited to share the conversation with you now.

Which roles on a web team need to know about accessibility and inclusive design?

Everyone! That’s why my book is called Accessibility for Everyone. And that’s why in the book I tried to dip into as many disciplines as possible — I wanted it to be clear that it’s an equal workload between all of us.

I could tackle the accessibility of a site’s design and front-end development, but why make interfaces accessible if the content isn’t? We need people who write good copy and produce accessible videos with transcripts, captions, and audio too.

It’s a team effort.

In your book, you talk about your brother, Sam, who lives with cerebral palsy. Is watching him interact with the internet what led to your interest in accessibility?

I’ve always been very interested in accessibility. When talking to other accessibility people — like proper experts and professionals working in the field — about why they got into the field, they’d say things like, “As I got older, I could empathize more with the need for accessibility,” or “I have a disability,” or “I have a friend or family member with a disability.”

This made me realize that my interest probably did stem from my experiences with Sam growing up. But Sam’s cerebral palsy was so much a part our every day that I never considered it my inspiration.

We hadn’t even really discussed his use of the internet in much depth until I started researching the book and we sat down and had a three-hour conversation. It actually taught me a lot about him that I didn’t know, because we hadn’t used the internet together very often.

So Sam and what else put you on the trail of accessibility?

When I was learning about web design and development about 14 years ago, web standards were becoming more widely adopted. We were coming out of things like table-based layouts and people were really starting to understand the need for a good experience on a site.

People working on web standards were also talking about the benefits of web standards for accessibility. People writing about web development, like Dan Cederholm, Andy Clarke, and Molly Holzschlag would always mentioned accessibility.

The things they talked about really stuck with me — like the importance of writing semantic HTML and having a decent color contrast for people who are color blind. I would try to include what I was learning in my designs.

You talk early on in your book about accessible design versus universal design. Can you talk more about that?

Yeah. I think about it like this: imagine if you had a shop, and your shop was raised quite far above the pavement. You need stairs out front so people can get in, and then you realize, “Oh, someone in a wheelchair or a parent with a stroller can’t access the shop. I’ll put a ramp on the side for them. It’s a side exit and the ramp doesn’t look pretty, but it will do.”

That’s accessibility.

Say, instead, when you built your shop, rather than thinking, “I’ll put stairs in,” you think, “Okay, maybe I’ll put in combined staircase and ramp access. I’ll make sure I have handrails and maybe I’ll put some colored stripes on the steps so people can easily distinguish between them when they’re walking up and down.” You starting to think about the needs of a much wider group of people.

That is universal, or inclusive, design.

The idea is to make sure you’re designing for the widest possible audience from the beginning, rather than designing something and then thinking, “How can I make that accessible for people with these particular needs?”

So teams should build this mindset into their process from the start, versus tacking it on the end?

Exactly that — yes.

Because accessibility runs through every single discipline. And that’s the thing about being inclusive and designing for a wide range of needs — your copy has an impact. Your visual design has an impact. The way you code your components has an impact.

So if you’re thinking about all those things from the beginning, you won’t need to make loads of last-minute changes. And you’re also not going to make any really horrible errors that make it impossible for someone to access your site — because you’ve thought about their access from the beginning and have removed potential errors throughout the design and development of the site.

If we want to take a universal approach and we’re not a diverse team, how can we make sure we’re not overlooking certain groups? What can we do to make sure we’re not missing anything?

I think the lowest budget approach is to diversify what you’re reading and the kinds of experiences you’re following. If you can talk to people who have a wide range of needs, then do that. If you’re not able to find people to talk to in person, then follow people online or Twitter.

There are hashtags like #AXSCHAT where people talk about their accessibility needs and possible solutions — anecdotes from people with such a wide range of needs. Listen in on what they’re sharing, what they need, their difficulties. You’ll start to understand how what you’re doing can be more positive.

You mentioned the hashtag — which is great. Who should we be following on social media?

The A11Y Project has a whole list. Generally, the list includes people who talk about accessibility in terms of work, but many of those listed can also provide a more personal perspective, as they have accessibility needs themselves. .

Inclusive design reminds me of the slogan “Nothing about us, without us” — a reminder to center the voices of those we build for. In your book you define colonial design as “believing we know what’s best for others, despite our different needs.” How do we avoid it?

The best way to cater to as many people as possible is to have a diverse organization covering a range of needs — we’re always best at designing for ourselves. A lot of successful products are built from people going, “I have a need for this, so I’m going to make a thing to fulfill that need.”

A diverse organization will better meet the needs of a diverse group. I work in a two-person, one-husky organization and I can honestly say it’s quite difficult. We can’t really diversify beyond what we are right now, so how do I make up for that?

I consume as much information as I can, talk to as many people as possible, and educate myself, without putting the burden or expectation on people with disabilities to educate me about disabilities — that’s not cool. They’ve got their own lives to deal with. They don’t need me asking foolish questions.

I do as much work as I can on my own and talk to people who want to talk, share their stories, and educate me. I’d say it has a similar crossover with social justice — we have to learn to educate ourselves and not make it about ourselves.

That sounds like a great approach to learning about any social justice issue — consume as much as you can. Listen. Reflect. Do better. Repeat.

Yeah, and just trying to do better at everything. I think that that’s the best approach. Not making it about ourselves, not being defensive if we’ve done something wrong in the past — because particularly in accessibility — it can be really hard to hear that the one piece of design you’re really proud of and you think is gorgeous, is actually not accessible to screen readers.

No, you didn’t deliberately exclude someone — of course you didn’t. But now you know. You have no excuse and you need to be better. And I say that with kindness. Make yourself aware and improve it.

We’re always iterating. There’s no such thing as 100% accessible — what suits one person may not suit another, and some needs are in conflict with each other. But it’s important to always do the best you can with what you’re designing.

Avoid the mentality of, “Okay, I’m done. I’ve done enough.” We can always going back, learn more, iterate, and make it the best thing possible. That’s how we make things as inclusive as they can be.

What’s the one thing you most wish people knew about accessibility?

The design of the web is generally pretty accessible by default. It’s all the clever stuff we try to do that makes it less accessible.

Browsers work really hard to interpret HTML and the code you’ve written in a way that’s accessible. They might make a component look different across different devices — a dropdown box in Safari on my Mac will look very different from a dropdown box in Safari on my phone.

That’s because people designing Safari decided that if you’re using a touch screen, you might want a bigger touch interface. You might want to scroll through the items in a different way than when you’re using a mouse or a keyboard on a desktop.

Browsers do a lot of work to make that possible. So if we use their existing components, and don’t add JavaScript to customize them in a way that stops that from working, we can have inherently accessible sites.

Obviously there are a lot of ideas in your book about ways to make the web more accessible. What are some of the simplest changes teams can tackle?

One of the easiest changes to make is to make all your text a bit bigger — tiny text is hard for everyone and nobody wants to read it. That small difference has a huge impact. Also make sure you don’t disable zoom so that people can zoom in if you haven’t made your text the perfect size for them.

Don’t rely on color to convey information. It’s quite common to communicate errors with red highlights or text. But what about the people who don’t experience the web visually? If they’re using a screen reader or a braille reader, they may not be able to distinguish a change in color. But also consider people who are new to computers or the web — they don’t necessarily know web conventions like “red = error.”

In these instances, provide text that explains what’s wrong, and how to fix it. A little bit of consideration can go a long way.

Those are great — thank you! What’s one thing a site could do that would make it an accessibility rockstar?

One of the most technically tricky things to do is make sites screen reader- and keyboard- navigable, so that people using them can get around your site. It’s not necessarily difficult with tools out there to test with, and ARIA.

But the tricky part — because the interfaces we design vary so much — is that you’re unlikely to find another site exactly the same as yours to duplicate what they’ve done for screen reader and keyboard accessibility, and transfer to your site. It requires a bit more work and digging to provide the best solution for your context. You also have to test your particular interface to make sure it works for real people.

Putting in that effort really says that somebody cares.

Have you seen a cultural shift in the acceptance of accessibility since you started doing this work?

Social media and being connected has been very beneficial for us to understand each other’s needs better. We have more access to people we wouldn’t necessarily have met before. I met accessibility experts because of my book — suddenly I was on their radar. It would have been quite difficult for me to meet people like that before.

Someone recently wrote about making Twitter more accessible by choosing to write alternative text for your images. (Twitter > Settings > Accessibility > Compose image descriptions.) It went around Twitter like wildfire. Accessibility experts were chiming in to share how to write useful, informative alt text — what to include and what to disregard in your description.

There was a lot of interest and I think that’s reflective of the wider world. People are becoming more interested in inclusivity and social justice, in general. And they’re more willing to make an effort when it comes to design and making good sites.

I’m wondering if there’s something you know now — something that’s become second-nature — that you didn’t before you started really thinking about accessibility?

I come from a graphic design background, so I used to make some of the most pretentious, ridiculous designs. I made some beautiful sites that weren’t accessible at all.

A lack of alternative text was one of the ways my sites weren’t accessible — I didn’t use it or think about it, really. Until someone told me you can describe images for people using screen readers. Since then, I’ve described every single image that I’ve placed on a website — because I can and it doesn’t even take long!

I’m not sure I’m very good at it. My descriptions are probably not very good, but I try.

I try hard to make the alt tags on the Webflow blog helpful, but I’m not always sure I’m doing the job. Any tips on writing better alt tags?

A lot of the images we use are probably decorative and not necessarily something you need to describe. Sometimes they’re great as visual aids but don’t have the same value as text.

If a picture is decorative, keep the alt text attribute, but leave it empty. That tells the assistive technology that we could have added an attribute here, but we chose not to because the image isn’t relevant. So it skips past it like it wasn’t there at all.

<img src=”image.jpg” alt=””>

This helps people who don’t experience a page visually — they’re not forced to read irrelevant additional information.

Trying is what makes a difference. A lot of people have said to me recently that accessibility is such a broad topic ,which makes it very intimidating. The breadth makes it difficult to know where to start and leaves some of us feeling like, “Unless I get it perfect, why should I do it? I don’t want to make things worse.”

But really, it’s hard to make an inaccessible site worse by trying to do the right thing. It’s very hard to actively cause big issues. It’s much easier to make those little changes. Do one thing at a time. Pick one thing you’re going to change today, and save the other things for another time.

Because that alone will make a difference to someone.

You wrote about the misconception that accessibility is best left to the experts. What other myths are there around accessibility?

One is that accessibility is all about screen readers.

Accessibility of a physical space isn’t just about people with wheelchairs. We might design a space to benefit people who find it difficult to walk, people using walking aids, people pushing strollers, or people carrying big boxes. We might design a space to be better for people with hearing difficulties or for people who are blind. Each person’s need impacts how they can access and use the space — just like on the web.

The tiniest change can take you from not having accessibility needs to requiring assistance. Maybe you break your wrist and you can’t use your mouse for a while. Suddenly you’re catapulted into a completely different set of needs.

People with glasses don’t necessarily see themselves as having a disability, but take their glasses away and make them use the web — now they have a need! So, yes, accessibility isn’t all about screen readers.

What’s the biggest mistake people make around accessibility?

The biggest mistake is also around screen readers. There’s this idea that we need to give people using screen readers extra instructions on how to use our site — instructions only visible to screen readers. But people using screen readers already know how to use the web.

They have the same understanding of the design conventions, just from a different perspective. Why provide them with potentially patronizing instructions when all they want is a simple, straightforward interface?

Is that one of the things you learned by paying attention to what people were saying?

Yes, it’s something I’ve heard from listening to folks who do use screen readers — that it’s frustrating to have people assume you’re not capable of understanding a simple page.

We can get so much from listening to anecdotes and stories about how people use the web. Often we don’t talk about how we use the web with each other. I don’t know what your browsing experiences are, and you don’t know about mine.

If anything makes us more open-minded to the diversity of ways to access the web, it’s opening up and listening to each other. It’s a very valuable mindset for accessibility. It gets you away from assuming everyone uses the web just like you do.

Who on a team absolutely cannot get away with being unfamiliar with accessibility?

Whoever is the gatekeeper before something gets released. Especially when you’re working really hard and you’re trying to release something quickly — it can be easy to discard accessibility as “something we’ll get to later. Something we’ll improve with the next iteration.”

It’s good to have a gatekeeper pointing out the issues. And you don’t necessarily have to be really great in any one discipline. You just have to be able to know how to use your computer and other people’s computers in a way that might mimic other experiences. Gatekeepers should know how to test with a screen reader, on a touchscreen, and without a mouse.

If you’ve got one person pointing out the bugs, you can figure out who needs to take ownership for that bug. If it’s a development issue, the developer — even if they don’t know about accessibility — can figure out a fix. Because that’s all any of us do in our jobs: when we don’t know how to do something, we learn it!

Which brings us back to how great it would be if everyone on your team saw the importance of accessibility. Once things landed with gatekeeper, there would likely be fewer flags.

For sure. And then there’s not the battle of having to make the same arguments again and again to convince people. That’s also why having leaders who care about accessibility is so valuable — if it’s being dictated from the top and from the beginning, people are more likely to prioritise accessibility.

How can we tackle a team’s lack of interest in accessibility — if that’s something we face?

One of the best things to do is to watch someone with accessibility needs use your site or product. Because sometime it boils down to a basic level of compassion. Usually when people don’t care, it’s because they haven’t encountered another person’s experiences for themselves.

There’s no pride in building a site that we watch people struggle to use.

Do you think it’s a lack of understanding or firsthand experience that keeps us from implementing accessibility standards?

I think it’s a perception that accessibility is hard to implement. Also not understanding how difficult our sites are to use when we don’t care. There are so many little things that add up that can make so many sites suddenly easier to use.

What’s the best time in the design process to address accessibility issues?

From the very beginning you should design with accessibility in mind. And be frequently testing as you go. You don’t want to spend loads of time building an interface to realize at the last minute — when you have no time to change it or do anything about it — that it’s really hard to use.

I also wish that when people wrote about design and development, they’d talk about accessibility in the same way they talk about performance. Loads of things we do from the very beginning of the planning process affect the performance of the site — the same goes for accessibility.

I’d say that accessibility considerations start even earlier than performance considerations. You need to start thinking about accessibility from the moment you put the first word into a blank text document.

Besides your book, what accessibility resources should people bookmark or buy right this second?

The A11y Weekly Newsletter by David A Kennedy is great, and it has a section for folks who are new to accessibility (A11y) every week.

Books you should buy

Accessibility agencies with great blogs

Other great accessibility resources

More accessibility resources

Reader, what are your biggest questions and concerns around accessibility?

Making the web more inclusive is a big, important topic. I’m so thankful Laura took the time to talk with us about the kind of impact we can have on the people using our sites when we design with accessibility in mind. We’re inspired to learn more and do better — I hope you are, too.




Design thinking about designing design tools for designers.

Recommended from Medium

Daisylegs Case Study

Tool 1: The MoCa Action Model

Elon Musk And Grimes’ Baby Gets Custom Shoes From Rombaut

Building your corporate or small business site on WordPress

Design for Interdependence

Design Thinking at HCL

Representation of a Person’s Cognition

Health Care — Doctor’s Appointment booking app — UI/UX Case Study

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
shannon fisher

shannon fisher

Editor. Writer. Knitter. Sparkplug. Spaghetti squash enthusiast.

More from Medium

Why it’s (usually) better to copy others

Doing Culture Right, From the Inside Out

Five years into my practice as an academic allergist/immunologist, my perceptions continue to…

Transitioning to a Design Manager