At TXI, we’re making an effort to share more information about how we think about diversity, equity, inclusion, and belonging (DEIB) and how we’re taking action. To that end, we’ve been blogging about the four justice pillars that our DEIB group uses to structure our company’s efforts to create a better, more equitable workplace and ultimately, world.
We recently published an article on how DEIB approaches disability justice, and in that conversation, we touched on the idea of accessibility.
To dive deeper into this topic, we invited product designer, DEIB group member, and accessibility working group lead Alex Chen to share their thoughts on how TXI is working to make global user accessibility part of everything we do. Here’s what they had to say.
How did the idea of making global user accessibility part of everything you build at TXI come about?
In general, accessibility should be prioritized in technology because as humans, we all have access needs. At its heart, human innovation means creating tools to meet our varied needs.
The unfortunate thing is that the needs of people with disabilities are devalued in our society, and that's part of the reason why there are so many barriers to accessibility.
What I think a lot of people don't realize is the sheer number of people with disabilities that exist and interact with technology today. In fact, 25 percent of adults have a disability. That being said, if people have some type of vision correction, if people experience stress or cognitive overload, or perhaps are not necessarily diagnosed with a disability, they have access needs as well.
It’s incredibly important that technology is supportive of us rather than something we have to fight against all the time. That's why accessibility is a need in technology in general. And at TXI specifically, we really value the quality of our products.
We value providing a positive experience, not only to our users but our clients. It would be a disservice to exclude something like accessibility from what we create.
How are you operationalizing accessibility and building it into your processes and products?
We have identified some key areas we want to avoid, but are still exploring other ways to improve global user accessibility in our products.
For example, in a traditional waterfall approach, you do all the design upfront, make no changes after you do all the development, and then you ship the product.
Afterward, people might find some accessibility issues with the product, like screen reader users can't use it. It might not be accessible to a keyboard, or maybe there are flashing lights. These are just some examples of the many issues that could come about, which could lead to the risk of litigation. And if you're already at the point where you've designed and built everything, the cost of improving and fixing these issues is now very high.
So, we want to move away from the waterfall model into a more agile approach that identifies accessibility needs upfront during the design stage and addresses them during the development cycle.
Many designers at TXI work day-to-day in smaller cohorts, but we are making a concerted effort to come together as a group more frequently. Our goal is to increase group critiques and have multiple people giving feedback on different projects, including on accessibility and usability.
And then, during the development cycle, our goal is to provide documentation for proper markup of these components so that they can be read by screen readers. We want to be constantly testing as new components, new pages, and new features are made, so that we can identify any issues at the end of a two-week sprint, rather than at the end of a six-month launch cycle, for example.
One of the things that TXI talks about is having accessibility champions on its teams. How did that idea come about and what exactly is an accessibility champion at TXI?
We are in a unique position because we are a consultancy (as opposed to a product company that focuses on just one or a small portfolio of products). Because we consult with clients of varying needs, sizes, budgets, and industries, a lot of our project teams use slightly different approaches per client, and I think that type of diversity is to be celebrated.
We also really value working differently, and we don't want to be prescriptive when we set out to do a certain type of work. Because that sense of uniqueness is something we promote and not everyone is focused on the same project, it can be challenging to lead a formal accessibility program. To put it another way, while we follow best practices in every engagement, we also often define unique criteria for each one. It’s part of the nature of our consultancy.
Another part of it is that sometimes when a company tries to do an initiative to promote accessibility, there might be one or two people who champion this type of work. What ultimately happens is the burden gets put on that person and others don't really think of it as their responsibility.
So, we are really trying to promote the idea of collective responsibility in order to achieve these desired outcomes. One way of doing that is by embedding an accessibility champion on every project, and we kicked off this program in summer of 2021.
How do folks become accessibility champions?
Really whoever wants to, whoever is excited, and wants to volunteer. All of our accessibility champions are people who've volunteered.
We made an announcement during an all company quarterly meeting, and I invited everyone to go through an example activity with me to write an image description for whatever image they wanted. For reference, image descriptions are accessible to blind and visually impaired people who would not be able to access imagery content otherwise.
What this exercise aimed to demonstrate was that accessibility is a creative practice as well and it can really boost the individual's skills, along with the quality of the application. It makes our general offering stronger. Luckily, the exercise also helped identify people who were passionate and interested in this type of work, and they volunteered to become champions on their team.
Do these volunteers come from a range of disciplines within the company, or are they mostly designers and engineers?
It's about half and half designers and software engineers.
The designers are often interested in some more design-related aspects such as visual styles, usability, and navigation. Design systems come up a lot in this type of work because it's about creating consistent components across the entire product.
Accessibility has a lot of front end implications as well, so we have a bunch of engineers who are focused on a lot of different aspects of accessibility. Some are focused on charts and data visualization. Others are focused on continuous testing and figuring out processes in which we can continuously test and approve the code rather than waiting until after things are pushed to production and finding issues.
What does this involvement look like as folks get started as accessibility champions?
When someone expresses interest, my coworker Kara Carrell or I will have an introductory meeting with them. We have a welcome packet where we ask questions not only about their interests, but some more information about the client and the project that they're on and any areas of focus that they would like to pursue.
We try to have regular check-ins with them, maybe once a month, if not once a quarter to see how they're doing after that initial introductory meeting. For example, they may be interested in a tool or plugin that might help with a project they’re working on. We talk about that and evaluate it. Is this something that other people should be using? Can TXI help offset some of those costs? Really, these check-ins are there to serve a champion and make sure that they feel supported.
Is it common for champions to interact with each other across projects to share ideas and resources directly?
We have a Slack channel devoted to accessibility where people can share learnings from the articles that they find or classes they’re taking.
We had a brunch and learn a while ago where we invited five champions to share some of the work that they were doing. We used to have monthly group meetings and we ultimately moved away from that to the one-on-ones so now as a group, we focus more on asynchronous conversations, and I think that that currently works better with people's schedules.
Do you have plans to measure the impact or find a way to represent the impacts of this group's work on the company and for its clients?
We've been thinking a lot about that. We are definitely still in the midst of defining those metrics of success.
One thing that we're considering is creating an accessibility rating across all projects. The Web Content Accessibility Guidelines (WCAG) are typically used as the standard to measure accessibility. They have about 100 individual success criteria and it can become very overwhelming to have to evaluate every piece of standards, so my colleague Gilad came up with the idea of an accessibility rating system that would resemble restaurant ratings. This inspiration came from axe-con, which is a conference that Deque hosts every year.
So, instead of focusing on which WCAG standards and saying, “It doesn't meet 1.2.13, but it does meet 2.36,” (throwing out totally random numbers right now) instead, we can say that it’s a 3-star rating, so we know we have some room for improvement, but it's not terrible.
We don't expect perfection. In fact, we think that perfection is going to be the enemy of progress here. So, simplified ratings like that would be really helpful, especially if we can use them to quantify the improvement.
Of course, there are other things that we can measure, such as cost and user satisfaction. These are all things that we're thinking about that are not quite concrete yet.
What’s next in these efforts or what are the kind of the next benchmarks you're looking to reach?
In conversations with accessibility champions, the overwhelming majority said that they don't really know where to start, that it feels a little intimidating to enter this topic, and that they feel unsure of what to do.
I will say that another quality that we try to encourage actually is being able to sit with the discomfort of pursuing something new. We make it clear to champions that we don't expect them to be experts; a willingness to learn is more important.
Because a lot of people mentioned feeling unsure or tentative about best practices, one of our major goals this year, especially, is to provide training.
The goal is for at least half of people working in delivery to have completed accessibility training. We're still in conversation about the exact budget and timeline of that effort, but I think that if we can achieve at least 50 percent training, then we'll be in a really good spot.
What does accessibility in every product of TXI look like as you see it today?
For me, the ideal state would be that everyone is an accessibility champion; it's not just the burden of one person or the shared burden of a few. Everyone at TXI understands the subject matter and can advocate for its importance.
Another thing that I would love is for the problems that we focus on to be the types of problems where we're trying to go above and beyond. For example, a really common accessibility issue is low color contrast. I come across a lot of websites that use light gray text over a white background, and that becomes so difficult to read. But color contrast is actually a very straightforward issue; it’s not always easy to address because of the many color combinations that might occur throughout the app, but that's where more intentional design decisions can make a difference.
I don't want us to have to worry about simple issues like color contrast. Instead, I would love for us to think about how we can really be supportive of users and elevate experiences beyond the bare minimum.
For example, at a bare minimum, a user should be able to complete a process and understand where they are in the application. What if there are things that are confusing or overwhelming, especially to someone with an intellectual or cognitive disability that could be a real barrier?
What about complex interactions that are typically not available to screen reader or keyboard users, such as vector and drawing applications? What about content warnings for triggering media so that we can ensure a safe and supportive experience throughout? These are things I’d love for us to be thinking more about.
Is there anything else we haven't touched on that you wanted to share?
The cool thing about this program is that as we start to demystify accessibility as a practice, hopefully, it becomes less intimidating. I would love for it to become less of a specialty because we promise to deliver a level of security and quality in our products. We perform a lot of code reviews and a lot of other maintenance checks, and I think it's important that we consider accessibility another one of these.
It's important for accessibility to be included in the entire package, rather than as an optional add-on. That's really the ultimate goal of this initiative, and if we can do that through champions and individual people finding passion and excitement in this craft, I think that it will be successful on that front.
If you’re interested in learning more about how TXI can deliver the solution your users need, contact us to start the conversation.
