My Heart Is In the Right Place, but the DOM Isn't

Hello, everyone. My name's Kyle West. I'm a web engineer and accessibility lead for Family Search. The title of my talk is My Heart is in the Right Place, but the DOM Isn't. One of my primary roles is that I co-author our design systems React library, which is used heavily throughout our products. As an author of a core system that is used by most of our, almost all of our users, I've always felt an added sense of responsibility for building an accessible product that's available to everyone. This has often led me to the ARIA authoring practices guide, which is provided by W3C. It's a wonderful resource for anyone who's trying to build a product that fits industry best practices.

If you've been there before, you'll have no doubt have seen this banner up at the top, which reads, No ARIA is better than bad ARIA. They have a wonderful link that we could go click on and read together if we wanted, but it's very logical and totally explains why that's important. But I've learned from more than documentation. I've had my own life experiences. Throughout my time, I've seen many times in which myself and others have tried to do the right thing, but didn't do it well enough to be effective. I have about three of those stories I'd like to share with you.

The first one to start us off, you've probably heard of spaghetti code and likely with it ravioli code, but you probably have not heard of potato code, which is the title of my first story. To give some context, one thing I do is I meet periodically with some of my blind patrons to understand what their experience is like and identify any issues that they might be facing, elicit feedback. I meet periodically with them. One time, I was meeting with a woman who herself is blind. She works in our support department and she often takes the calls for other blind patrons. That week, she had noticed something that was a little bit off from what she was expecting, and so she wanted to show us what the issue was.

If you're unfamiliar, the way in which a blind user interfaces with a computer is through a tool called a screen reader, which takes the graphical information displayed on screen and then reads it aloud to the user. Then the user has an elevated set of keyboard shortcuts that let them navigate the page. In other words, instead of you yelling at the computer, the computer now yells at you. Well, for this particular case, the issue that our user had found was on a page that looks something like this. It has a heading at the top with some high details about the information on the page, and then a series of main cards containing all sorts of important information, and then a series of smaller sidebar with some smaller card widgets that perform certain related actions to the page. The issue that she wanted to point out to us was at the very bottom of the sidebar section, and as she was navigating to that portion of the page, along the way, about halfway through the sidebar, the screen reader said something that we found very intriguing. It said, Link potato. She just skipped over it like it wasn't a big deal. We said, wait, wait, wait, go back. Did you say potato, or did the screen reader say potato? She said, yeah, it did.

When people ask me about it, I've been telling them that it's not really a potato. It's just a character or something that our screen reader doesn't understand, and so it just gets confused and says potato. But it's not really a potato, so they can just ignore it. Bless her. She had so much trust in us, the engineers, that she assumed that it was the screen reader that was the problem and not our code.

Well, I don't really trust our code that much, so I went and tried to find this immediately. It didn't take me very long to get to this little gem where, as you can see, someone had hardcoded ARIA label of potato onto an icon. If you're unfamiliar, ARIA label is a special attribute that the screen reader uses for us to be able to say, hey, for this portion of the DOM, use the given value to describe it.

So when we got to there with the screen reader, it said potato, which is not really ideal for the situation since it obviously wasn't a potato. Most of the time, an ARIA label is a good thing to have, but in our case, it was just put there superfluously, which gives me the definition of what I now call potato code, which is code that should have never made it past a code review. This is a prime example of no ARIA is better than bad ARIA.

It turns out that one of my close friends, he's the one that wrote this, and had he had done nothing, the screen reader would have simply read this as an unlabeled graphic and then moved on, but no, my friends heard me talk over and over about accessibility and that it's important that we put appropriate labels on icons and images, and so he said to himself, essentially, I don't know what to put here right now, but I'll come back to it later, and then he went along and finished what he was working on, but forgot to come back. A junior dev did the review, it got merged, and then it went on its merry way to patrons.

Luckily, this is a pretty easy fix. The first option we have is to simply provide a legitimate value for the label. This way, the user can, when they navigate to it, they know its relevance and that the screen reader is able to communicate that to the user. You should know, though, that not all screen reader users speak your language, so one tip I have is to make sure that you're translating your labels if your site supports more than one locale. Just to make sure that it's understandable by all the people using your website.

Another option, and this is the one that I think we ended up going with, was to use an attribute called aria-hidden, and in case you aren't aware, aria-hidden is an attribute that tells the screen reader, hey, this portion of the DOM, you can just ignore it for whatever reason, and so the screen reader will just skip over it. This is appropriate to use in cases where the provided element doesn't give any additional value to the page, typically for a decorative purpose, and that's what it was in this case. The appropriate label we might have put on the icon was actually already said in the DOM right next to the icon. It would have been a sibling, and that was already in visual text, and so we decided to hide the icon since it was all inside of a link.

The link was already being labeled with the visual text, which is totally appropriate. I have some lessons learned from this experience. The first one, as this is my intuitive learning of no aria is better than bad aria, had my friend done nothing, then it would have been less confusing than having a random potato in the DOM. Another lesson that's just a good thing that we covered today was that if your product is designed to support more than one locale, make sure that you're translating it. Any labels that you put on, again, because not all people speak your language, and even those that have a need for using a screen reader.

Then it's okay to hide decorative elements if they provide just simple visual value, but nothing that's semantic or necessary to understand your page. Lastly, my advice is that you can avoid potato code by having quality code reviews. It looks good to me. That rubber stamp is not really appropriate for all situations, especially ones that are not understood by everyone. This is a good thing to make sure that you're reviewing and testing your code appropriately.

My next story, I'm calling it Tabindex Everywhere. It takes place at the very beginning of my career back when I was straight out of college, and I didn't know what best practices were. I didn't know about screen readers, that they were a thing, or anything about the APG or WCAG or all that. All I knew was how to write lots and lots of code fast, and that's not always a good thing. One day, I got a bug ticket. It said something defective. We've been getting reports that some patrons have been unable to use the keyboard to navigate on this page, and then a link to the experience. Cool.

Well, I didn't really know what that meant. All I really saw were the words keyboard and navigate, and so I decided to do my own research. I went to my favorite browser. I typed in some garbage to see what would pop up, and then I found this. The first thing that popped up was Tabindex, and it sounded like exactly what I needed. You mean to tell me that there's a magic attribute that if I put on any DOM element, it'll make a keyboard focusable? Cool.

So I did. That sounded like what I needed. I did what any junior programmer who's highly prolific would do. I spent the next sprint putting it on everything. I put it on all the headings. I added it to every paragraph. I put it on list items. I added it to cards. I made every part of a table focusable, and I put it on buttons and links, which already come with Tabindex, by the way. I was just being safe, I guess.

To make sure that my solution continued to work, I made a series of tests to just solidify it. Then I put it out for code review. Now, if it's not clear already, this was a bad idea made by someone who was well-meaning but knew nothing about what he was doing. It's a terrible misguided effort. Tabindex is not accessibility. Actually, my friend sitting next to me was the one who did the code review, and I distinctly remember him leaning over the desk and just looking down at me and saying, Kyle, are you sure about this? Are you sure this is the way that we can make things keyboard navigable?

I just looked up at him and I said, yeah, I think so. He didn't contest me on it. Because he was also a junior, it got merged. Another potato into the ether, if you will. But no need to worry. It wasn't a big potato. It just happened to be that this was on a part of our site that was during a beta period, so our early adopters found it. It eventually ended up getting reverted, and the only thing that was really lost was my team's time. Still not a good thing to have, though.

What I should have done instead was I should have done more than merely five minutes of research. I'd like to imagine that had I done that, I would have eventually stumbled upon the authoring practices guide. As you can see from the screenshot, it has so many details about the proper ways to implement accessible features into your products, including descriptions on keyboard support with code examples. This is what I should have been looking at, not the first coding help subreddit post that popped up.

So my lessons learned from this experience, again, this solidified in my personal history, no ARIA is better than bad ARIA. What I built was very confusing and more difficult to navigate than had I just done nothing. In hindsight, it would have been better off for the user if I would have just been lazy and lied about fixing the bug than had I done what I did. I'm not encouraging anyone to lie about your work, you should be honest. But that's how bad of an experience it was, not just for maintainability, but actually going through it.

The real best practice from this, though, to me, is that I needed to familiarize myself with the best practices. And that includes the reviewer, too. Both as the coder and the reviewer, we have a responsibility to make sure that our users understand or that we understand what an accessible experience is for our users. We need to make sure that we're doing things the right way. Like guessing isn't a viable, feasible option. We need, there are plenty of real resources to help us and we should be relying on those.

This last story is a little bit more serious, if you can't tell from my title, don't make me throw up. At this point in my career, we had been doing accessibility work for a long time. There was a lot of great efforts that were done. Of course, there were plenty of work to still do and a lot of bugs. But overall, the big problems had been solved and I was comfortable with that.

I was feeling like we were in a really great spot. Then one day I got a message that made my heart sink. This was from a patron. And what they wrote was, the problem is that I can't spend hardly any time using the website because it nauseates me. The animations make me dizzy. Please get rid of them. I beg you.

I knew immediately what was wrong. This patron has, probably has, what you would call a vestibular disorder, which is a pretty complex situation. But essentially, what happens is that they're very sensitive to movement and parallax effects and even high contrast colors. Essentially, what's going on is that your visual information that your body's receiving conflicts with the other sensory, in particular, the information coming from your inner ear. Your brain thinks something's wrong, and it makes you nauseous, it might make you throw up.

If you ever experienced motion sickness, like through riding in a vehicle, then you've experienced a vestibular dysfunction. A vestibular disorder, they experience similar feelings but all the time. Not very fun. Luckily, most browsers support a media query called prefersReduceMotion. This exposes the operating system's accessibility preferences so that we can cater to them and adjust our animations as we need to.

The thing was that it surprised me that I got this letter, though, because I thought I'd already fixed this problem. A while ago, we had written code that looked something like this that told our animation library, we use React Spring, it's a pretty great library if you're unfamiliar with it. We were telling the animation library just to skip the animations if the user did prefer reduce motion. This worked when we merged it. But most code eventually regresses, and over time, we lost it. We didn't have sufficient acceptance tests for this particular feature. It ended up slipping through the cracks and eventually made it out to users in a broken state.

Luckily for us, in between the time of it breaking and us learning about it, React Spring had reduced a new hook called useReduceMotion that did exactly what we needed it to, and it works flawlessly. We put that in, and it's been great ever since. For FYI, for your information, there are several kinds of these queries that you could use. You've probably used the prefers color scheme if you've ever implemented a theme for your application. Not many people think of that as an accessibility issue, but it's making the website more comfortable.

Accessibility is just usability for more people. The more comfortable we can make our website, the longer users are going to spend on it, and the better they are off for it. These aren't even all of them, by the way. It's just what I wanted to fit on the slide. We know about prefersReduceMotion together here. There's also contrast and transparency that you can make queries for and be able to make the experience more comfortable. You don't have to use all of them for all experiences, but making it better off for your user is never a bad thing. We're now prepared, as far as lessons learned, to amend our mantra for the day, which is that no ARIA is better than bad ARIA, except if you do nothing and it makes your users throw up.

It's generally considered bad practice to have your users associate feelings of nausea with your product. It's not really good for business. We can honor our DOS preferences to avoid that. If we do so, the users, again, can spend more time on the website, and then all the benefits that come from that.

The biggest lesson I learned from this is that I needed to have more inclusive acceptance tests. Had we caught it earlier, it would have been better off. The user would have never gotten nauseous from using our product, hopefully. Then we could have avoided the whole situation had we just had better tests.

Sorry, by the way, if that was you. I feel bad that we ever got to that point. Well, that's about all the time that I have for stories today, but I wanted to leave you with this quote. It's from one of my personal heroes, Fred Rogers. He said that human beings are far more wonderful than machines. To me, this is a reminder that human life is incredibly unique, and that's what makes it beautiful.

There are a lot of people whom the world is not built for them, and they have to live in it anyway. Please consider the potential that you have to show love to others and reduce people's burdens, at least in the interactions that they have with your products. You have a tremendous capacity to do good here, so please do. Thank you so much. Again, my name is Kyle West. You can find me on Blue Sky or LinkedIn under KyleWestCS. You can also find these slides on my website, kylewest.dev, slash slides. Thank you again. It's been a pleasure. Appreciate you.