Hello everyone! My name is Kyle West, I'm a Senior Web Engineer & Accessibility Lead for FamilySearch International. One of my primary roles at FamilySearch is that I co-author our Design System's React library - which is used heavily throughout our products.

As an author of a product that faces every patron who comes to our site, I've always felt a sense of responsibility to ensure that accessibility is built into our shared components. This often brings me to the ARIA Authoring Practices Guide (also known as the APG) to make sure that we are following current best practices. This is an incredible resource for anyone wanting to make a product that fits industry standards. I've spent so many of my days on this site and I can't recommend it enough.

If you've ever been to the APG, then you have, for sure, seen this banner which reads: > No ARIA is better than Bad ARIA. As you can see, there is a link here that leads to a well thought out and logical article which alone should be enough to persuade you this is true. But instead of reading that together, I am going to show you some real-life horror stories that demonstrate why it's true.

To start us off, you may have heard of: - Spaghetti Code But have you heard of...?

To start us off, you may have heard of: - Spaghetti Code - or perhaps, Ravioli Code But have you heard of...?

... Potato Code? Well, I discovered it a little over two years ago. To give a some context: one thing we do at FamilySearch is meet with a half-dozen or so of our Blind patrons regularly to elicit feedback and identify issues they face. In one of these meetings, we were speaking with a woman who works in our support department and often takes the calls to assist other Blind patrons. That week she started seeing a new issue, and so she shared her screen so that we could see (or hear*) what was happening.

In case you aren't aware, the way a Blind user interfaces with a computer is via a tool called a "screen reader" that, simply put, takes the graphical information displayed on screen and reads it audibly to the user as they navigate.

The issue she found was on a page with this kind of layout: - A heading with high level details about the contents of the page - A main section with cards containing all sorts of important data points - And a side section with smaller card-widgets to perform certain related actions to the page

The issue she found was at the very bottom of the sidebar. But as she was navigating her way over to it, we heard the screen reader say something intriguing...

Right about here it said...

"Link, Potato." And she just skipped over it like it wasn't a big deal!

We interrupted her and said, "Wait, go back. Did that say 'potato'?" She said: "Oh yeah, it did. When people ask me about it, I've been telling them it's just a character that the screen reader doesn't understand. So it gets confused and says 'Potato' - but it's not really a potato so they can ignore it." Bless her! She had so much trust in us that she assumed the screen reader was the problem and not our code.

I immediately started looking through the code base, and eventually found this little gem. As you can see, someone hard-coded an `aria-label` of "potato" onto an icon If you are unfamiliar, aria-label is a special attribute that tells the screen reader to ignore all other text it sees and use this value instead. Most of the time that's a great thing to do to make something clearer for the user. But it can go wrong if you don't use it right. By the way, I know which dev did this. It was my best friend.

This is what I now like to call, "Potato Code" - which is any production code that should have never made it past a code review. Just curious, how many of you have ever deployed Potato Code? <raise hand> I'd probably need a shipping freighter to hold the number of potatoes I've tossed into the void over my career.

But this is a prime example of "No aria is better than bad aria" Had my friend done nothing, the screen reader would have simply read this as "Graphic" and moved on. But no, my friend has heard me talk over and over about accessibility, so he said to himself "Kyle's told me that images should have appropriate labels; I don't know what to put here right now, but I will come back to it later." And then he went along, finished what he was working on, but forgot to come back. A junior dev did the review, it got merged, and it went along it's merry way to patrons. Luckily, this is a really easy fix

The first option we have is to simply provide a legitimate value for the label. This way, when a user navigates to it, the screen reader can announce that label so the user understands it's relevance. You should know, though, that not all screen reader users speak your language, so if your site supports more than one locale, be sure to translate your strings like you would in any other part of your code.

Another option, and the one I think we ended up doing, was to replace the `aria-label` with `aria-hidden`. This tells the screen reader that it can ignore this part of the DOM altogether. This is appropriate to use in cases where elements provide only decorative value, but no real information is displayed with the element. Or this may also be used to hide redundant information that would be distracting for the user. Note that in this example I also removed the `role` attribute because it doesn't make sense to add a role on an element that the screen reader won't use.

And in this one example we already learned several best practices! If your remember the APG warning from earlier, "No ARIA is better than bad ARIA". This is our first and most important best practice. Also, if your product is designed to support one more than one locale, you should translate your labels to make sure yor product is understandable for all of your users. As a tip, on deliberate occasion, it's ok to hide decorative elements - as long as it makes your application clearer and less confusing. Lastly, avoid potato code - make sure you give enough time to follow good processes. It'll pay off one day.

This next story is more serious. At this point in my career, I had been doing accessability work for several years, and was feeling pretty good about the state of things. We still had bugs of course, but much of the hard work for making our web products accessible was done, and I was comfortable with that. Then one day, I got a message from a patron that made my heart sink.

What they wrote was... <read slide> I knew immediately what was wrong. This patron probably had what's called a "Vestibular Disorder", which makes them very sensitive to movement, parallax effects, and even high contrast colors. It's a pretty complex situation, but the simplistic explanation is that the movement observed by your eyes conflicts with the sensory your body (in particular, your inner ear) is experiencing; your brain thinks something is wrong, and it might make you throw up. If you've ever gotten motion-sick from riding in a vehicle, then you've experienced a vestibular dysfunction. Those with a Vestibular Disorder experience similar feelings, but all the time. Not fun.

Luckily, most browsers support the `prefers-reduced-motion` media query. This is the best mechanism to get the user's accessibility preferences from the Operating System, so that you can cater to them.

What surprised me is that, at one point, I did solve this problem. A long time ago we added code that looked a little something like this, where we listened for changes to the media query and then notified our animation library to skip animations if the user preferred reduced motion. (you can see we use ReactSpring - great library) And this worked. But then time went on, and eventually it stopped working. And it stayed that way until I got that message. Exactly why it stopped working is a very long and un-fun story, so I'm gonna leave it out. Lesson learned though, if we had better testing we would have caught it sooner.

Luckily for us, in the time between this breaking and us discovering it, ReactSpring had released a custom React hooked called useReducedMotion, which did exactly what we needed it too. And it's worked flawlessly ever sense. So it was a quick fix after we discovered the problem.

FYI, there are actually several kinds of these queries that can make the experience more enjoyable for your users. You don't have to use all of them for every experience, but understanding them and your user's needs can make the experience more comfortable.

So now we can amend our lesson from earlier: "No ARIA is better than bad ARIA", except if you do nothing and it makes people throw up In general, best practice is that it's not a good idea to have your customers associate your website with feelings of nausea. That's just bad for business. And another lesson is that you should have more inclusive acceptance tests. Had we done that at the time, then this problem would have been caught a lot sooner, and maybe that patron would have never written us asking for help. Sorry, by the way if that was you.

One last story. Back when I was straight out of college, I didn't know about best practices. I didn't know about the APG, or WCAG, or even that screen reader's existed. All I knew, is how to write lots and lots of code (not always a good thing).

Well one day I got a bug ticket. And it said... <read slide> Cool, I didn't really know what that meant.

All I really saw were the words, "keyboard" and "navigate", so I did my own research.

I went to my favorite browser.

And I typed in some garbage to see what I could find.

The first thing that popped up was tabIndex. You mean that there's a magic attribute that if you put it on any DOM element it, that will make it keyboard focusable? That sounded like exactly what I was looking for! So I did what any prolific junior programmer would do - I spent the next sprint adding tabIndex to everything.

I added it to headings

I added it to every paragraph

I put it on Cards

I made every part of tables focusable

I even attached it to buttons and links - just to be safe.

And I wrote unit tests to make sure it stayed working

Now, if it's not clear already - this was a bad idea made by someone who knew nothing about what he was doing. Well meaning, but misguided effort. And because the person reviewing my code was also junior...

... It got merged! But don't worry, this technically wasn't potato code. It just happened to be that this page was in a beta period and only our early adopters saw it. It eventually got cleaned up and the only thing that was lost was my team's time.

What I should have done instead, was do more than merely 5 minutes of research. Because had I just kept looking, I would have likely stumbled upon the ARIA Authoring Practices Guide. As you can see from this screenshot, they have so many details on the proper ways to implement accessible features.

Including details around keyboard support with code examples! This is what I should have been looking at, not the first reddit r/CodingHelp link that popped up.

Again, this story solidifies the "No ARIA is better than bad ARIA" concept. But the real best practice we get from my story is that you should familiarize yourself with the best practices. As both a reviewer and a coder, we have a responsibility to our users to understand what an accessible experience is. It's ok to take time to make sure you are doing things the right way. And there are plenty of real resources to help you.

Lastly, life is incredibly unique, and can be hard for so many people in the world. Please consider the capacity you have to show love to others and reduce everyone's burdens - at least in your interactions with them, or their interactions with your products.

I'm Kyle West. You can find me on Twitter, BSky, and LinkedIn all under the same handle. You can find my slides on my website. It's been a pleasure, Thank you!

TODO: ask if they want me to keep the presenter info slide

TODO: make sure that the links go to the specific presentation version for this conference