Accessibility is Simply Logical

Transcript

A senior developer and CX manager set out to examine accessibility and inclusion at Castos. Welcome to our podcast, Logic Accessibility.

Kim: Welcome everybody to Logic Accessibility. I’m really excited. This is our very first episode. We’re going to get started by first introducing ourselves. Alec, if you’d like to say hello first.

Alec: Yeah. Hi, my name is Alec. I’m the lead developer here at Castos. Great to be here. 

Kim: My name is Kim McCaffery. I’m the customer experience manager here at Castos. A little bit about what we’re doing here with Logic Accessibility. What is our purpose? As the title implies, we’re looking at accessibility within Castos across all Castos products. More specifically, and one of the main reasons is, Alec and I are doing this together. It’s really important to us. I know you probably agree that we wanted to really put a spotlight on the developer’s role in improving and building accessibility to the process, would you agree? 

Alec: Yeah. I think a lot of the companies that I’ve been at before, Castos, didn’t really focus on accessibility. The only one that I can think of off the top of my head was a marketing agency that only really focused on it, because they had been sued for it before, which doesn’t really count in my opinion. It’s one of those things that a lot of software companies don’t really think about how much of their audience they are just ignoring and not building tools that they can actually use or enjoy using. It’s just something that we want to focus on here more as we grow as a company. 

Kim: Accessibility can mean so many different things but from a developer standpoint, it always has felt like there’s a barrier there because it seems overwhelming. Of course, as you know, and probably anybody else that is working on a SaaS team or software, everybody’s always running on a limited bandwidth. You try to push it forward, you try to keep it off the back burner. Sometimes it’s difficult, but one of the things that’s brought us to this point is that, we hit a moment where we recognize, hey, this isn’t a nice to have, this is a need to have. 

This is something that needs to be part of our process, not something that we go back and improve but something that as we’re building, that accessibility is part of the process, part of the sprint, part of the cycle. Would you agree with that? 

Alec: Yeah, I think it’s just as important to focus on accessibility as we do quality or delivery time. It’s something that we need to build into our process and make sure that we have time to do it when we’re actually working on things. A lot of software development companies view testing in a similar way where it’s nice to have, where if you have four weeks to get things done, and you have a week left at the end, write your tests, or you have four weeks, get done with the three weeks, make it accessible. 

That doesn’t really work in either case. I speak from experience when saying that if you don’t prioritize good testing and good accessibility, it just doesn’t happen. Those nice to haves rarely ever actually put into the product, because like you said, we’re always under some kind of not necessarily time crunch, but we always have stuff to work on, and we always have deadlines that we’re trying to meet. If you mark something as a nice to have, that is the first thing that’s usually going to get cut when we’re looking for places that we can cut time without cutting quality, which in a roundabout way ends up not working, because cutting accessibility and cutting testing is cutting quality. 

We don’t necessarily think of it as that because it hasn’t been taught to us to think of it that way the same way that keeping our source code clean and keeping everything organized has been taught to us as having a high quality product. At the end of the day, the source code and stuff that’s nice for us, that doesn’t help the end user. The accessibility aspect of that, especially, should be much higher priority than a lot of the stuff that we have been taught to prioritize traditionally, either in school or through experience. 

Kim: I know we’re talking about what we’re cutting out and the end user, when we look at disabilities, 20% of the population is disabled. Whether it’s a temporary disability, chronic disability, that is a huge percentage. Those are our end users. Not paying attention to that from a business standpoint, it’s just bad business, first of all, but it just makes sense.

That’s why we went with Logical Accessibility, it’s logical. It’s where the title came from. You make a really good point. I joined the team most recently. You were here a little bit longer than I was. Shortly after I joined the team, we had a user open up a support ticket and said I can’t read the information on the pricing page because it’s not accessible to my screen reader. 

We all were talking about it and in a meeting, and it was like, well, wow, that’s really interesting. That’s never been brought up before, we don’t have users that have ever really said anything about it before. I quickly stepped forward. I was thinking back, maybe a little bit bold on my part, and I was like, well, yeah, you haven’t heard from them because they’re not our customers. They don’t make it that far. If somebody uses a screen reader to get the pricing page, and they can’t read the pricing page, it’s safe to assume that the product is also going to be equally as inaccessible. 

We started talking about it. We started talking about legal ramifications and just the responsibility that if you’re going to have a product that’s available to the public, globally, this is something that needs to take place. We are fortunate enough that we have a founder, just like you and I was just logical. It just makes sense. We immediately had that stakeholder buy-in. 

Like in the past, it was always a matter of presenting all of the evidence as to why it’s important or building the business case and presenting it and that sort of thing. It’s always been a challenge, at least to my experience in the past. That was not the case here. He immediately had said, well, yes, that needs to be done, and then formally, nailed it down and said, I want you to spearhead this. I want you and Alec to get on this. That’s what we’ve been doing ever since.

It is now circling back. We have to look at existing products that we have. For anybody that’s not familiar, Castos is a podcast, hosting, and analytics platform. We’re looking at a web app, we’re looking at a WordPress plugin, we’re looking at the marketing website, just really across the board at all these different products. 

I think when you and I first sat down and said, okay, what are we looking at here? We ended up being a pretty extensive checklist. I’m like, what was ahead of us? We decided to start just taking steps towards that. What you’re doing at the same time is not just looking at what we have to fix, but simultaneously, you’re already taking steps towards building this into the process. 

Alec: Yeah. When we were sent out to do this, we set two rules for ourselves. The first one was, we were not because we can’t, we’re too small of a company. We couldn’t drop everything and go back and fix it, like have that be our main focus. We are also in a place as a company where we’re growing pretty fast, we’re adding new users, we’re adding new features, we’re making changes to things quite a bit. It’s one of those things where we don’t have to drop everything, because we’re already touching every part of the application anyways. 

The rule was, any new features, any new user interface, anything fresh off the presses, never been touched before, must be accessible by default, and must pass a certain checklist of items that we need to review to make sure that is accessible. Then for the existing parts of the application, as we are coming into those pieces and actually working on those areas, that is the time that we also go back and add the accessibility. There are also some areas that I know we don’t give a lot of attention to that need to be updated on that. As part of our normal process, we have two weeks where developers can work on pretty much anything in time, about every eight weeks. 

Using that time to also work on those areas that I know we probably aren’t going to get to through that normal process of just like, I’m working on this area anyway, so I’m going to fix it. It’s a three-tiered thing, where everything new must be accessible by default. If you’re working on something existing, improve the accessibility. If there’s a piece of the app that we know we aren’t going to touch, that’s where we have to actually schedule the time to go and fix it. 

Kim: One of the reasons that we wanted to do it, almost like documented this journey via podcast. When we started out looking at this, I did extensive research looking for what I usually do, who has gone before us? What was their process? How did they go about it? I didn’t find a whole lot for how to start to tackle this, how to nail this down. I decided, well, you know, maybe we should just have something available for folks to be able to follow that along. 

We’re doing this initial episode. Our plan is to continue to record additional episodes and then publish it as one large series at the end. So far, our initial steps, we determine the scope of the project. We then created a repository of tools, and that’s something that we’ll also be sharing along the way in show notes and blog posts, then the pre planning started. That’s when we started nailing down that checklist. 

We’ve already made such great changes, not just in the tangible changes in the product, but in our team wide meetings. I’m already hearing our team also started to speak to accessibility. I’m already hearing that that’s pushed out more of that in the forefront, as opposed to that afterthought, beyond just you and I but with our other team members as well. I’ve really found that to be really interesting. 

Alec: It’s interesting because I feel like it’s similar to how developers approach testing where it’s like, if you give them the time, it’s something that they want to do. Everyone wants to be proud of their work, everyone wants to feel like their work is usable and pleasant to use for as many people as possible, and that goes for developers too. Usually, when that doesn’t happen, it again comes back to that lack of time. 

By prioritizing and saying we are baking time into the schedule for you to work on these things, you’re basically just giving developers carte blanche to work on things that they actually want to work on. I take a lot of pride in the way that we build not just accessibility into what we do, but an overall user experience and trying to make our application something that is easy to use, that is intuitive to use, and that is pleasant to use for all of our users. 

To me, having those accessibility features in there is just part of that overall quality of making sure that this is fun to use. Accessibility isn’t just something that we talk about for people living with disabilities, it truly does make your product better for everyone, regardless of whether or not they’re living with a disability. I am not legally disabled, but I have 80% hearing loss in my right ear and 20% hearing loss in my left ear. 

Simple things like podcasters using stereo channels for like, you have two people on the show, the left person is in your left headphone, the right person is in your right headphone. If I don’t have the ability to tweak an equalizer, I can’t hear almost half of the conversation that’s happening in that episode. It’s little things like that. You don’t have to be legally deaf or legally blind or have a legal disability for these things to help you. Everyone has a little bit of hearing loss. Everyone has a little bit of eyesight loss as you get older. It’s just something that benefits all of us. 

Kim: Accessibility and those types of improvements and features and billing that in, it really does. It adds quality to the user experience for all. It’s really fascinating. There’s so much great information and data that is out there about that. Things that we did change right out of the gate, thankfully, we’ve got a great front-end designer, who was able to move really quickly and we were able to create an accessible pricing page. 

Also, from outside of the developer scope, from within my role, customer experience manager, how we approach support, that needed to change. In the middle of all of this, we were migrating from Help Scout as our help desk to Zendesk, which of course, for anyone who’s ever migrated, a help desk was a huge undertaking. It was also a great opportunity to go back and go through the hundreds of different articles and revise them, which I did one by one to make sure that those were accessible, because we had directional elements in a help doc, things like click on this at the top right hand corner or left hand corner, or referring to the color of a button, that sort of thing, in a written help doc is not accessible, but also how we approach support in a ticket. Making sure that our team isn’t using similar language in tickets. 

Accessibility shows up in every customer touchpoint. Every customer touchpoint, accessibility is a consideration. Already a great learning experience and I’ve grown a lot, and my understanding has grown a lot since we started this project. 

Alec: Here’s another example of, improving accessibility helps everyone. In my role, I don’t work with the WordPress plugin as much as some of our other developers. I’m usually either working on the web application side, or doing management and setting up tools for other developers. I don’t know how to use the WordPress plugin all that well. The help docs weren’t necessarily all that useful to me before because they were written for someone who is coming in with no knowledge. There was some kind of disconnect where I had enough knowledge that it made them harder to read, if that makes sense. I don’t know if it does. 

Whereas after going after you went through and changed all of our help docs, I use our own Zendesk support documents to help me work on the plugin, because I don’t have that knowledge, and the documentation that we have now is genuinely good enough that it helps me in my work as a developer. That is something that our old help docs, I didn’t realize they were wrong. As soon as you started pointing out some of the things to me like, not using directional indicators or not using color, those things immediately made sense. But it’s not just down to things like that, it’s also just the way things are worded and how the document flows. 

Whether you can easily reference things, using the noun instead of the pronoun so it’s clear what you’re talking about, all those little things are things that I just didn’t think about when I couldn’t use the help docs before. As soon as those things were changed, it felt like we had all new support documents. Again, that’s just another example of like, we did that to improve the accessibility of our support articles, and I hope that it worked out well for people who need those. It also worked out really well for us, like internally. You wouldn’t really think about that when it’s our support articles that are being revised. 

I should know the things in our support articles. If it’s not something that I touch on a day to day basis, I don’t have that knowledge, and having those support articles rewritten to be more digestible to all audiences really helped me be able to install all the plugins locally, get everything spun up and actually start debugging some issues. It was really helpful in that regard as well. 

Kim: That’s just made my day. You do make a really good point. A lot of times, especially, in software when we’re talking about accessibility, it just seems like folks are default to blind, low vision, deaf, or hard of hearing. We’re looking at transcripts, and we’re looking at color contrast and that sort of thing. Accessibility is auditory, cognitive, neurological, physical, speech, visual, and mobility. We’re talking about a whole spectrum of different types of things that we need to be considering. 

What we’re doing right now and what’s next, the big thing that we’re tackling right now, we have a listener analytics page. That’s a core functionality of Castos. People really like to be able to not just come in and publish their podcasts, Castos is doing all the hosting. People come into Castos, they’re uploading episodes, they’re writing show notes, all of that fun stuff. They like to then be able to go to these analytics, so how often episodes are being listened to, what are their top episodes geographically, where are the listeners, that sort of thing. 

That page and those tools were not accessible to screen readers, but that area of the app presents a unique challenge, because that data is presented in the form of charts and tables. When you and I started looking at how to make a table accessible, that great video that we came across of here’s a table that a screen reader can read, but it’s not accessible and here’s why. As opposed to reading the information in a way that made sense, maybe across the lines instead of columns, it was reading straight down column A, straight down column B, straight down column C. None of that information made any sense. 

You and I were like, oh, wow, this is going to be a unique challenge to how they take this information and make it accessible to screen readers. Its core functionality is super important but wow. It’s a lot more complex than I had anticipated. 

Alec: I think that section presents a unique challenge too. The main usage of that is to get quick information about things like, are my numbers going up, are they going down, are they staying steady, where are my listenerships from? Those are the things that are pretty easy to represent visually in a graph. But I haven’t really found the best way to represent that data in a format that can be used by people who can’t read graphs.

It’s a unique situation where, I want to, not just make those tables accessible and be able to read the literal data out, but how do we also make it so that they still get that additional information the graphs are conveying of, what is happening to my listenership, where are they primarily located, what sources are they using the listen to, and being able to get a good idea of how those things relate to each other. Because I think that that’s one thing that I’m not sure that just making the table read the correct way conveys, is getting the context around each line and not having to remember that you’re five rows before this had these numbers, and this one is higher, so that means my numbers are going up.

Just having it be in a way that you can intuit those changes in your analytics in the same way that you can with a chart, but in a format that is readable by a screen reader. That’s the key challenge that we’re dealing with that page and one that is both interesting and difficult to tackle. But one that, if we get it right, we can use that all in so many other places in the app. It’s a goal worth pursuing and one that we are going to pursue. I hope that we can find something that really gives that same information, but conveys it in a way that everyone can access it. 

Kim: I haven’t been able to really find a whole lot. Is there anything out there that you’ve found?

Alec: I’ve got some suggestions, nothing really concrete. I think the one that makes the most sense, at least initially, is to have a summary of what the chart actually says. Because we can intuit that information from the numbers themselves, it’s not necessarily putting them on the graph that makes them suitable seeing the relationships between them. We can process those relationships on the back end. We can have a paragraph of text that says, between these dates, your numbers were generally around this area and we’re steadily rising. 

After this date, things started to dip a little bit, something like that, where we’re giving an explanation of what’s in the charts without having to have a person do that every time, because we have thousands of customers. It’s not feasible for us to have those be custom written on every single one. How do we come up with a system where we can, from just the numbers themselves, get that intuitive information that we were trying to convey with the charts and just put it in a summary?

I don’t know if that’s the best solution, but so far, that’s the one that I’m leaning towards, because the implementation of it should be fairly straightforward, and I can know for sure that they can at least get that information. Whether it’s the ideal format, I’m less certain of that, but that’s what we’re leaning towards right now. 

Kim: That speaks to the spirit in which we are approaching this. We’re not kidding ourselves that, oh, this is going to be a one and done thing. Neither you or I are blind, or neither you or I have a number of different disabilities. We’re not going to get it right the first time. What we are doing is we’re listening to our customer base, we’re listening to our users, we’re diligently researching, and we are open to the scrutiny, and being called out, and making changes as needed. 

This is never going to be something that we just say, oh, we got that right. Maybe we take a swing at the analytics tables and charts, and it just comes back like it makes totally no sense, whatsoever. I, just being out the customer-facing person that I am, I anticipate that we’ll be told pretty quickly. As the case, then we can get it right. We will go back, of course, and we will keep working on it. That’s part of the work and how it should be. So we’re going to be prepared to iterate. 

The other thing that we have talked about really recently is audio transcripts. For anybody that’s podcasted, been in podcasting, transcripts are a pretty big deal. A lot of times, you see them like, oh, you should have a transcript to go with your podcast for SEO purposes. The accessibility really is even at the forefront of some folks minds. It is a pain point for podcasters to be able to have audio transcripts generated, and how to add them whether they should be in show notes or as a downloadable file. 

It is a pain point. You can go on any Facebook for podcasters or any social media group, and inevitably, there will be a conversation about, how do you go about transcripts? It’s always like, ugh. It’s just a universal pain point for podcasters on how to provide accurate, readable, scannable, whatever the case may be, transcripts. One of the things that we just started kicking around exploring the options to be able, whether that’s like a built-in audio transcript solution, because we already have that now, but it’s more like an integration that we have from another service. 

To be able to make that more available to more podcasters, build it in. It’s just really removing that pain point, removing that friction, so that it’s just logical. Of course, I’m going to add transcripts to my podcast episode. Why wouldn’t I? It’s right there. I don’t know where that’s going to take us. We started kicking that around. Our team was that back […]. We’re on Slack a little bit, but I was excited to, even just by the idea of how can we just remove this pain point? Because it is such a huge pain point for podcasters. I thought that was pretty cool. 

Alec: There’s a lot of solutions that we can look at for something like that. I don’t know that we necessarily have the machine learning chops to create our own automatic transcription service per se, but there’s other options out there. You can have them checked against each other or something to just improve the overall quality. Then the other question that we had was the deliverability of it. 

Our WordPress plugin, Seriously Simple Podcasting, has a way that you can upload those transcripts. In the podcast player itself, there’s a place that you can then go download them. They’re available on the web pages, but no one that I’m aware of, as far as the podcast listening apps, has any way for you to really view a transcript in the app. For that matter, as far as I know, there’s no standard for adding a transcript to an RSS feed, so they wouldn’t even know where to look for it. 

One of the things that we’re towing about with is, maybe there’s some way that we can include a transcript in an RSS feed in a way that it doesn’t make the RSS feed just massive and multiple gigabytes to download, because transcripts are a lot of text. It is just text, but it’s a text for every single episode in your feed. Not bloating the feed, but also in a way that maybe we can encourage some podcast players to implement support to have each sentence fragment have a timestamp, and you can turn on, like closed captioning.

We confirm that idea a little bit and maybe trying to come up with an implementation for that that others can use just something to make transcripts more accessible, because even the podcasters who do the work or pay for a professional transcribing now, the discoverability of those things–you mentioned that most people talk about it for SEO. I’m not sure if that’s entirely because of just the SEO or because people know that they’re hard to find right now.

If you don’t go directly to an episode on a podcast website, you’re probably not going to be able to find the transcript. That’s not how most people listen to podcasts, they listen through Apple podcasts, Overcast podcasts, Google podcasts, Spotify, whatever. Putting those in a place where not only are they available, but they’re discoverable. 

That’s the two-sided coin to everything. Just putting something out into the world is not enough. You have to make it accessible, you have to make it discoverable, and you have to make it so people know that it exists. Otherwise, it might as well not be there. That’s what we were talking through and just trying to get a feel for us. How can we not just make the act of having a transcript for your podcast easier, but also make it easier for your listeners to find? 

Kim: That’s a really good point. The discoverability of it, absolutely. It was really exciting, though, to see that conversation taking place. Everybody gets a little bit excited about it, oh, we can do it this way or we can do it that way. We’re starting to see accessibility already woven into the fabric of how we approach things, and even generating new ideas, that conversation is just being driven from the top down. Now it’s really exciting to say this is where we’re at, we’re going to continue to record content, we’re going to continue this conversation and document this journey. 

We plan to continue sharing maybe what didn’t work. Maybe in a future episode, you’ll find out like, well, that didn’t go very well, the analytics page or find out that we stumbled across a solution that we are going to be able to duplicate in other areas. Either way, we’re excited to share this documentation, even if it’s embarrassing at some point. We’re excited to share those wins really more than anything. 

Please keep an eye out for future episodes. Join us. If you have any ideas, if you’re working on accessibility, if you’re looking at accessibility and inclusion in your products, if you have ideas, things that have worked for you or haven’t worked for you, any advice, please feel free to reach out to us at [email protected]. We welcome your feedback, your thoughts, your ideas. Thank you so much and please join us next time. 

Alec: Thank you.

Thanks for listening to this episode of Logic Accessibility hosted by Alec Joy and Kim McCaffery, and supported by Castos podcasting and the dedicated members of the Castos team. At Castos, our goal is simple. Make podcasting easy and accessible to all. Be sure to head over to castos.com for show notes and resources, as well as other podcasts created by members of the Castos team. Thanks again for listening