[00:00:00] Tessa: you wouldn't be a front end engineer if you didn't wanna test things like 10 different ways for every change. Right.

[00:00:06] Jared: Hey folks. Welcome back to Elm Town. I'm your host, Jared Smith. We'll be visiting with Tessa Kelly today.

[00:00:14] Sponsored by Logistically

[00:00:14] Jared: But first, let's talk about our sponsor, Logistically. At Logistically, we make transportation management software for third party logistics companies and shippers.

[00:00:23] I'm grateful that Logistically pays me to spend a bit of my time recording Elm Town episodes, as well as pays for our recurring production and hosting costs. We build the front end for all new features in Elm.

[00:00:34] We have over 100,000 lines of Elm code in production. We're always eager to talk to folks who enjoy writing Elm. Please drop us a line, elmtown@logisticallyinc.com I'll add a link in the show notes.

[00:00:47] Introducing Tessa Kelly (she needs no introduction)

[00:00:47] Jared: Now, let me introduce Tessa Kelly. Tessa works at NoRedInk as an engineer writing Elm and publishing blog posts.

[00:00:57] She has been on two previous Elm Town episodes, episode nine and episode 30. She's also been on Elm radio a couple times, maintains a couple of Elm packages accessible-html and the pallette package, and has also presented at Elm Conf at least three times that I I account here. And, uh, also been on the Software Unscripted podcast and I'm sure a bunch more.

[00:01:22] Tessa, welcome to Elm Town.

[00:01:24] Tessa: Hi. I'm excited to be here.

[00:01:26] Tessa is stealing her brother's life

[00:01:26] Jared: So I wanted to start by going back into your history and asking you how you got started in computing and programming.

[00:01:36] Tessa: Yeah, so I guess the start was that I was really just trying to steal my older brother's life. Um, so, uh, he had decided to get into programming. He went to Hack Reactor, which is a programming bootcamp, and then he got a job at ClassDojo, which is an education technology startup. And so then I decided to go to Maker Square, which is another programming bootcamp that was later swallowed by Hack Reactor.

[00:02:04] And then I got a job at NoRedInk, which is an education technology startup. So it's going pretty well so far, stealing his life.

[00:02:13] Jared: Oh, that's great. Yeah, I know ClassDojo, my, uh, son's school uses that for communication. So, um, yeah, that's, that's really neat. And, uh, of course, I, I know of NoRedInk. I've actually used it a little bit myself, playing around and seeing what it's about. But of course, uh, NoRedInk is kind of famous for Elm, if you will.

[00:02:35] Um, so you, you're saying that you were kind of doing what your brother was doing, right? So what was it? About it? Did you see him kind of working and you thought, oh, that would be nice. I like that, or, or could you go in a little more detail about your thoughts there?

[00:02:53] Tessa: I think one of the things was that he liked his job and then another thing was that he was excited about the like, level of impact that he could have as a single person. Like the, the scale,

[00:03:08] Jared: Yeah.

[00:03:08] Tessa: how many lives you can, you can touch. So many people use ClassDojo and so many people are so fond of ClassDojo and that's.

[00:03:16] Kind of amazing compared to a lot of other opportunities that you can have in, in life where your impact is very local. Also extremely important to like, have a positive impact in your local community and your family and all of your interactions. But, the scale at which you can do good or harm in like a web application is, is pretty exciting.

[00:03:38] Jared: Yeah, that's a good point. I guess I hadn't really thought about it in those terms, but I really like that and I think I'm gonna take that with me as well.

[00:03:49] The early days of Elm at NoRedInk

[00:03:49] Jared: So when you were getting started, what year was it that you started at NoRedInk?

[00:03:57] Tessa: 2015, I believe,

[00:04:00] Jared: Okay. And

[00:04:02] Tessa: of 2015.

[00:04:04] Jared: gotcha. And were you using Elm at that point that it was already introduced? Correct.

[00:04:10] Tessa: So when I started at NoRedInk I learned what Elm was during the interview, which is probably not what you should do when you're walking into an interview. Like, huh, what's this major technology that you're using? Um, but yeah, so I had, I had no idea about Elm, at that point. But as soon as I got the job at NoRedInk

[00:04:31] all new code on the front end was being written in Elm. So that's what I started learning and writing.

[00:04:38] Jared: Awesome. What version of Elm was it in those days? Do you remember?

[00:04:43] Tessa: 16, oh, not 16. Does that sound right?

[00:04:47] Jared: That sounds correct to me. That was before I started using Elm, so I'm not sure exactly, but were there signals still

[00:04:55] Tessa: There were, there were, I remember not fully understanding signals. That's my primary relationship to signals is being a junior programmer and being much more comfortable working with, um, like the HTML side.

[00:05:10] Jared: Right. Yeah, I, I hear that also, I've recorded an episode with Aaron Strick and he said a similar thing that, that signals were, a difficult thing to understand. And I started with Elm 18, so I got to sort of skip over that, that difficulty. So, yeah. That's really cool. And so, Elm, I assume, has changed a bit over the years at NoRedInk.

[00:05:39] Could you maybe describe how it's changed, if it has?

[00:05:44] Tessa: In terms of like how NoRedInk uses Elm

[00:05:47] Jared: Yes, that's what I

[00:05:48] mean, Yeah. Mm-hmm.

[00:05:51] Tessa: Yeah, I think, um, patterns and styles have definitely changed and I think our usage has matured. Um, I think early on we definitely were splitting things up into different files, so we would have a model file and a view file and an update file.

[00:06:06] And we've definitely moved away from that following more the advice in the, "The Life of a File" talk. That's, I think, very popular. And I think that's been, uh, a good improvement. I think we've also nested less, so less use of Html.map unnecessarily, keeping things a little bit flatter, some of our older pages.

[00:06:32] I think we tried to make impossible states impossible within a given module that was like wrapped via Html.map and all of all of these maps in a way that could make it a little bit difficult to follow. So I think a, a lot of our code has gotten flatter in general. Um, the other thing that's changed a lot is our component library, noredink-ui, has matured a ton. A lot of our button version or whatever is on like a V 11 now, but that doesn't actually reflect all of the versions that we went through before pulling the package out, like into a package.

[00:07:12] Jared: Mm.

[00:07:13] Tessa: So it's just been like version after version after version of buttons say, and version after version after version of modal.

[00:07:22] And hopefully they're getting better and hopefully they're getting more accessible as as time goes on. So I think, I think that's an area where we've improved a lot, um, and where our visual consistency and like behavioral consistency across pages has improved a lot because when you're first starting with Elm, of course you don't have a library of in-house built components to, to work from.

[00:07:45] Jared: Right. Yeah, that makes sense. And I've definitely looked at the noredink-ui library as inspiration, you know, for our own internal UI tools and, and so yeah, I've seen those V 11 V12 and, and didn't think about that, that of course there would be iterations before it was, was published. So, yeah, that, that makes sense.

[00:08:08] You would, um, not see that. So, you've, Changed how you've approached your usage of Elm at NoRedInk.

[00:08:17] Motivation for building tesk9/accessible-html

[00:08:17] Jared: And you also have built a package around writing HTML with Elm, right? The accessible HTML package. And so what was your motivation for building that?

[00:08:33] Tessa: Accessible html. Partly I wanted to learn more about accessibility. It also seems like we had helpers for other. Attributes. , and I wanted there to be like helpers for attributes related to accessibility specifically that were easy to use. So you weren't always using strings. Um, since I think most people would agree that like strings are less good than, variables where you're not gonna make typos.

[00:09:02] And,

[00:09:04] Jared: Right. You're making impossible states. Impossible.

[00:09:07] Tessa: Yeah. Yeah. Eliminating a, a class of bugs, hopefully, um, hopefully eliminating a class of bugs. Yeah. So that's, that's I think the main motivation was learning. And then, oh, and then I guess the other thing is that I saw a place where I could add value without needing a ton of expertise necessarily, because there is the, there's the ARIA spec, there's clear descriptions, uh, What every attribute is supposed to do, and the values that are allowed are clearly written down in the spec.

[00:09:43] So it was, um, something where I could make the package with the, like attribute helpers available and fill what I saw as a whole in the package library, um, but not need to be an expert yet.

[00:09:57] Jared: Right. Yeah. So you're creating something to learn it and also make impossible states impossible. And, and so I guess then, let's dig a little deeper. What about the motivation for accessibility in general? And, uh, maybe this should be, you know, a given, but I don't wanna make an assumption. And so if you don't mind to kind of, uh, share a little bit more in that.

[00:10:26] Tessa: Yeah. Yeah. I mean, I think in general I'm very interested in doing my absolute best to do quality work. And I think quality includes a lot of things that are potentially challenging to do well. Like it's hard to make things usable. It's maybe you have to know what you're doing to be sure that things are secure and that you're protecting your, your user data correctly and that you're, you're doing things according to the latest standards and regulations.

[00:10:55] And I think accessibility is part of that for me. Um, there's like what does, what does being a good front end engineer include? It includes people can use your site, um, to, to my mind. So that's part of it. And then I think another part of it is that there are guidelines that you can follow and the guidelines aren't necessarily perfect.

[00:11:23] And there are complicating factors in terms of like, this screener does things this way and that screener does things that way and you have to test things. Um, but you wouldn't, you wouldn't be a front end engineer if you didn't wanna test things like 10 different ways for every change. Right. Uh,

[00:11:41] Jared: Yeah.

[00:11:42] Tessa: but I guess the, the guidelines are appealing as well cuz this is the path to do things well.

[00:11:47] Um, and like following the guidelines gives you, uh, a little bit of a roadmap, which is nice to have.

[00:11:55] Jared: Yeah, I think that makes sense. And I know you've discussed this in detail before, and if you go to the accessible HTML package, you have some information on there. Uh, you gave the "Accessibility with Elm" talk at Elm Conf 2017. Um, you've also mentioned it on Elm Radio. These, uh, principles, four principles of accessibility, perceivable, observable,

[00:12:23] understandable. O operable, sorry. Yeah. Operable, uh, understandable and robust.

[00:12:30] Tessa: Mm.

[00:12:31] Jared: And so, um, Yeah, that I think is a, a nice foundation if you get the right words for it, um, to start.

[00:12:41] Not disempowering people

[00:12:41] Jared: But, I wanted to talk a little bit more because I had mentioned this when we were talking beforehand about, you know, empowering and you had mentioned, you know, now it's more about not disempowering.

[00:12:52] So would you mind to elaborate on, uh, on what you mean there by that?

[00:12:59] Tessa: Yeah, totally. So I think what we had talked about over email was the idea of maybe being drawn to accessibility work because it means empowering people with disabilities. And I think I said that I kind of think of it the opposite direction, as in like not disempowering people. Um, and so maybe a, a good example of this, uh, like migraines, a lot of people get migraines.

[00:13:32] Um, and for some people a migraine trigger might be related to like flashing lights or bright colors that they can't control. So if you're failing to support high contrast mode, that's, that's, Literally like laying somebody up for potentially a couple of days, which is a, that's a very literal disempowering of a person.

[00:13:58] There's also people, um, with epilepsy for whom flashing might literally cause a, a seizure. And, um, so like a failure to think about accessibility in that case, like, this person was just going about their life totally fine. They visit your website and now they're having a medical event. Like, so my, my sense of like the bar is like, you know, don't give people seizures.

[00:14:27] Don't give people migraines to the degree that it's in your control.

[00:14:33] Jared: Yeah. I mean that's is very powerful to think about in those terms, and I think I. You've talked about this a little bit on the Elm Radio episode as well about, um, RSI, which is something that I've experienced myself and struggled trying to use, uh, different software, um, to, you know, there was dragging speaking tool that I had tried to use at one point, uh, as I was working through that.

[00:15:02] And, uh, there was a lot of frustration with that. But I mean, you're right, you can actually be in pain because of how you're using, um, a tool. And like you said at the very beginning, we can have a lot of power that can be either positive or negative. And so, um, yeah, if you look at this from the perspective of not disempowering, as in I, I like this, there's this quote about challenging your assumptions that I think applies really well here.

[00:15:32] And it's by this runner, uh, Lauren Fleshman, uh, on, she was talking on the. Daily Stoic podcast. She said, "Don't assume that you're the default. Make space for there to be other ways of being."

[00:15:45] Tessa: Mm-hmm.

[00:15:46] Jared: So I, I think that that, um, that fits really well with this conversation of, of not making an assumption about what the norm is.

[00:15:59] Tessa: Yeah. Yeah. I think, um, the number that people use is one in five people in the US have a disability. So you're, you're talking about a lot, a lot of people.

[00:16:13] Jared: Yeah. Wow. , and you also mentioned in our email conversation about the social model of disability. And that was interesting because I had not really, uh, heard that mentioned before. Could you elaborate on that a little bit as well?

[00:16:29] Tessa: Yeah. So I think, um, I'm sure that there's someone more qualified to speak on this than I am. Uh, but I think the concept with the social model of disability is that, Whether you are disabled or not depends on situation and accommodations, um, in a given scenario. And this is just one way of thinking about disability, and I don't mean to say that it's the only way, it's a way of thinking.

[00:16:56] Um, but if you imagine, say a conference and there's a stage and there's no ramp and there's someone in a wheelchair who's gonna present, the person in the wheelchair is perfectly capable of giving that presentation. The the wheelchair is irrelevant to their presentation. Um, it, it, it literally has no bearing on what they're gonna be talking about or their slides totally irrelevant.

[00:17:28] The problem is that there's no ramp and that is causing, any, any difficulty that arises.

[00:17:34] Jared: Right. And the effect of that, if that person is unable to present that day, not only affects them, right? It affects everyone at that conference who was not able to hear that information, right? So I, I think that there's this, um, way that we can talk about how people are, uh, for whatever reason, uh, motivated by themselves or for themselves to do certain things.

[00:18:05] And so, if you think about it from the perspective that by. Not disempowering other people. We actually benefit ourselves and everyone. So I, I think that, um, it, it is good to talk about this and these, you know, and, and to think of just different perspectives and different ways of, of understanding, uh, what our goals are and what our motivations are.

[00:18:30] So, yeah, that's, that's really neat.

[00:18:33] The business motivation for accessibility

[00:18:33] Jared: I wanted to ask you if you had thought much about, uh, I'm sure you have because you, you do work on accessibility at NoRedInk. are you, and there was this, uh, episode that you were on with the accessibility bats or as part of the accessibility bats accessibility and practice on software unscripted.

[00:18:57] And so I know that you spend at least a part of your time at work working on, uh, directly accessibility. And so when you're talking about that with people who are, are maybe not directly on the team and talking about maybe the business motivation of accessibility, what things do you talk about in those terms?

[00:19:17] Of course, we've, we've mentioned the, the fact that one in five people may have, uh, you know, a disability and that of course would affect your users.

[00:19:27] Uh, the number of people who may be able to use your software or use it without causing them harm. And so if you could talk, maybe if there are a few things that might be motivators for business if people are trying to motivate their business to do that.

[00:19:46] Tessa: Yeah. Uh, well, one thing is that there are, there's potentially legal liability if, um, you don't make your web application accessible. And I'm not a lawyer, so I'm not necessarily the best person to give you legal advice. Uh, but there is, you know, There's increasing legal battles on that front.

[00:20:12] So however they turn out, being involved in a legal dispute is expensive. So that's one consideration. Another consideration, depending on whether you're straight to consumer or more enterprise, is that, um, your purchasers might be looking for a product that adheres to various, um, guidelines. Uh, there's what's called a, a VPAT or accessibility conformance report that your sales team might be asked for, say so.

[00:20:52] You could think of your VPAT as both a reflection of the accessibility of your application, but then also as a sales tool. If you do well on it, which I, uh, recommend doing, because people with disabilities need to be able to use your application. And if you are, , making an application that's more direct to consumer, uh, I think one in five people is kind of the end of my argument in the US.

[00:21:19] Like that's, that's a good reason right there. There's a ton of people who potentially would wanna use your site that you might not even know about. If your site's not accessible, if they can't use their, your site, like they're not gonna keep trying, they're just gonna find an alternative. Uh, yeah. So those are some reasons for us specifically.

[00:21:42] I think there's another reason that's pretty interesting, which is that

[00:21:46] you can think about developing motor skills. Uh, which is something that all kids are gonna be having, like if you're talking about a fourth grader, their motor skills are still developing The kind of guidelines that are gonna help somebody with a motor disability to to click something, um, are also gonna help your average fourth grader.

[00:22:10] I think this is a, a case where building an application with accessibility in mind will make your application better in general. And then if you have a user group that's specifically maybe got a, a lower attention span, not gonna be able to focus as long, might need help with reading, still developing readers, uh, dealing with dyslexia for the first time.

[00:22:35] Like there's a lot of overlap. Kids are, some kids are disabled, and then also many kids are facing the same functional needs as other disabled users would be. Which is, you know, something to consider.

[00:22:51] Jared: Yeah, I think those are great points. And on that topic of your particular case where you're working with users who are building software for users who are unable to choose what software they use, you mentioned this on Elm Radio and I thought that was, uh, a nice lens to look at it too, is you are, you have, I think, more responsibility in that regard because. They don't have a choice.

[00:23:21] And, and so if you are, um, in that business, and of course, you know, there may be legal repercussions, but just as a business who is, you know, considering your, considering your, uh, impact on users, I think that that is a, a huge motivator. That's good. Yeah. Um, and one thing that I thought of as you were talking is that I think there's a, a way of thinking about software from different lenses that makes your software, like you said, robust.

[00:24:02] Right. Is, is one of those principles, because you are thinking about the example of the five star rating, right? The, this, the. This thing that you had built at one point where you had started out by saying, oh, well I'm gonna make this accessible by, you know, star is, uh, what was it, star filled or star unfilled.

[00:24:26] And then thinking about it deeper of, oh, well maybe that's not really the message I'm trying to convey. Not only did that understanding that realization help the software become better, but it helped you as an engineer to think about the software in deeper terms and have a better understanding. I think, and, and at least I find that when I'm thinking about different perspectives and building tools that are going to be, um, operable in different ways, then I'm going to need to think in different ways that ultimately make me a better developer of that particular thing that I'm building.

[00:25:15] Tessa: Yeah. Yeah, I think that makes sense. Like the more you're asking in context like what is this here for? Why does this exist? What are we trying to convey? With this image, is it decorative? Is it meaningful? Why is it meaningful? For whom is it meaningful? What parts of it are the bits that actually matter?

[00:25:34] The more you think like that, um, about like one small piece of your application, the deeper your understanding will be like across the board and the better you'll be able to remember why you made the decisions that you did later on.

[00:25:50] Jared: Yes. Yes, exactly.

[00:25:52] The tests are there for you

[00:25:52] Jared: And in terms of better understanding why you are making those decisions. I found that by doing test driven development and building in those decisions into those tests has made it easier for me to go back. And understand why those decisions were made. So, uh, for example, um, you've talked about program test and a, let's see what that was "Writing Testable Elm" at Elm Conf 2019.

[00:26:27] And so I think that was a, a really nice talk. If you're using that tool, program-test, to create, uh, different workflows or, or to test different workflows, then I think you are building in your reasoning for why you have those that you can later go back and look at and say, oh, well we build it this way because we need to make sure that we. This worked for this particular use case. So I think that is a, a pretty neat, , side effect of that. You know, it makes it more robust, but then you have documentation built in by doing that.

[00:27:10] Tessa: Yeah, I agree. I'm a big fan of tests. I was just reflecting the other day, after starting something that I was intimidated by and I was like, I don't know how this is gonna, is this gonna go at all? I don't know. We'll see. We'll see. Um, like how much tests just help to get you over that initial hurdle of I don't know where to start.

[00:27:31] I'll just start with tests and then at least you've got something written down and can work from that. And then when you do mess up later on, the tests are there for you.

[00:27:42] Jared: Yeah. That is nice.

[00:27:44] Tessa: I think tests are another thing I mentioned before about being drawn to things that like speak to quality, like the ways to make things quality. And I think tests are another one of those things that really appeal to me cuz you know that if things are well tested, They're going to be higher quality or they're going to be easier to change to make high quality.

[00:28:04] Jared: yeah. Yeah, that's a, a great way of putting it.

[00:28:08] Using Elm philosophy to avoid the "accessibility dongle"

[00:28:08] Jared: So if you are thinking about quality, which I think that is probably going to be a lot of our, our readers, then, creating a software that is robust in that it's taking into account different use cases. Um, it's also considering different perspectives, right?

[00:28:30] I think this, this really ties into the Elm philosophy tweet that, uh, Evan had tweeted out, I don't know, a few years ago, and, and there were a, a few different items on that. And, and two of those items I thought really fit into this conversation and I want to get your thoughts on it, but one of them was "learn from everyone". And the other one was "take responsibility for user experiences". And I think if you subscribe to Elm, as, you know, as a tool and, and the philosophy behind it, I think that yes, you have this responsibility and you are going to want to learn from everyone and, you know, build a, a higher quality software in the process.

[00:29:13] Tessa: Mm-hmm. I, I agree with that. Yeah. Uh, one of the things that people in the accessibility community emphasize really heavily and that we need to be doing better on, on our team, and hopefully we will do better on as, as the team grows, is, really involving people with disabilities in user research, in building the actual application, like in doing the dev work and doing the design work.

[00:29:42] Like from jump, um, from Ideation onward. I think that ties into learning from everyone, but also like involving everybody and not necessarily trying to understand every lens yourself, but bringing people whose like firsthand lived experiences who have firsthand lived experiences to show, to share, to the table and to the, I don't know, wherever you build software to, to the computer, I guess.

[00:30:16] Jared: Right. Yeah. And so I know that from the conversation you had on Software Unscripted that there are considerations about how you go about that, right? It's not, you cannot say, you know, for example, whether or not the user is. Using a screen reader is that true statement.

[00:30:37] Tessa: Yeah, you, you shouldn't, I think is the,

[00:30:40] Jared: Oh, okay.

[00:30:41] Tessa: mostly shouldn't. Yeah, I think you can on, um, like native apps. I, I don't know how on a, on a web application, yeah, I think generally people advise against, doing that tracking.

[00:30:57] Jared: Right. And so, and to the point of I think of that conversation was because you shouldn't do that and you don't know whether people are using your software and, you know, and just living through the pain or whether they are using it and then going away, or to what Richard had said about, you know, switching browsers.

[00:31:22] I use Firefox as well, and sometimes I open up a website in Firefox and it says, you need to open this in Chrome. In fact, the recording software we're using, uh, made me do that. So I, I think that, that's even more important when you're talking about accessibility and so by actually involving the people that are experiencing those things in the conversation, yeah, you're going to get better feedback and you're gonna build a better product in the process.

[00:31:53] Tessa: And you're not gonna build things that people don't need or want. There's something that people call an accessibility dongle, kind of disparagingly, uh, which is where some person has tried to empower somebody with a particular disability, but they didn't actually talk to anybody with that disability first.

[00:32:14] And so they build something that's not useful or, or practical. And I, I think that goes back to there was a, a really excellent talk at axe-con this year around user research. And, uh, the speaker emphasized that user research doesn't start when you've built a thing and wanna see if it works. Like user research starts when you have the idea.

[00:32:46] Jared: Right. Yeah. And that is a, a good question of then where, do you start in- incorporating people into that process at NoRedInk?

[00:33:01] Tessa: Well, this is something where I think that we can do, uh, a better job where I think there's more room for improvement. For us, where we're at in our accessibility path at this point is largely remediation. So we've got a lot of accessibility issues. We've done some audits and then we fixed many of the issues.

[00:33:26] Still got some left, but making, making a ton of progress. But at this point, we're mostly focused on unblocking users, making sure that the information is conveyed at all, making sure that it's operable at all. Um, and then we're optimistic that once we achieve that bar of like can be used, we'll be able to, to work more on the, is nice to use,

[00:33:56] um, makes sense, questions. So that's another thing is that the earlier you do accessibility work, um, the less remediation you'll have down the road and remediation, it takes time.

[00:34:11] Jared: Yeah, of course. And by starting upfront with that in the design process, I think the process of actually building that then is hopefully not going to be as lengthy, right? Because it would not include the amount of time to do the remediation as well. And particularly,

[00:34:32] accessible-html design ideas

[00:34:32] Jared: I like the fact that because we have packages like accessible-html that

[00:34:38] there are some of those things that can be made impossible, right? It follows those guidelines. And so for example, if you're using the the tab and tab list and tab panel, you know, functions, that's going to guide you to making sure that you are creating something that is at least, baseline accessible, right?

[00:35:01] Tessa: Hopefully, I think what I'm probably gonna do, this is like some, some plans for the future. I'm probably gonna remove the straight HTML helpers that aren't related to HTML attributes. Because I think that there's, there's more than one reasonable way to, to build out a tab component, for example. But it's very hard to make a component that supports every reasonable way that you could build it.

[00:35:35] And the, the API ends up being more complex than the, like, file structure for accessible-html really like, makes sense to have. So like for noredink-ui, for example, we have a tabs component. It's on V7. It's got like 30 different attributes that you can pass to it. And the way it's actually set up, it really doesn't, it doesn't support varied interaction patterns.

[00:36:05] Like there's, there's two main keyboard interaction patterns that would be reasonable to use for a tab component. So the first one, you hit the tab key on your keyboard and then you're brought to one of the the tabs and then you use your right or left arrow key to move to the next tab over. And when you do that, your focus moves to the new tab.

[00:36:29] The new tab is selected and the top panel changes. And that's great. And I think that's really pretty intuitive. Although if you have a data intensive application and changing the tabs is gonna trigger an expensive request, maybe you want the user to confirm that they wanna change to that tab before you actually switch and like make a million requests, hopefully not a million, make do something expensive that they don't actually want you to do.

[00:37:00] They're trying to get to tab three and here you are making them tab. With a arrow key. Three of that doesn't make sense. So then the other pattern that makes sense to, that's reasonable to use for tabs.

[00:37:11] You hit the tab key, you're brought to the first tab. You hit the the tab key again, and then you're brought to the second tab, and then you hit space or enter to actually select that tab so that the focus state and the um, selection state are decoupled. It's more interactions, which is potentially worse for the user in some ways.

[00:37:37] But if you're gonna be doing something expensive, maybe it makes more sense, which is to say like there's. A lot of different reasonable things that you could do, even with a, a seemingly straightforward component like tabs. And I don't know that I can do a good job on that, given like the complexity of styling, given the, the possible options that you could have that would be reasonable to do in, in that single file structure.

[00:38:12] Jared: Yeah, that makes sense. I think if your tool has reasonable defaults, I think the, the thing that I like about it is that it doesn't mean that you can't build things other ways by looking under the hood. Right. I, I think that that's one thing that I like about it, is that you can see. Well, this is one way of doing it.

[00:38:36] It may not take every, you know, potential case into consideration. Like you said, scrolling through or tapping through seven different tabs and loading all of those to get to the last one, uh, might not make sense if you're reloading data from the server. But, um, but at least you get an idea for, you know, some of the things that would be involved in that.

[00:38:57] And, and so perhaps then if it were not an actual function in the Accessibility module, then it would be the, um, an example, you know, and, and maybe you would have examples of each. That would be nice, I think, as a developer coming to that and, and wanting to implement that to see, oh, well this is, you know, a basic example of.

[00:39:22] How you might have one interaction, and here's another case where you may want to build it slightly differently because of, you know, these other considerations and so this is how you might do it for that case. I don't know. That's,

[00:39:36] Tessa: Yeah, I mean,

[00:39:37] I I think it's, uh, one of the challenging things about being an Elm developer is that the, like, there are authoring practices. There is the authoring practice guide, which has examples of like tabs and other commonly used components, but they're not an Elm.

[00:39:58] Jared: Right.

[00:39:59] Tessa: So the approach that, um, the approaches that people take in like HTML with some vanilla js, it's not gonna look the same as in an Elm version of the same component.

[00:40:12] And it's not gonna give you any ideas for like API design.

[00:40:17] Jared: Right. Yeah. And, and so then if you were to, uh, to take those parts out, then I think from my understanding, then you would have, tools that are still making impossible, states impossible, you know, preventing people from building HTML that is inaccessible with other functions like the image helpers and things like that, right?

[00:40:45] Where you cannot add in a, an image that does not have all text or, you know, a div that has a clickable, uh, event on it. Is that correct?

[00:40:59] Tessa: I might, I might take those out too. I don't know. It's, so the, the stuff that I'm, the parts of the, of the library that I'm really confident in are the ARIA helpers, the role helpers, and I think the value there. It is partly typo prevention. And I think that if you're somebody who's using fancy like VS Code Elm stuff and you've got your docs popping, popping up right in your editor and you're using that and then I've got links in there to like the, the ARIA spec, I think that's, that's really where the value is, is like depending on how your environment is set up, it will hopefully make it easier for you to get access to the information that you need, but that you're not that

[00:41:49] practiced at, at browsing. Like maybe you don't really use the, the specs that much. Here's a direct link. This is the piece that you care about and here's a, a brief summary of when you would need this and what like warnings about it would be. So that I'm confident that that has, has value. The decorative image or non decorative image,

[00:42:15] I think that's also pretty useful. Makes you think carefully about which thing you want. The trouble with preventing clicks on divs is that it?

[00:42:27] I think it's, I think it's nice to avoid clicks on, on divs often, but there are times when you might need a click on a diviv and that's like the reasonable thing to, to do. So for instance, if you have a modal and the modal has a semi-transparent backdrop, For our most modals, um, where you won't lose like a lot of of work like modals, where you're not asking people to like input their credit card information and like draft all of this junk.

[00:43:02] If you click the backdrop, the modal should close. If you hit escape, the modal should close. It doesn't really make sense for the backdrop to be a button. Like, I don't, I don't think that would really get you anything. I think that the backdrop being clickable is an affordance for mouse users. That's an accessibility feature for people who primarily use, um, a point and click behavior.

[00:43:32] And I think that's, that's fine as long as there's an equivalent behavior for keyboard, primarily keyboard users like the escape key. If that makes sense. So it's like a, it's a parity thing.

[00:43:47] Jared: Yeah, I think that makes sense. And that would still be possible by using the default HTML package, right? So I mean, if you were using the accessible HTML package in combination with that, I think you would still have that as an option,

[00:44:06] Tessa: You would, you would, it's it's a, it's more of a ergonomics thing.

[00:44:10] Jared: Yeah.

[00:44:11] Tessa: Um, an ergonomics concern. But yeah, I'm, I'm torn about it. I've been thinking about it for a long time and I haven't made any moves, so I don't know if people have thoughts, tell them to me gently.

[00:44:23] Jared: Yeah. There we go. So listener out there. If you are using those and are getting value out of those helpers, then please, uh, let us know. And, uh, constructive criticism,

[00:44:37] Tessa: feel free to, to leave an issue on the, on the package, uh, on GitHub.

[00:44:43] Jared: There we go. That's a nice way of approaching it. So, yeah, that's, um, that's an interesting conversation getting into API design here and

[00:44:54] How do you feel about CSS?

[00:44:54] Jared: actually, In that vein, let me ask you about accessible-html versus elm-ui, because I think that's kind of a popular, uh, tool that people are using as opposed to HTML directly.

[00:45:10] And I know some of the functions available and the way that they're designed looked very similar to accessible-html to me. And, and this, and I'm talking about Matthew Griffith's elm-ui package here. Um, like for example, the, uh, label above and, and label below, things like that, that, uh, require you to add a label when you are creating an input, for example. Do you have any thoughts on, on how, how those are addressing accessibility and whether or not you, you think that approach is, is working? What do you think?

[00:45:54] Tessa: I can't really speak that much to elm-ui, um, because we don't really use it very much at, at work. I think there's one place where we use it, but for the most part, because we've really committed to our own in-house component library, we've really wanted to write css. I guess maybe that's like the, the, bifurcation point for like, elm-ui or not, it's like, how do you feel about CSS? And I think for me, and for some of the other people at NoRedInk in particular, some of our designers, it's like, I want the finest of fine control over everything. I wanna be in control of every little detail. Um, but if that's not what you want,

[00:46:42] then you'd, then you'd make a different, a different call there. I think it's, it's great to hear that the API enforce is requiring labels above inputs. That's awesome.

[00:46:52] Jared: Yeah, and that makes sense that I think the, the idea of particularly the fact that you're accepting that you're going to continue to use CSS and the fact that you are, are going to have that fine grain control with your component library where you can choose to add in, you know, the accessible roles and, and ARIA labels and things like that, where I think that will create value for everyone who's using those components.

[00:47:25] And then within that you have whatever control you need. And with that, it, it really makes sense, I think, like you said, to, to give people more control, but simply give them these helpers that prevent them from doing typos and, and kind of guide them to, Hey, if you want to use this particular accessible feature, here's some more information about it, you can read up on it.

[00:47:50] And I think, yeah, that, that seems like a good pairing and it seems like a pragmatic approach.

[00:47:55] Tessa: I think it's worked pretty well for us and it's also, it's made it possible for us to, to make a lot of the progress on like accessibility, remediation that we have to, to really like, own our, our input. Say, um, like right now we've changed how our. Like, like form input, APIs work so that you can conveniently add like a guidance message, like password must be six to 12 characters or whatever, um, as well as an error message.

[00:48:29] And both of those are programmatically associated with the input that they describe. And that hasn't always been true, but because, because we own our own text input, that change was very straightforward from an API perspective, from like an updating the component perspective. And then once you've done that, it's just a matter of being willing to go through every input and, and update them to, to follow the patterns that you've established.

[00:49:00] Jared: Right.

[00:49:01] What's going on at NoRedInk?

[00:49:01] Jared: And so I guess kind of getting to today and what you're building at NoRedInk, uh, what, what's going on there? I know that you published a, a blog post on adding these, uh, these pop-up labels, and, uh, that was really neat to, to see your, your work there and, and thank you for sharing Ellie's in that.

[00:49:26] Uh, but do you wanna talk more about that or anything else that you're excited about?

[00:49:31] Tessa: Sure. Yeah. So that work, um, the, the labels above like words, um, that work is not going to be widely released for a while yet. We are doing user research. Go us. Um, so, uh, hopefully we'll be able to talk more about. Uh, like the, the real use case for that later. Um, but I am very excited about it. I think it's, I think it's gonna be neat.

[00:50:01] And then the other thing that we've really been focusing on within the Accessibilibat team is the, the concept of the highlight and like the act of like annotating text with, with a highlight. Both to get students practicing at tagging, say the claims, evidence and reasoning in a paragraph. And for inline commenting.

[00:50:31] So teachers can, can leave inline comments, like you highlight a sentence and then you say, this was great, um, on a particular piece of a, of student writing. And actually it turns out that we have highlights. All over our site. We have so many different types of, of highlights. It's been a real, it's been kind of a surprise to us cause we thought we'll improve the accessibility of this particular thing.

[00:50:55] And then it turns out that that particular thing is this building block that's, that's used all over our application. Um, but that's been, that's been really, uh, a fun and interesting project because if you think about the naive implementation of a highlight, you do really start with just adding color.

[00:51:15] And that's not enough. You need like the, the information to be conveyed to screen reader users. You need the information to be conveyed with high enough contrast colors in like your, your standard view so that people can like disambiguate between the different colors and disambiguate between the text, the highlight color, and the background color you need.

[00:51:39] Um, to not be using only color as a distinguishing factor, especially if you're thinking about high contrast mode on like a, a Windows machine say, where all those colors are just gonna get removed. Um, so that's been a, a very fun, well it started fun now, it's now, we've been working on it too long, but it's in an interesting project.

[00:52:02] Jared: Yeah, that's the way it goes sometimes. But I think, you know, the way it sounds that by looking at it from a different lens and, and considering these different perspectives, you're gaining a, a deeper knowledge, like you said, of this kind of core piece, uh, that you realize after working on it for a while, um, that, you know, there's a lot to it and, and it sounds like, uh, you're working through it.

[00:52:24] So that's, that's nice.

[00:52:26] Tessa: It's been fun.

[00:52:28] Jared: Yeah. Cool. Do you want to say anything else before we move on to picks?

[00:52:34] Tessa: I don't think so.

[00:52:36] Picks

[00:52:36] Jared: All right, what picks do you have for us today?

[00:52:39] Tessa: All right. Well, earlier I mentioned, um, one of the talks from axe-con on user research. Uh, I recommend axe-con in general, but that talk in particular is good. We also talked about like the legal landscape briefly for the past three years, axe-con has had an actual lawyer do a presentation at, at every event, and, um, she's shared updates on the legal landscape in terms of like what cases are going on, what things matter.

[00:53:09] So if you're interested in the legal side, I recommend that. axe-con has, um, four tracks. So there's like design, um, programs. So if you're interested in like, how do I make this program happen and have it not just be me, there's a developer track and then there's Wild Card. And the Wild Card always has some interesting and surprising talks, so I highly recommend checking out the recordings from axe-con.

[00:53:33] It's free and you just have to, you just have to give Deque your email address. That's it. One email address and you get all the content in the world.

[00:53:42] Jared: All right. Excellent. Any other picks?

[00:53:45] Tessa: Other pick more Elm specific. Shout out to elm-review. As usual, shout out to elm-review.

[00:53:53] Jared: Always. Yes. Awesome. Love elm-review. well, uh, my picks, they start with, uh, we'll do an Elm specific one first. Uh, Aaron VonderHaar's program-test. We mentioned it earlier, I think it's really nice for testing your whole program. It makes it really easy to do, I think. And one of the things I really like about it that ties into our conversation is functions like fillIn require you to have accessible HTML when you're using it.

[00:54:28] And so I like that it sort of helps you build accessible software as you're testing it and you realize, oh, there's not really a clear way to get this thing that I want to test. And so, um, Thanks Aaron for building that and if you are looking to add more robustness to your Elm programs, check out program-test. And the other two are a couple of books. The first one is Lucky Man by Michael J. Fox. I've read this a couple of times now. The first one, uh, first time I read it I was just out of high school and, , it's, it's about his experience with having Parkinson's and about, uh, his struggles with, uh, alcoholism and, and kind of moving toward an optimistic, uh, life and it really made me appreciate

[00:55:30] things and help me see different perspective on life. So, and I, and I reread it recently, uh, just last fall. The other one is called The End of This Day's Business. It is by Katharine Burdekin.

[00:55:45] It was written in 1935, but was published in 1990. So it was sort of discovered later, which, if you are a history buff, if you are interested in things like, what was going on with, uh, the world, particularly Europe in the mid 1930s, this book, uh, speaks about that. It's called a feminist utopia book.

[00:56:13] But the, the premise is that it's 4,000 years in the future and, uh, there's been a role reversal. It is somewhat binary, zero and one, in, in how it talks about it. But the, uh, the primary character, definitely, uh, blurs those lines. But I think that the, the book itself, um, it's not sci-fi, it's 4,000 years in the future, but it's more about the social and political, uh, ideas and, and differences between that world and, and the world as it, you know, as I think the author was, was looking at that in 1935.

[00:56:50] And there, there aren't a whole lot of copies of this book and the cover. It looks really off-putting. I'll, I'll say, um, so if you look it up and you, you think, oh, this looks terrible. I just want to maybe I, I just flipped it open earlier and I wanted to read out just one little bit here. It says, "They were like, people who had with terrific toil got themselves up a precipice to a flat place where they could rest and take their breath, but they couldn't rest because what was on the top of the precipice simply scared them to death."

[00:57:24] And this is talking about, I think the, you know, the time, what was going on 1935 and this, the, the nature of things at that time and, and her reflecting back on it as, as the kind of, situation they were in. And so anyway, I think, if you can find a copy of it, uh, it's definitely worth a read. And that's it.

[00:57:48] Thanks Tessa, for coming to Elm Town.

[00:57:51] Tessa: Thank you.

[00:57:52] Jared: Until next time, peace.

[00:57:54]