Hello everyone and welcome back to another episode of Programmatic. My name is Michael Doeies and it's been a little while since we've recorded one of these, but we are back with another episode and I feel like this is going to be a very controversial episode and people have a lot of different opinions on this, but I think it's important to talk about. And because it's such a big topic to discuss, I felt like I should bring an expert on the topic of accessibility and I'm here with Taylor Arnt today, so hi Taylor.

Hi Michael.

Yeah, thanks for being here.

Yeah, no problem.

Taylor, why don't you let our listeners know what your background is and talk about what your career has been in programming and specifically what you've focused on over the past couple of years and then that'll lead into what our topic is today.

Yeah.

So like Michael said, I'm Taylor Arnt, and I currently live in Austin, Texas. I've been in the digital accessibility space for over six years. I started at a university in Michigan called Western Michigan University. I was there for about three to four years doing accessibility as a student worker. And then in 2020, I lost my job. After that I became self employed and I did accessibility for corporations and governments and a whole bunch of other small businesses. And then in 2021, I got a job at an accessibility audit firm. It was in Minnesota, but I work remote and so I did that for about a year. And then right now, as of May 1, I am a freelance self employed accessibility consultant. So I focus on web, but I also focus on mobile. And I have been doing programming since I was about 14 years old when my great friend Brandon Tyson introduced me to programming. So that's kind of my backstory.

Fantastic. Well, what you just talked about is kind of why? Well, you're going to be on a lot more, right? Yeah. And the programmatic podcast folks will be coming back more often. So we were looking for some good content because I felt like we were talking too much about the basics and we'll continue to do some of that, the Eleven lab stuff. We're going to try to come up with a new solution for having the code read out loud so we'll have more programming challenges and things like that in the future. This episode is a little bit different today compared to other episodes that we've done, but I felt like it's important because too often a lot of people go out and they build apps and they get counted off when people audit their apps for accessibility. And the reason is because when people audit apps, they treat it as a website. And we all know that websites and mobile apps are very different things. Different information is presented in a mobile app differently from a web page.

Exactly.

There are items that are in a mobile app that are done a certain way to fit better on a small screen or on a tablet. And Taylor, let me ask you this, because actually I've never even thought about this. How are desktop applications audited? Are they audited the same as a website? Or how is that handled compared to a mobile app?

That's a great question, Michael. So the answer to that question is it depends. Of course, that's a very vague answer. And what I mean by it depends is, of course, if you're working for one of the big accessibility companies, they're going to have their own set of standards. But generally, yes, a desktop app is audited the same way as a mobile sorry, a website, meaning that every desktop app must follow WCAG Web Content Accessibility Guidelines, or if you're working in government context, Section 508. And so really, the standards are the same for practically everything. And so, yes, it's really the same in terms of auditing desktop apps. Now, of course, like I said, if you're working for a big company or you're dealing with a big company for auditing, then they may have their own procedures. But in general, best practice in the industry currently is you use WCAG for.

Practically curious, you know, because WCAG, if people are not familiar, stand for Web Content Accessibility Guidelines.

Yes.

And the key word is, at the beginning, web websites. Now there are certain apps. The funny thing is that this actually does apply to certain desktop apps.

It does.

And which ones would you imagine those apply to?

So these apply to, for example, if you've got like, Electron. So think about Visual Studio code, think about Slack, think about Microsoft teams, all those where they have a web baseline.

Yep, that's exactly where I was going with that. So it does apply in those areas, right. So that's one thing to keep in mind. Now, if you're building a Windows application and you have a menu bar and a toolbar, a lot of those things do apply. But there are certain areas where certain frameworks, certain operating systems may prevent you from having accessibility. And I don't know that people think about that. Right, so certain operating systems and certain devices may not even let you have a dark mode. Think about that. Right, yeah. So then you would have to be tasked with building one into your app.

And that's really a burden for developers, because think about this, if you're a developer and you're very new to it, like for me, I'm building this. Markdown Editor right. Let's imagine for just 1 second that Windows does not have dark mode. Well, how hard would it be for me to build a dark mode into my app? And how many developers would actually do it?

Right? And okay, here's just a prime example. In the accessibility space, we've all heard of this little device called the Blind Show classic Two.

Oh, yeah.

For folks that may not be in the developer or in the accessibility space or use screen readers and things like that. This is an Android phone that has its own app system, an app catalog. It does not work with Google Play. You cannot set dark mode for Android apps. So Zoom and all these other apps that are in light mode, that's what you're going to be stuck with. There is no possible way of adding that accessibility in to allow for a dark mode with Android. So that's just one example. It's not necessarily a stop ship, but it is one example where if somebody were to audit on a blind shell classic, two, they could make an exception for any app that is an Android app. Am I wrong?

You are not wrong, Michael. Again, a lot of these companies, if you're working with a big company, have a very rigorous process for making exceptions, right? Because they will only make exceptions if there is really no way to do it. And maybe even then, they will not make an exception. But generally, if the expert that you're working with is adept in the development community and also the accessibility community, they will realize that Android, you cannot do this dark mode.

Well, and that's kind of the big thing, is that they may think, well, Android, because Android does allow for dark mode. Right?

Right.

But this version sorry, this version of Android does not. So I guess they would have to write an exception based on this device. Is that how that would know?

Again, like I said, it all depends on the company. So I'll just take my company, for example, because I do accessibility audits. So in this case, what I would do is, yes, I would write an exception. I'd say, because this is a blind shell classic, this blind shell classic does not have the ability to do dark mode. As a result, an exception is going to have to be granted. And I'll have some language.

I'll go along with that.

Now, will most companies do?

That depends. I would say majority will not, because they don't know. First off, they don't know what a blind shelf classic is. And second off, they don't really know about development because a lot of these accessibility professionals don't have a development background.

Or their development background is web. Is that correct?

That is a really good part of that. Because the thing is that when I worked at my previous employer, a lot of my colleagues literally were at a web development boot camp, and they got hired right on the spot at that company, and a lot of them had web development experience. I was actually one of the only employees who had mobile.

Interesting. Okay.

Yeah.

So we're talking about desktop apps and mobile apps. But one of the things that we really wanted to focus on is the technicalities of these things. So if I have a mobile app and I'm using something like SwiftUI or if I'm using Storyboards or I'm using Kotlin with Jetpack Compose or Flutter or things like that. There are all kinds of ways that you could present content on the screen with images and things like that. And the general practice for web, as my understanding goes, is that anytime there's an image, you want to be able to tab to that image unless it's decorative. Now, right? My definition that I understand of decorative is a background image, something behind text that just adds background. Is there any other definition on the web for a decorative image?

So again, like I've been saying, it depends on the company. So because I am familiar with my company, because I make the standards, my definition is basically there are a couple of things, right? So first off, it's anything that's not visually anything that's there for visual appeal, like decorations on the page or a background image, right? Or even something that is like a icon that's just redundant, right? You want to make sure that you use Aria and get rid of that, right? Hide it if it's going to cause I guess, you know, the thing is that anything that's going to clutter up the screen reader is needing to be hidden. But if it's really important, like for example, if it's know image of, I don't know, let's say it's a group image of Michael and you know, we'll say if we got all the tickopolis developers together, of course that would not be decorative because that's part of the page. And so really anything know for visual appeal is my understanding and what I say needs to be hidden because for the screen reader user it's going to be very confusing.

So I guess another question with that is if you have a home, a picture of a house with the word home next to it, would the image be decorative on the web?

What is its context?

Like a link to go to the home page?

Yeah, it depends like I said, because if it's already going to be displayed somewhere else, why do you want to show the image and then have a redundant thing below it saying home? I'm just kind of trying to picture.

This in my brain.

So you don't want to have it redundant because that'll just be confusing. So if it's a picture of a home, that's great. But it all depends if that home is supposed to represent like a home for sale or if it's just a home page, then you already get that context. So in my opinion, if it's just your visual appeal, we can hide that.

That makes sense. So I guess in this kind of case, if the image is to, I guess maybe, okay, should the user even know, like, okay, say it's in the menu, and you have home, and then you have say it's. Say you're doing a mobile let me rephrase. Say you're doing a menu that has a picture, like an icon before each of the menu items. And the icon is just a picture representation of what the menu item is. And the menu item is completely accessible. But they are doing using Aria to hide the image from the screen reader. Would that be acceptable on a web page?

Again, it all depends on the person, in my opinion. Yes. Because why do we want to clutter up the screen reader? Some people will say show it, but again, that could create more problems because it's going to be more stuff for the keyboard in terms of keyboard users. So for people who have to rely on just the keyboard, absolutely not. We need to get rid of it because that will make more tab stopped, which will then make it harder for them to use the keyboard to get where they want.

Yeah, that makes sense to me. And I think that's kind of the same in a mobile app because there are times where we have lists and things like that, where we have an image and the text. But at the same time I'm wondering, is there a difference? Do you feel like there are places in a mobile app where the images should be hidden, where from a screen reader where on a website they should be described more?

It's kind of a hard question. I think I understand what you're saying and the answer is, well, it all depends on what's going on. I mean, really, you want to follow the most widely accepted practices. Like I was just saying, for mostly web and mobile, of course there may be exceptions and what I'd say is all apps are not created equally and sometimes there must be exceptions to be granted because you can't really have a one size fits all solution. And so I say really not. But again, it all depends on what's going on.

Yeah, I think it kind of depends on does it's left up to interpretation of really the auditor and the developer to remediate that because I feel like if the image has any use of displaying information and that information is not being conveyed by an accessibility label or text. Right, yeah.

So really the rule is if it's an image, that is important to the sequence of the app. Like for example, I'll just think of like a real estate app because we're talking about home. So home just came up to me. Let's say we're talking about, for example, something like Zillow. If you just have a icon of a home, right, but then you don't show it or maybe it's a picture of a home, then how's that going to be helpful? Because the picture of a home is going to be hidden from screen readers. Wouldn't a screen reader user want to know what the home looks like that they're going to potentially buy? So in that case you want to have alt text or you want to have an accessibility label in mobile.

Now, here's the other question. If you have an image with visible text, well, say you have an image with visible text on top of the image, and that's done a lot in different websites and apps. Do you want the text to be read separately from the image, like two different tab stops or two different flicks or in the same flick so you get the image description and the text beak? Because I think personally, I would want both at the same time because they're both related.

Yeah. So really the key thing with that is you want to make sure it's easy for people to follow the relationships. And actually, I was talking about this today with my school, right? Because I'm going to accounting school, and they were talking about tables, how they were inaccessible and know, that's kind of a problem in accounting because you got all these tables. And of course, Michael, I'm getting off topic, but you're going to see why I'm telling about this in a second. So, of course we're talking about, okay, how are things related? Because imagine if I had a whole bunch of numbers. Like, let's say I had Apple stocks. I'm just making up stuff, and I had, I don't know, earnings by quarter, earnings by year, overall stuff. But let's say it was just a whole bunch of numbers and I didn't know what was what. You know, how confusing that would be for me. Instead of it saying that it would say something know, year to date, it would have a table header and it would say all that stuff. That'd be a lot easier. And so, like Michael was saying, we want everything in one flick or tab stop. So that way it conveys the relationship easier.

Yeah. So I think when it comes to images, and specifically starting with that this time, you really do want to stick with the same similar things with websites. Now, I think it comes a little differently when you're talking about a table view and a list, when you're going through list items with voiceover. Let's take social media, actually for this. This is a great example of this. Okay. So typically when you're looking at a timeline on social media, you have a profile picture, which drives me crazy because most of our community of the blind and visually impaired, low vision, unmastodon, never puts profile pictures.

I think I'm guilty of this.

Yes, you are. One of your accounts does, one of them doesn't. And as a low vision user, I could just quickly usually look at a picture and be like, oh, that's so and so. I don't have to read the name with a screen reader. And it's very interesting when you think about that. That's a whole conversation we could have on, like, the IA cast or some other podcast. But can with low vision, I can quickly look at the picture faster than I can read the text of the person's name and that's kind of interesting, but I can quickly look at the picture, then read the name and then we get the text and the other buttons. But I think that by technicality you would want to get so and so's profile picture as something that is readable but at the same time is that decorative? Because you're not going to be able to get the description of that image. So knowing the person's name with a screen reader is really enough to know, hey, maybe image of person name would be the more accessible or not image of because you're not supposed to use that as all text but yeah, you're not. No. So maybe just the person's name being a description of the profile image would be enough because if you were going through and you had to hear an alt text of every profile image on a timeline, that would take forever to go through. Right. So again, that's one of those times where a decorative is fine in that case. So in a list view, even though that could be important information, it's one of those times where I think that discretion is needed so that the user can get the information they need and not see every get text of each profile picture. Yeah, and then when we compare like Twitter or X and threads with Twitter, we get one swipable object for each post, whereas like threads, we have to go name time.

That's annoying.

Content each button and then you go to profile picture, name time content. Yeah, I think there's more flicks than that. So it's one of those things threads in that fashion is technically accessible and that is more accessible but it's not very usable. Right?

Yes.

So that's kind of a little bit of a difference because on a website you could jump to information. If somebody uses headings, it's a lot easier. You can use headings on voiceover as well, but it's just the efficiency of getting through the information, what's accessible, what's usable, in my opinion is what matters there. So that's kind of my thought. On images, it's just on a mobile app, especially compared to a website, everybody is expected on a desktop website, everybody's expected to know, okay, it's going to take me a while to go through all of my Gmail, right? So that kind of stuff, it's just expected on a desktop to take a while. But on a mobile device, you don't have the space, you don't have no, you do not the time. It's a quick get in, get out. So I think apps on a mobile device are slightly different as far as images and how that's handled. Do you have any thoughts on that? Like what I've explained or anything that you want to add on that?

Yeah, I was waiting for you to.

Be finished, so I really agree.

Michael says again, it's all about the context, folks. It's not a one size cookie cutter solution. You can't just say, oh, for everything. Do this right. Accessibility is all about analyzing the situation. And I think that's what a lot of things and people don't realize is accessibility is all about analyzing the situation, what is better in this situation and what will work for the user. And there is a difference between usable and accessible. And that's something that's very important to understand.

Yeah.

So let's go ahead and move on to another area. And that's headings.

Oh, goodness.

Yeah. We've got some headings to talk about here between websites and mobile apps. So this is kind of a big one that we discovered when you were auditing Vo Starter.

Yes.

And it was michael, why are you starting with a heading level two on your web content in the web pages? Right. And my reasoning for doing that is technically the top of the navigation bar in an app I believe should be considered a heading level one.

I just didn't see it.

Mobile apps do not have heading levels.

Does Android might go? Because I was told that android did.

I believe it might, but iOS does not. I haven't looked on Android in quite some time, but I do believe Android does. And in that case, you do want to use the heading levels properly. Right. But on iOS, it does not. So if I'm using web content, I always consider the top heading to be your heading level one, and every heading below that to be a heading level two, three, or know, depending on what framework you're using. Web or swift. What are your thoughts on this?

Again, like I said, it's all about using your judgment, right? Because you want to talk with a developer. And I think that's what a lot of accessibility companies are missing, where you can literally collaborate with the developers to make their apps accessible. So just because one developer is like, oh, I did this because of X, great to know. And then what I do with that is I take that into consideration. I'm like, okay, he did that. This is his reasoning. And then I think about, is this reasoning applicable to the standards? Will it meet the standards? And I'm like, okay, yes, that will work. And sometimes I'm like, no, unfortunately what you said, it's great, but we need to adjust X, Y, or Z. And so that's what I think is the thing, is that I wouldn't have known Michael's reasoning had I not asked him the question, like, hey, why'd you do this? And that's why I so think that collaborating with developers when you're doing an.

Audit is agree, you know? And I think it's interesting. We have an interesting dynamic because I'm more on the developer and design side of things, and Taylor's more on the accessibility side. She's starting to develop more apps and do things like that. So it's a great conversation to be had. Headings is one area where it's always very tricky and making sure that people get the right concepts and do the right things.

And what I also generally say about headings is just because iOS does not have the proper headings, you still want to use them correctly. So what I mean by that is you want to have the main navigation bar heading, right? And then if there's a significant subsection in your app, I don't know.

Let'S.

Say the I accessibility app was structured a little bit differently. Let's say it was like all one tab, oh gosh, Michael, don't do this. But let's say, for example, the first tab we had Recent Podcast, and then the second tab we had sorry, second heading we had Contact US, and third heading we had I don't know about the team, I'm just making up stuff at this point. You want to use headings for significant sections of the app and no, you don't want to use headings to bold your text.

So people who are listening don't use.

Headings to bold text either on mobile or web. Just don't do it because it will be very bad and inaccessible. Use headings as headings, not as bold indicators, just a little PSA.

Yeah, I think that's very important is knowing when and when not to use headings. I guess it's easy to do, it's easy to think, oh, I can just use a heading to make this bold. No, there's proper ways to do that. And in fact, iOS has different styles of text you can use.

Good to know.

So there is a heading style, there is a body style and there is a headline style. There's so many and the reason why they do that, they're called dynamic types. And so as you change the text size on your device, those will scale properly with your content. That's actually an accessibility feature, believe it or not.

That's awesome.

So let's talk about kind of the last thing I had in mind to talk about and that's audio. And the differences between audio on the web and audio in devices. We know that if something is over 3 seconds, do not autoplay, it just shouldn't be done, right? Yes, but there's another caveat. I feel like on mobile devices, that's not really considered on web, if I'm playing an audiobook or if I'm playing music or radio or maybe I'm listening to something important like in an app, it should be and is in my mind, an accessibility violation. If your app comes up and initiates what's called an audio session before the audio is needed to be played, YouTube and Twitter or X does this all the time to try to get things loaded faster for autoplay of video. I feel like that is an accessibility violation because maybe you do have something important on that you're playing and these apps just steal the audio for their own use.

Yeah, sorry Michael, I'm going to show.

If you're done no go ahead.

So again, it's really not written in the standards.

Right.

But it really should be because audio should not be taken from one place to be played in another and you shouldn't steal the audio session to go then play it somewhere else. And I think that is a very important thing that really should be addressed, and it's not. And so if you're watching this and you're an auditor, if you're auditing mobile apps, make sure you could look at that because you want to make sure that this app isn't just going to steal people's audio when they're doing something else. If you're a programmer, please make sure that you don't do that.

Yeah, and it's very easy to do because a lot of programmers like to say, okay, if I go to this screen, I'll just set up this audio session. No, set up the audio session when the person presses the play button or the Watch video button or anything like that.

Yes.

And that way you can make sure that you are not going to interrupt audio until you're ready to do kind of as our final topic here. Taylor, do you feel like the because I really feel like there is there are several differences between how certain images should be laid out and spoken and viewed in an app compared oh yeah, we didn't even talk about buttons. Let's go to that real quick.

I was going to say we're missing a couple of crucial aspects, Michael buttons and know we shouldn't have links in mobile app, but that's all well, we.

Should have links in mobile apps, but they should be links. So they should look like links that have an underlined text. Like if it's in the middle, I would call that an inline link, but.

Not fake links as I call it.

We're just links to so a button can be a button and a button is typically by Apple standards, a blue accented text button. They don't really put an outline, they don't really do any of that anymore. You could turn on button shapes and outlines, but they look very similar to links. And so I think a lot of companies really consider them as links, even though they should be buttons. Same as list items. A list item is a scrollable list of dynamic items that can be acted upon. A good example of that is like the I accessibility app or any podcast app where you're picking from a list of episodes or Apple News. Right. Those should not be considered links, but they are. And Taylor, do you want to talk about that? Like how other companies look at that kind of content?

Oh, yes, I can. I won't give any names, folks, because.

I don't want to do that.

But I will just say I know of some companies who literally think that. How do I explain this, Michael? If you go to a new page, that's great. That should be not. Even a button. What do we call it? Like a clickable thingy?

What do we call that?

Well, they could be buttons or like navigation links or usually buttons, but I'm.

Saying they shouldn't have buttons on them. You know those buttons that you click? They don't have the word button in them, but they're like list items can do that, list items. But they believe that you should only use buttons in certain occasions. You shouldn't have an app full of buttons.

Got you. So they're saying that if you are going to a next thing, it should not be a button.

Right.

So if you're using a navigable item that can cause you to go from one screen to the next, it should not be a button object or view.

Yes.

So what are your thoughts on all of that?

I don't like that because in my opinion, if I'm going through an app, I want to know that something's going to click because I could just assume that's going to go to the next thing.

Right. But how do I know?

And so buttons are really crucial to understand how this app is laid out and to understand what I need, you do. And also, what if I can't move on? Then sometimes they're not even like grayed out or aka dimmed for screen readers. And then I wonder why I can't move forward. Very important to make sure that we can fix that.

Yeah, but I think it's important to not just lump everything into the term of some companies consider mobile apps. A navigable item should be a link. That might be the case on the web, but not in a mobile app.

And I think that's the thing. Some of these companies, folks, come from a web mentality. And so I think one of the things is if you are a developer and you want a company, finding one that knows mobile and preferably has mobile developers on staff is probably your best bet because that way you get mobile tailored suggestions.

Yeah, see, that needs to be your slogan. Tailored accessibility by Taylor Aren't.

Okay, but no, I mean, what I say is having developers who are on staff, who understand mobile and who can give you code level recommendations and who also know mobile so that they won't give you recommendations. Like everything shouldn't be an actionable button or whatever I just said a minute ago, I don't even know because it's.

So bad I forgot about.

So, you know, buttons, list items, headings, images, all of these things really need to be thought about in comparing things between mobile and web. Is there any other things that I'm missing, Taylor, that you want to bring up again?

Always captions transcripts. Got to make sure you have your captions, got to make sure you have transcripts for audio. Also making sure that I'm just trying to list out everything I know. If you're going to go to a web page, make sure that you link it properly, like within a link that goes out Safari or asking the user for the browser. But really, that's all I can think about. Of course, color contrast. Michael, we got to think about color contrast with mobile. Of course, we talked about dark mode earlier, but is there any other color contrast stuff?

Well, I think with mobile, you really want to follow the WCIG standards on that, just as you would. I think the biggest things we wanted to focus on are the exceptions to the rules.

Yeah, I think cover all the kind of did.

I'm sure there's others that we didn't really go through, but I think this has been the longest episode of Programmatic we've ever recorded.

Yeah, I'm super pumped about it. And if you have any feedback or you want to tell me something maybe that I didn't think about, feel free.

To give us feedback.

So in all of that to say, I think this has been a great episode of Programmatic. We're going to be back for more. And just keep this in mind. Programming needs to be a creative and artistic career and hobby, and it doesn't need to be something that you stress out over accessibility. So having good practices as you begin programming will really help you out in the long run. It's also good to know somebody that like Taylor. In my case, I say, hey, I finished an app like VF Starter. Go audit it, and I pay her some money and boom, here's the problems. Okay, fix them. So that's all very useful. Getting that stuff done from the start is very useful. We don't want to go too far in the realm of accessibility on this podcast as we want it to be for all viewers. But I wanted to bring this up because it was something we were talking about at dinner. It's like, you know what we need to record an episode about? Um, yeah, this is going to do it for this episode of Programmatic. We'll be back soon with another episode. Taylor, how can people find you online?

So you can find me on Macedon at Tayarndt, at Techopolis. T-E-C-H-O-P-O-L-I-S social. I'm also on X at T-A-Y-A-R-N-D-T. And I'm on YouTube as well. At Taylor. Well, actually, the username is still Tay. So Tayarndt, if you literally just search my name, I'm sure you'll be able to find me. And of course, I also work with Tecopolis as well.

So you can find me on mastodon at Mikedoeys at Tecopoulos social. You can find me on X at Mike Doeies. You can find me all over the web. Just search for Michael Doeies. You'll be able to find me. If you want to email me about the content today, you can email me at [email protected]. I'll get back to you and we may talk about it on the next show. So thank you so much. I want to make this more of an interactive show in the future, so if you have any questions or programming questions and things like that, let me know. I would love to be able to help out with that. And until next time, enjoy programming and make something awesome. Thank you.

Bye bye, you.