Beth Qiang is a front-end focused, fullstack Senior Software Engineer at Lob. She has been chosen to speak at Axe-Con, a digital accessibility conference running March 15-17, 2022. We caught up with her to learn more.
Lob: Why Axe-Con? What kind of topics does the conference cover?
Beth: I found out about Axe-Con through a co-worker and attended as a participant in 2021.
It’s hosted by a company that does accessibility audits among many other things accessibility-related, so it’s all about accessibility in development and design on the web and other platforms.
I thought it was great in terms of the diversity of speakers, and the content presented was super useful. Last year, I came away with a deeper awareness of how those with disabilities can perceive the web, and the kind of specific and actionable items I personally could implement—or advocate for on my own teams. For example, how to test accessibility (I hadn't done a lot of accessibility testing before coming to Lob). Specifically, I learned about the axe-core library and how to use it to integrate accessibility testing into my test suites.
Well, I’m on the mailing list and got an email from them recently stating, "CFPs are open." I thought, "Maybe I have stuff to contribute this year." So submitted a CFP and here we are!
Lob: Why is accessibility a topic that interests you?
Beth: I think it's super important, mostly because accessibility, at least to me, means that everyone can access and use whatever you create. It seems silly for people to create things only for people who are just like themselves, in the sense that they may be sighted or may not have any sort of physical limitations. It’s a sad thought for me that there are people out there who can't use apps or platforms because unintentionally or not, they were created only for a very specific kind of person. To the individual left out, it can be perceived as the developer didn't think it was worth their time to consider accessibility and make sure that everyone could access what they created.
Lob: I know that you are essentially a self-taught developer (with humble beginnings at free code camp and then Full Stack Academy bootcamp) so I'm curious which came first, the chicken or the egg? That is, did your interest in software development come before your interest in accessibility, or the other way around, did you see software development as a way to impact change in that area?
Beth: I would say the development part came first because that led me to a greater awareness of the importance of accessibility, particularly on the web.
That being said, throughout my lifetime, I've always believed strongly in, and have worked towards, the cause of diversity and inclusion. So I think it's kind of a natural extension of that: wanting everyone to feel like they, one, belong in the world, and two, are able to use these things that we create. Because I am a sighted individual for example, or don’t have physical limitations, it wasn't until I started software development that I realized, “Oh, this is an issue; people who are not like me cannot experience the web in the same way.”
Lob: Was there a particular project you worked on that really brought this to light?
Beth: A few years ago, I was working on a learning management system (LMS). We were required by governing bodies to make sure that our platform was accessible to people who had all sorts of disabilities. We had a lot of accessibility audits that exposed some gaps, but also got bug reports from students who couldn't do one thing or another. They couldn't send in their assignments easily, or at all. They weren’t able to collaborate with their peers like others could, or access their grades; big issues like that. That was my first real experience of the potential impact.
Throughout my lifetime, I've always believed strongly in, and have worked towards, the cause of diversity and inclusion.
Lob: What is your talk about and what do you hope that people will take out of it?
Beth: Lob has a user dashboard that offers account management, data and analytics on mailpieces, and so forth. As a part of our dashboard re-platform efforts, we created a UI component library. This is basically just building blocks for any app. For example, a singular input field, or a singular checkbox, that together, you drop in and compose a webpage. One of our primary goals was to at least meet a baseline level of accessibility since the original dashboard was not usable in many respects by those with disabilities. We had to ensure that someone who is a keyboard-only user, or a screen reader user for example, could easily navigate and use our site. Another good example is considering color contrast for those who may have low contrast or low vision.
When we began looking at the button components for the dashboard, like “Success” or “Error,” we actually requested the design team revise our brand colors because they did not provide enough contrast to meet our desired accessibility standard. Those same UI components are now being used across all other front-end applications at Lob.
In that process, I began to think a lot about how flexible or not to make our components. The idea in the future is that we will open source our component library so that others can use the same components when they're creating their own things. It’s asking, what's the balance between flexibility—in terms of allowing people to do what they need to do with your components—but also still baking in a certain degree of accessibility, so that the developer doesn't have to do all of that on their own.
Lob: So, let’s say...As a baker, I can use a prepackaged cake mix. I can add nuts, make a two or 10-layer cake, or top it with vanilla or chocolate icing—but there are certain ingredients already present. Thought must go into what is included in the mix to be the most beneficial to me, while still allowing me to do what I want with it?
Beth: Exactly. So in my talk [How a Developer Can Break Your UI Component Library’s Accessibility, and What To Do About It], I'll break down the decisions that developers will have to make about what to include and enforce in their libraries, accessibility features that can be baked into libraries without compromising developer experience and component flexibility, and other considerations beyond the components themselves.
Lob: Give me one quick tip I’ll come away with?
Beth: Something that we implemented in our UI component library was the ability to style a button like a link, and vice-versa. Sometimes, we found that we wanted an element that looked like a button to take the user to a different page, so we wanted the functionality of a link. Allowing a developer to use a link-styled-as-a-button means all of the baked-in accessibility and expected behavior of a link exists, but it still visually accomplishes what we want.
Lob: Well, we are excited about your talk…Are you?
Beth: Public speaking is not necessarily within my comfort zone, especially to an audience as big as AxeCon. But one, I know it's good for me; two, I think I do have important insights to share with people. And three, I am a woman, I am a person of color. And I think it's important for other women and other people of color to see someone like themselves represented on bigger stages and know that we exist. We're doing important things, we have things to share.
AxeCon 2022 is a virtual event featuring discussion around building accessible experiences. The event takes place March 15-17, 2022 and registration is free. Be sure to check out Beth Qiang’s talk: How a developer can break your UI component library's accessibility, and what to do about it.
.png)
.png)
.png)