Public Speaking

Welcome to TN Inspire at TLCC 2016. So the picture you see here is a picture of me wearing a sweater that I designed and knit. And I don’t mind being proud of that. And if I was going to ask you to describe this sweater, you might say this is a gray men’s zippered cardigan with a red stripe, probably about as small.

It’s a medium, but we’ll say it’s a small. And that’s correct. If I said to you, where does this sweater begin? That’s a weird question.

It doesn’t make sense right away. A sweater is an article of clothing. It’s something you wear. It doesn’t have a start or a finish.

Unless we think about how it was knit, how it was designed. In which case, the sweater begins at the neck, where we cast on the stitches. We knit down through the chest and the shoulders, at which point we separate the stitches for the arms. Then we finish the rest of the body.

We knit the hem. We fold the hem under. Actually, the folding hem under comes later. Then you pick up the stitches for the left arm, knit the left sleeve, bind off at the cuff, pick up the stitches for the right sleeve, knit down to the right cuff, bind off there.

Pick up the stitches for the collar, knit the stitches for the collar, bind off there again. Then you fold over the hem, sew that, sew this. Drop in the zipper, sew in the zipper, bada boom, bada bing, your sweater is done. Now the interesting thing is a website is exactly the same thing.

A website is not a three-dimensional object like an article of clothing, but it is a multi-faceted, multi-dimensional thing that people come at from different directions and see from different sides. Like the sweater and the sweater pattern, it is also composed of a number of linear sequences that are arranged with a very similar kind of logic. When I realized this, it helped me understand two things. One is it helped me understand why both knitting and coding scratch the same mental itch.

If you’re a coder, you understand what I’m talking about. If you’re a knitter, you really understand what I’m talking about. The other thing it helped me understand is why am I such a control freak? Because what I realized is I want as much control over the hand-knit items that I produce.

I want to be able to influence them as much as I can, and you can’t control these things. The model in this picture is my seven-year-old daughter, speaking of things that you cannot control. But it is through the linear processes that I try to exert that control by understanding all of the variables, by getting a grip on all of the linear sequential things that come together to produce these non-sequential three-dimensional things, I feel that I can influence the ultimate outcome of these things, which is, of course, completely false. We can’t control these things once they’re out in the world.

With a website, we have Google Analytics, and we can look at behavior and where people click and how they leave, but we don’t really understand what’s going on perceptually in their minds. We don’t have that. And with hand-knit items, we don’t really know, or I don’t know, what happens to the hand-knit items I give to people. They might be in closets getting eaten by moths.

So this is home brew, which I also make, and this is a very similar thing, a linear process that produces a substance that is not only hard to control once you consume it, you are out of control. And this is sourdough bread, wild yeast. Once you get that wild yeast into your recipe, into your kitchen, you have surrendered control. Wild yeast does not behave like store-bought yeast.

You try to get a hold of the temperature and the variables, but at a certain point, the bread’s going to do what it’s going to do. And this is really how this thing ought to be. The things that we produce with our creativity need to retain that kind of wildness. They need to be out of our control.

And that point where the sequential processes meet the moment that it’s released into the world and it is not in control anymore, that’s for me where the creativity and the volatility really, really is. And the way I get into that is by asking that question that I asked at the very beginning. Where does it begin? Because that is the gate, that is the door that opens up the mystery to creativity and to the wildness that is in all the things that we create.

Thank you very much. Thank you.

Hello everyone, and welcome to Accessibility Talks. This is the monthly virtual meetup where we chat about digital accessibility, inclusivity, and usability. Each month we invite a speaker to present a topic, and afterward we invite the community to ask questions and participate in the discussion. I am today’s host, Andrew Olson.

I go by Andrew or Andy. My pronouns are he, him. I’m a friend and software engineer at Principal Financial Group. I enjoy front-end development and the challenges of making the web accessible for everyone on any device.

I’m thrilled to be part of the Alley Talks team in hosting today’s discussion. Today we will hopefully be having a live transcript. On your screen there is a link and also a QR code. We’re a little delayed, but we’re hoping to correct that and have the live captioner join as soon as they can.

But in the meantime, I’d like to move on and we will let you know once that transcript is available via the chat. That said, I want to take a moment to remind folks that our group seeks to provide a friendly and safe environment. We require all participants to adhere to the Accessibility Talks code of conduct. This applies to all community interactions and events, and this also applies to verbal questions as well as chat and text channels.

This code of conduct can be found on our website, AlleyTalks.com. That’s A-1-1-Y-T-A-L-K-S-dot-C-O-M. All participants should be able to engage in productive dialogue and should share and learn with each other in an atmosphere of mutual respect. You have any questions for our speaker today? Please post it.

You can post it on X with the hashtag of AlleyTalks. Again, that’s hashtag A-1-1-Y-T-A-L-K-S. Or if you’re participating in the live chat, you can add your question to the YouTube chat window, and we’ll get to it at the end of the discussion. So with that, let’s get started. I’d like to introduce you to today’s speaker, Jesse Loesberg.

His pronouns are he, him. He is an award-winning web designer, developer, and IAAP certified professional in web accessibility with 15-plus years of experience designing and building WordPress, Drupal, and standalone websites. He’s currently a web developer at University of California, Berkeley Library. And a fun fact about Jesse is that he’s been an avid knitter for over 20 years and has just restarted piano lessons after a 40-year hiatus.

So my first question to you, Jesse, is do you have any examples of your knitting work around you? Jesse Loesberg Sure. Not the most exciting one. This just happens to be on my desk, but this is a hat.

I live in Oregon. My desk is by this sliding screen door, so it’s cold where I sit. So I generally have a hat on my desk. And not only did I knit this hat, but I designed this hat.

It’s one of my first designs for bald heads. Yeah, sure. Purely coincidentally, I had one of my own. I guess that’s probably more common than I think.

That’s great. Also, my next question is, is there a song or an event that inspired you to pick up the piano lessons at this point in your life? Oh, that’s a great question. So many songs.

Mostly, I really just wanted to get back to music, and I wanted something in my life that I could really, really focus on, that when I was working on it, it would kind of just make the whole world go away. But I’m embarrassed to, or maybe shouldn’t be embarrassed to say that I do have an unabashed love for Phil Collins that I generally keep secret. But he’s got, some of his piano work is actually really spectacular. So there’s a few old Phil Collins songs that I really wanted to be able to play.

Not ironically, although to most people, I would say that I was playing it ironically. That’s, you know, you got to find that and play that. That’s outstanding. As a musician, I grew up a drummer, then to bass and then guitar.

So I love to play all the things, and I love music. So that is outstanding that you’re picking it up and playing what you love. So do not be afraid to Phil Collins in front of people. If they think it’s ironic, that’s on them.

You play what you need. I appreciate that. All right. With that, I also realized I missed some slides because I was too excited about going through the introduction.

I just want to call out really quickly the Alley Cat Club members. So we do have the Alley Cat Club. So just wanted to bring that back up. Apologies.

So we want to thank you for the Alley Cat Club members that give donations and make this possible. So again, today, being able to put on this live stream, to have a wonderful website, and to have live captioning when available. Thank you to Carrie, Simo, Rajab, myself, I’m an Alley Cat Club member. You can be too.

Alyssa, April, and Steve Woodson. So if you want more information about that, you can go to our website. So thanks for letting me backtrack a little bit here, Jesse, but very important, because that’s how we’re able to bring you and have you come on and bring this wonderful topic. So with that, I’ll hand it over to you.

I’ll go off the screen here and we’ll collect some great questions in the YouTube chat and take it away, Jesse. Great. Thank you, Andrew. Like Andrew said, my name is Jesse Loesberg and my pronouns are he him, and I’m a web designer and developer with the UC Berkeley Library.

UC, for those of you who may not know, stands for the University of California. And today we’re going to be talking about the accessibility mindset. And before I jump in, I’m going to give a little bit of background on my own personal experience with disability. I’ve stuttered ever since I could speak, really.

Stuttered my whole life. It does tend to go away or fade to the background when I do public speaking. It’s one of the reasons why I love public speaking so much because I do get to experience the feeling of fluid speech, which doesn’t happen too much in other parts of my life, but that’s been an aspect of my life as long as I can remember. Also, about four and a half years ago, I was in a pretty serious bike accident.

I was hit from behind by a car. I was wearing my helmet, but I still sustained a traumatic brain injury. And although my body was more or less fine after that, I do have some mild cognitive issues as a result and also seizures. So, my experience with disability has expanded in recent years.

But to jump into the talk, I’m going to start with stuttering and my speech. And the first thing I’m going to show you is this. This is a telephone. This is an old-style red telephone.

By the way, for the folks in the audience who may be visually impaired, I’m going to be describing most of the images that I’ll be showing. This is a very old telephone. It’s got a handheld receiver that you lift off the cradle. It’s got a dial that you actually have to put your fingers into and turn.

Depending on your age, you may be looking at this and having a very tactile memory of what it felt like to turn that dial, to actually force that dial back and feel those clicks as they turned. So, this is the kind of telephone that I grew up with. But I’m going to pose a very specific question about this telephone. And that question is, who is this made for?

Who is this telephone made for? And there’s a technology-related answer to that question. And the answer is, it’s for people who want to verbally communicate with somebody who also has a telephone who is not physically present. Simple answer.

You want to talk to someone who isn’t there who also has a phone. You pick up this phone, you dial the number on the phone, and you talk to them. And that answer still applies to our phones, even though phones have changed a lot since the days where we used this kind of phone. So, that is an answer to this question, who is this made for?

But I’m going to ask another question that expands the way we think about who this phone is made for. And that question is, who is able to use this? And that changes things a bit. The people who are able to use this are people who can use their hands and their fingers, because you need to be able to use your hands and your fingers to pick up that receiver and hold it to your ear and your mouth.

You need to be able to use your fingers to turn that dial, which means you need to have the dexterity to use the dial, and you need to have the hand strength to use the dial. If you remember these dials, it took no small amount of hand strength to do. It is also for people who can see. You need to be able to see the numbers and the letters so you know what number you are dialing.

It’s also for people who can hear, because you are holding this receiver up to your ear, and you need to be able to hear the voice that is coming through on the other side. And it’s also for people who can speak. The other part of the receiver is, of course, the microphone. You are holding it up to your mouth, and you are speaking.

So who is able to use this? People who can use their hands and their fingers, people who can see, people who can hear, and people who can speak. So let me ask, who is this for? It’s not really just for people who want to verbally speak to somebody who isn’t physically present in the room and also has a telephone.

It’s also people who match this criteria. And for me personally, the speaking part was particularly challenging. So from my perspective, this was also for people who were fluent speakers, because unlike public speaking, the telephone has the opposite effect on me. When I pick up the telephone, my speech gets much, much, much worse.

My repetitions get more intense. The blocks, as in when I’m trying to say a word and can’t say it, become much more intense. Saying my name for all kinds of mysterious reasons that I don’t understand becomes much more difficult on the phone. So this made life pretty difficult for me as a young person.

My first job out of college was in a bookstore, and interacting with customers in person was not a big deal. But people would call on the phone, and the phone would ring, and my boss would say, Hey, Jesse, go pick up that phone. Which for most people, no big deal. But for me, that generated a lot of anxiety because I really didn’t know how it was going to go when I picked up that receiver, because the phone, I didn’t think of it this way at the time, but the phone was not built for me.

The phone was built for fluent speakers. And what that meant was, when my boss said, Hey, Jesse, go pick up that phone, I would look at the phone and see this. And what this is, is a hand-drawn rendering of some kind of medieval torture device. It is a chair with spikes on it.

There’s our restraints for the wrists. There’s some kind of device at the ankles that I imagine looks like propellers. It’s probably supposed to inflict intense pain on the ankles. And then there’s another roller with spikes that I don’t even know what it does, but I’m sure it’s super painful.

And this is what telephones were like for me. I did not like using telephones. I did not want to use the telephone. But I also felt like I personally was falling short by not being able to use the telephone.

I didn’t have the frame of mind that I have now, which is, I was not feeling the technology. The technology was failing me. This is how I think of these things now, and how I’m going to encourage everybody, all of us, to think about technology, that the people who are not able to use it are not failing it. It is probably failing them.

So I’m going to have us ask the question, who is this made for about another thing? Things that most of us probably use every day, and you are probably sitting in front of right now. This is a picture of a desktop computer. There is a flat screen monitor, and a mouse, and a keyboard.

So when we ask the question, who is this made for, the initial technology-related answer, like the telephone, is this is made for people who want to send email, use the internet, do word processing. I don’t think we can say the word word processing anymore. I’m probably dating myself with that phrase. But think about all the tasks that people do on a computer.

You’d think this is for people who want to do the things you do on a computer. But let’s ask that next question, and ask, who is able to use this? And again, we get a different perspective on this piece of technology that we use every day. The screen is for people who can see, who are able to perceive color, and also read.

It’s also for people who can use their hands and their fingers. The mouse, you need to have use of your hand, and your arm, and the dexterity to use the mouse. Same with the keyboard. You need to be able to use your hands.

You can do it with one hand, but a keyboard like this is really built for people who have full use of both their hands, full use of their fingers, generally all ten fingers, and the dexterity required to use that keyboard. So this again, with this question, becomes a very different thing. This computer, as it is constructed here, as we are looking at it, is really only for a subset of the human population. There’s lots of people who don’t meet the criteria required to use this computer, which is how we get into what is generally referred to as assistive technology.

As assistive technology, as we generally think about it, as most of y’all watching this probably know, is technology that helps people who don’t match this criteria we see here to still use the computer. And here are some examples of assistive technology. There are four pictures here. I’m going to describe them in clockwise order from the top left.

In the top left corner, we see a Braille screen, a Braille reader. A Braille reader is something that hooks up to your computer. It has a set of spaces with little holes on them. Little pegs come up in the holes that create Braille characters that allow Braille users and visually impaired users who read Braille to perceive what is on the screen through their fingers line by line.

Continuing on in the top right, we have a single-handed keyboard. This is a keyboard that has all the functionality of what we would call a standard keyboard, but easily accessible by only using one hand. On the bottom right, we have a picture of a person sitting at a desk with a computer screen on it. There is no keyboard.

They are sitting in a chair with a lot of assistive devices on it. You can’t tell from the picture necessarily, but what is being used here is eye tracking. This is a computer that uses eye tracking to use a mouse cursor based on where a person is looking at the screen. And then continuing around in the bottom left, we have another picture of someone sitting at a computer with their finger pointed at the screen.

They do have a keyboard present, but they also have a microphone. And again, you can’t necessarily tell from the picture, but this is a picture of someone operating a computer with voice commands. Voice commands are a lot like keyboard commands. If you are someone who uses a keyboard entirely to access the computer without a mouse, voice commands perform the same actions that keyboard commands do, but with the voice instead of with a keyboard.

So these are examples of assistive technology that people with certain disabilities would use with a computer. And that is generally how we think of the term assistive technology. It’s for a very specific group of people, people with disabilities, to do a particular task. But I like to try to broaden our sense of the term assistive technology beyond how it’s generally used.

Now, I wear glasses. I’m wearing glasses right now. There are probably many of you watching this presentation right now who are also wearing glasses. And if you are a person wearing glasses who would not be able to perform certain tasks without your glasses, like reading or driving or anything, if your level of visual ability is such that you really couldn’t conduct the basic activities of your life without your glasses, guess what?

Your glasses are assistive technology. And generally when we think of assistive technology, we think of the things that are on my screen right now, the things that I just described. But really anything that helps you perform a basic life activity that you would not be able to perform unless you had that thing, that is assistive technology. And thinking of it that way really helps us to broaden our concept of how technology serves people and who it is serving.

Because we generally think of people with disabilities as a category of people. And legally it is a category of people, and there’s a medical aspect to that category of people. But really technology is designed to serve everybody. It is designed to help everybody do certain activities in their life.

And some of the activities that helps us do are things that are not basic life activities. But a lot of them are, or thanks to our smartphones, they have become basic life activities. But technology is meant to serve everybody, regardless of whether you exist in the category, the cultural category of disability. So when we ask the question of any piece of technology, who is this made for, and we ask this about the technology that we create ourselves, whether you are creating a device, whether that is your job, or whether you’re responsible for the front end of a website, or the back end of a website, or working on an app, or whether you’re responsible for UX and visual design, when you ask the question, who is this made for, the answer is always everyone.

The things we build are for everybody. And in a perfect world, that’s how it would always be. But as we know, since many of us are involved in the world of digital accessibility or accessibility in the built environment, a lot of the things that get built and the technology we create don’t turn out that way. There end up being large groups of people that can’t use the things that we build, simply because of the frameworks that we carry around with us in our minds, in our lives.

And that doesn’t mean that we are bad people. That doesn’t mean that we have done something wrong. That’s just how we were raised, the environments that we grew up in, and how we think, which is perfectly natural. So the way we use and create technology is informed by our life experience.

It’s informed by our economic background. It’s informed by our sexual identity. It’s informed by our racial and or ethnic background, by our level of ability or disability. It’s informed by where we grew up and where we live and by individual life experiences.

These are really all the things that make up who we are. And these are the things that create our mental framework. And these are the frameworks that we bring to our work and we bring to our jobs and that we bring to the technology that we build. And again, there’s nothing wrong with that.

This is part of being a human. But one of our jobs as people who create technology that are used by other people is to recognize our own mental frameworks, to identify the things in our lives that have contributed to that mental framework, and then to step outside them. So in order to create technology that is truly for everyone, we need to step outside our own mental frameworks. And I’m going to run through a few examples, which may be familiar to all of them, of what happens when we do not do this work.

When software or technology finds its way out into the world and gets used after a process that did not involve reflection about what your life assumptions were. So this is a screenshot of a landing page from medium.com and an article from there. The headline is bad form design. First names must be at least four characters.

So that requiring on a form that someone is going to use, that first name or last name or any part of the name be at least four characters, that’s when it is used. It’s often regarded as a security feature. The assumption here is that most people’s names or the assumption is that all people’s names are going to be more than four characters. Obviously, that’s not the case.

There’s lots of people in the world whose names are less than four characters. There are also entire groups of people. For example, Asian people whose names when they are transliterated into English are less than three characters. Kim is a very common Korean last name.

That is an entire group of people who, when they tried to submit this form, would get an error, would be informed that they were not completing this form correctly. So that’s an entire group of people who would not be able to use this form, who would encounter a barrier and would have to move on to something else, use a different product, or if this was providing a necessary service, they would not even be able to use this service. Also, any Asian name that’s being typed in this form is already transliterated because it’s probably the case that most forms like this don’t accept Asian characters. That’s a whole other talk.

Here’s another example. This is a landing page from motherjones.com. The headline of this article is, Hey Siri, why don’t you understand more people like me? This article is about how Siri has trouble people with different accents.

That includes regionalisms right here in the United States, but it also includes obviously people from other countries who are speaking to Siri. This is generally because the people working on the software were testing the software with people who were just like them, who spoke just like them, and sounded like them, and likely did not expand the user testing to people with accents who are not like theirs. Again, this produces a significant barrier to people who are from other countries, even if they speak English. People from the regional south and the United States experience this all the time with technology that’s created by people from the west coast.

This is a significant barrier to using Siri on their phones, to using any voice-activated software when it is developed by people who didn’t go through the reflection process of who else is going to be using the technology. These are the barriers that have resulted. My third and final example of this, this is an article from Scientific American. The headline is, Police facial recognition technology can’t tell black people apart.

Well, you may have seen this in the news or a related story. A lot of technology like this is created by people who are white, and if they are only testing on themselves, or people like themselves, then it is likely that their facial recognition technology is not going to work for darker skinned people. And then when this technology makes its way into public use, especially when it starts to involve the police, this can have very significant social consequences, which I’m sure everyone on this call is familiar with. So I’ve ordered these examples from one with the sort of like most minimal social impact to the most significant social impact.

So when I say that people who work on technology need to go through a refraction process about what their own life experiences and what their framework is and what assumptions they’re bringing to their work, this isn’t just me thinking about what is the best, most awesome world we can live in and how we can all be happier. We’re actually talking about actual impact on people’s lives and people and consequences that can actually be physically dangerous and in some cases fatal. So what I’m talking about can be a life or death situation. I’m not really trying to inspire fear here, but I would like to call out that this process that I’m talking about us going through is really essential to changing the state of our world, because when we don’t go through this reflection process and we create technology that gets broadly used, it can have very significant consequences.

So for a lot of kinds of technology, like when I use the term technology broadly and talk about glasses like I did before, it can be a very loose and vague thing to go through the process of how do I make this accessible to everyone. But I am a web developer, I work on websites, I’m sure there’s a lot of web folks in the audience right now. We are very lucky enough to have something called the Web Content Accessibility Guidelines, or WCAG for short. And quite briefly, taken from the w3.org website, WCAG was developed through the W3C process in cooperation with individuals and organizations around the world with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.

WCAG is an evolving thing, it is a living document, but it does aim to do this and it does a pretty good job. So what is WCAG at the nuts and bolts level? I’m not going to do a super deep dive because again, you could do a lot of talks on WCAG, but I’ll give an overview. WCAG is a set of four overarching principles.

It is a set of guidelines for adhering to the principles. It provides testable criteria for meeting the guidelines and it provides techniques for meeting those guidelines. And again, I’m not going to dive in, but I will provide what those four overarching principles are. The principles are all web content should be perceivable by everyone.

Everyone who is using your app or your website should be able to perceive what the website is providing. All of the functionality should be operable by everyone. Everyone should be able to use your website. They should be able to use your navigation menus.

If there is a form or if there’s any kind of user interaction, everyone should be able to operate that interaction. All content should be understandable by everyone and all content and functionality should be robust. And that last one means that the website or app should be usable regardless of what browser is being used, regardless of what platform you’re on, whether you’re on a phone or a desktop or a tablet. All content and functionality should be usable in all those environments.

It should be fully robust. So we can treat the WCAG guidelines as a set of boxes to be checked. And if you do that, you will go a long way towards creating a fully accessible website or a fully accessible app or experience. But we can also use WCAG to change the way we think, which is that extra step that I think we should all use WCAG to take.

We can take those WCAG guidelines and not just check off the boxes, but we can also use the WCAG guidelines to ask questions about why we are applying these principles and who we are trying to serve by applying these principles. So to illustrate that, I’m going to turn to my own institution, the UC Berkeley Library. UC Berkeley Library’s mission statement is, we help current and future users find, evaluate, use, and create knowledge to better the world. So any technology that I work on, and I’m responsible for all of UC Berkeley’s public facing websites and a bunch of the internal websites too, when I’m working on the website, when I’m able to pull my nose up from whatever problem I’m trying to fix, this is where my sight lands.

This is where my vision lands. This is the ultimate goal of my job, to help current, future users find, evaluate, use, and create knowledge to better the world. So the technology that I work on needs to serve this group of people, which is, of course, as I’m always saying, everybody. So to focus in on this, I’m going to take a look at our navigation menu.

Over the past few years, we’ve gone through a rebuild and redesign process. We launched a newly designed and fully rebuilt website in May of 2022, had many, many improvements. The first thing we’re going to look at, though, is the navigation menu from our old website. This is the header and navigation menu from the website that we replaced in 2022.

And I’m going to ask this question that I’ve asked about the things we’ve looked at so far, which is, who is this made for? Well, this navigation menu had a bunch of issues. For one thing, these were, I don’t have a live example of this, which I think is good, but this is not live anymore, this site. But I’ll verbally walk you through what some of the accessibility issues with this menu were.

The menus that have drop-down arrows were hover menus. I am opposed to hover menus for multiple reasons. Accessibility reasons are one of them. But you hover your mouse over them, and these gigantic boxes would drop down.

And those menus were only accessible by mouse. If you were using a mobile device on which you have to tap, or you were using the screen reader options that are on offer on mobile devices, these hover menus were not accessible to you. Not only that, the hover menus were gigantic and created what I call, and I think are generally called hover tunnels, where you are required, if you want to get one of those links that are on the menu, you have to move the mouse into the menu. If you go off the menu, it disappears.

It was just an overall, like, horribly frustrating experience. If you were a keyboard user and you were using the tab key, you could also not get the drop-down menus to show up. However, if you were tabbing through it, the links that were in those drop-down menus were still accessible by the keyboard. They just didn’t show up.

So, you would be tabbing through, and your focus indicator, it would just disappear, and you would be tabbing that little bottom area in the bottom of most browsers that shows you what URL you’re going to go to when you click. That would still change, but nothing on the screen was changing. So, this menu was a block for screen reader users, people who had a hard time using their mouse, and for keyboard users. It is also very difficult for users with some visual impairments, because the color contrast of this menu does not clear color contrast requirements.

This top level wasn’t super bad. It didn’t clear the guidelines, but the drop-down menus, which, again, you’re lucky enough not to have me show you, the contrast of those was not great. So, when we asked the question, who is this made for, the answer we really get when we take all these things into consideration is, this navigation menu was really made for non-visually impaired mouse users with a high cognitive threshold. The cognitive threshold part relates to the fact that some of the drop-down menus had many, many links in them.

Using the libraries menu when you rolled over that, at the time this website was live, the UC Berkeley library system had 27 libraries in it. So, 27 links would appear, very, very tiny. Cognitive issues are one of the issues that I confront in using websites. I would not be able to use that menu now after my accident.

That drop-down would appear with all those links on it. I’d say, nope, and I would move away, and this would not be a menu that I would be able to use. So, all this, of course, raises the question of how did this menu get this way? How did this website get launched with a menu like that?

Well, it’s because the designers and developers, one, were not visually impaired, so they themselves did not need to take this into consideration. They were able to use a mouse, so they were mostly testing with a mouse. They weren’t doing just keyboard testing, and they weren’t testing with a screen reader. They also inherited a navigational architecture that reflected the organization, and what I mean by that is, and I’m sure many of you have experienced this.

I have experienced this in other roles and other websites as well. If there isn’t a reflective process about who is using the navigation menu, and who the audience is, and who the navigation menu is designed to serve, then your navigation menu will default to the structure of your organization. It’s just a natural thing. I’m sure all of us have come across navigation menus on websites where you’re like, I don’t understand why this menu was built this way, and if you think about it, you realize this is the structure of the organization that you’re looking at, which only serves people in the organization.

It doesn’t serve the public. So, since our mission statement at the library is to help all users access knowledge, that navigation menu really looked more like the organizational structure of the library, and was not made for users. So, if you are a user with a disability trying to access this nav menu, you’ve got a really high bar to clear. Now, again, our developers were not bad people.

The developer who I have worked with for the last few years who recently retired did work on this menu. I had his permission to go into this, because he’s a very nice guy, and he said, oh, you’re not slamming me. Don’t worry. But, you know, I didn’t want to feel like I was judging his work.

Even though he was an excellent colleague and one of the best people I’ve ever worked with, there’s the simple fact that he had the framework that he had that he was coming to, and no one was going through the process of really asking who this menu was really for. So, when we ask the question, who do we want to be able to use the navigation menu, the answer, of course, is everyone, because everyone is always the answer to this question. But we also want keyboard users to be able to use it. We want stream reader users to be able to use it.

We want people with low vision to be able to use it. That’s contrast issue. And people with cognitive disabilities. We do not want a navigation menu that overwhelms.

We want it to be easy to read and to use. So, we use an outside vendor for site architecture and visual design, and we ask them these questions. What is your agency’s overall approach to web accessibility? Are you familiar with WCAG, and can you provide us with examples of your work that meet WCAG guidelines?

And if you work for an organization where you bring in outside vendors, these are the three questions I encourage you to ask. And you need good answers to all three of those questions if you want to be able to move forward with a fully accessible result. And my favorite red flag is if you ask a vendor about accessibility and they say, oh, yeah, everything we launch is 100% accessible. Don’t ever use those people and run the other way.

Anyone who says that is guaranteed to provide you with a result that is not accessible because nothing is 100% accessible. And that answer doesn’t recognize the fact that accessibility is not a destination. It is a goal. It is a process.

And it is something that needs to be maintained over time. Nothing is 100% accessible and stays that way. So, our vendor adopted the accessibility mindset by focusing on simplifying the structure of the navigation menu, which we talked about, using a high contrast color scheme, working to find straightforward, easy to understand linked names, that’s that cognitive stuff, and avoiding unnecessary visual design elements. Our developers, that was me and a couple other people, adopted the accessibility mindset by ensuring the navigation menu can be used with only a keyboard.

The best way to do this is to unplug your mouse or put your mouse in a drawer so you don’t get it and tab through the keyboard and make sure you can get everything you want to get to. Using screen reader accessible markup, making the navigation menu responsive to varying screen widths, i.e. mobile responsive, this is out of the box standard these days, but still important, keep in mind. And adhering to the style guidelines as provided by the vendors.

The style guidelines were accessible as the developers, we needed to stick to them. We adopted the accessibility mindset during testing by using automated testing tools. At UC Berkeley, we use Siteimprove, but I personally use a suite of very different browser plugins. There’s lots of great testing tools, automated ones and non-automated.

We also did manually testing with only a keyboard. And also, and this is super important, it’s amazing how many people forget this, asking people with disabilities to help us test. I have my certifications, I know how to do a lot of accessibility testing, I know how to test with a screen reader, but I am not a daily screen reader user. You always need to test, you need to have the help of user testing with people who use those devices on a daily basis.

Those are the people who will find the issues that even an accessibility testing expert who does have those disabilities will not find. So, super important. So, where did we end up? These are two screenshots of the navigation, the new navigation menu.

One without a dropdown, one with the dropdown open. The top level links are now buttons. So, buttons are fully keyboard accessible, all on their own, they don’t need any special markup. This also means they are not hover menus, there are no hover menus here.

You click and you get a dropdown menu. These links are very short. I actually thought to have them even shorter, but I am satisfied with how relatively short these links are. The contrast is very high.

So, we cleared the contrast guidelines and they are fully navigable with a keyboard. They behave in predictable ways by keyboard users. So, not only do you get the dropdown when you click on the button, when you click the button, when you hit the tab next, you automatically tab into the dropdown menu and when you tab out of the dropdown menu, it automatically goes away. You don’t have to tell it to go away.

It has full support for screen readers as well. It is easier on the eyes. It is cleaner, it is easier to look at for cognitive processing. This navigation menu is a vast improvement.

We applied this all the way across the site. I am not going to dive too much into this, but these are our respective search bars. Searching the library catalog is most of what people want to do when they come to our site. On the top, we have the old one.

On the bottom, we have the new one. The old one has a lot of the same issues that the old navigation menu has, and the bottom one improves on this by adhering to the guidelines, being accessible to keyboards, lowering the cognitive load, and being screen reader accessible as well. So, there are very practical reasons for adopting an accessibility mindset, not just all the great stuff that I have been talking about, but also because retrofitting for accessibility, if you have to work backwards to make something accessible that is not, it takes more time and costs more money than starting with accessibility at the beginning. Also, retroactive fixes are difficult to maintain over the long term and increase an application’s fragility.

So, if you are having to retrofit and add more code, your application gets more fragile. There are more opportunities for it to break. You have to keep track of all of those changes, so it just gets more difficult to maintain. And most importantly, people higher up the ladder, and this is often your biggest leverage if you are lower down the ladder and you are trying to convince your higher-ups that accessibility is necessary, you are less likely to be sued.

And I have direct experience of this at UC Berkeley. UC Berkeley is now in a consent decree with the Department of Justice. We did get sued for very, very good reasons. We have milestones that we need to be hitting over the next few months to get all of our public-facing websites fully accessible.

UC Berkeley is learning this lesson the hard way. So, if you work for an organization where you are trying to convince accessibility is a necessary thing, the money is often the most convincing thing. I wish that were not the case. We live under capitalism.

Money is the motivator a lot of the time. So, telling someone they might get sued under the ADA, that is often the most motivating thing. Don’t be afraid to leverage that particular item. So, these questions, who is this for?

Who is able to use it? We can ask that question about all the kinds of technology, all the aspects of the built environment in our world. The world becomes a very different place when you start asking these questions. You start to see everything through a different lens.

And on this picture, on this slide, I have four pictures. Again, I will go clockwise. On the top left, we have an iPhone. Who is this for?

Who is able to use it? iPhones actually have a lot of really great accessibility features. So, lots of people are able to use that iPhone. Top right, we have a movie theater.

Movie theaters these days now have really great accessibility features. This particular movie theater has spaces for wheelchairs. The seats are very wide. So, they are not difficult to get out of.

There are stairs, but there are handrails at the bottom of those stairs for people who need it. Most importantly, there are places for people to sit who cannot get to the stairs and plenty of room for them to maneuver around so that they are able to enjoy the movie without having to go upstairs or wedge themselves into seats that they can’t get into. There are also features for people who are visually impaired. Bottom right, we have a BART train.

BART is the Bay Area Rapid Transit System. That is the transit system that I am most familiar with. Metz Transit Systems have lots of great accessibility features. If you start looking around for them, you can see the spaces for the wheelchairs.

You can see areas where there is Braille. At the stops, there are signs. There are people also announcing the stops so that deaf people know where they are and other hearing impaired people, visually impaired people. Lots of really great features.

This particular train platform has right by the edge a set of raised bumps so that visually impaired people using the canes are able to tell when they are near the edge of the platform. That also provides traction for people who need it. And then bottom left, we have a row of bank APMs. Banks have been sued up at Wazoo for accessibility because people have got to get their money.

So, APMs have a lot of really amazing accessibility features. You can get your wheelchair up to an ATM, turn it sideways, access all the features. Things are at a height for wheelchair users to be able to use. The buttons have raised numbers so you can feel them.

They also have Braille. They have audio inputs so people who need hearing devices can plug in whatever device they need. There’s all kinds of features. When you start asking these questions as you move about the world, you start seeing the world in a different way.

You start seeing what is accessible to everybody. What things are not accessible to everyone. What things have had the thought and the time spent on in order to make them accessible for everyone. And you can also start applying these questions to your own work.

As you are working on the things that you work on, on the things you build, whatever you happen to build, who is it for and who is able to use it? Because at the end of the day, who is able to use it is the same as who it ends up being for. These end up being the same thing. You may have intended it to be for everyone.

You may have inadvertently caused it to only be for certain people. Our goal is to make the things that we build and the things we create usable for absolutely everybody. That is the end of me yammering on about the accessibility mindset. Thank you for listening to me and watching my slides.

If there are comments or questions now, Andrew, I would be happy to take them. Yes, we have about nine minutes left. First off, I just want to say two things. Thank you so much for sharing your journey in making the University of California Berkeley Library accessible.

You are on the front line and that is a real impact. I want to thank you for the journey. Thank you for being brave enough to show where you were and where you are today. I really appreciate that.

The second thing, back to your slide with the movie theaters, I do want to say this, that there is a movie theater by me that has sensory showtimes. What that means is that they have the lights up, they have lower volume and they have a friendly environment and they say on their website to stand up, talk and sing. They have certain times where it is for sensory folks to come and enjoy movies. I want to say that is an option at a theater by me.

If it is not by you, you might have to ask and tell them to advertise it or request it. To me, that is a great way for movie theaters to have everybody, who is that for? A movie is for everybody. Allowing people to have space to enjoy it how they choose to enjoy it.

With that, we have some questions. The first one is, the question is up on the screen. What app or website have you personally used that delighted you by providing an inclusive digital experience? That is a great question and I especially like that question because naturally I spend most of my time thinking about the websites that don’t and that bugged me.

The first one that pops into my mind actually, and this won’t be a surprise, but the Level Access website is great. Level Access is of course an organization that provides tools and consulting for digital accessibility. Of course, their website is going to be accessible. It is accessible on a lot of really great levels.

Of course, the one that I am always initially the most sensitive to is the cognitive load that a website demands of me as a user. Level Access is just great. It is super clean. As you scroll through, what is occupied in the visual field is what you want to look at or what you need to look at right now without too much noise.

It also doesn’t sacrifice the pleasure of visual design in that goal because, of course, a lot of us who work on accessibility when we work with design departments, that is a place where we can bump heads a lot because a lot of designers want I want this pretty thing, I want this color, I want that, and you are saying as the accessibility expert, no, no, no, you can’t do that. But there is a lot of really great ground to be met there and I feel like the Level Access site does that really well. Of course, it is fully keyboard accessible and screen reader accessible. That is the low hanging fruit one that I will put out there.

Thanks for saying that. I will reiterate that space is such a great design tool for those of us that are sighted and to work with stakeholders to embrace space has been a challenge throughout my career, I will say, as a front-end developer. We will have one more question, I think, and then I want to give you space to answer this and then we will wrap it up with a few slides. There are other questions.

Feel free to reach out to Jesse, but we will just take one more here. The question is on the screen right now, it says, did you engage students to test the new website? Yes, most definitely. Unlike the process that was gone through for the old website that I showed you for the new one, with our vendor, we went through the process of identifying our audiences, we went through that process of identifying user personas, as they say, and of course, students was one of the largest.

We even broke that down into undergraduate students and graduate students because they came to our websites with different needs and are looking for different things. Yes, the answer is yes, we did because one of our biggest goals was to make our websites usable by the people that we identified as the user. Short answer to the question, but yes, we did. That’s great.

I also love your mission statement and how that level sets you to the work that you do. I think that’s a wonderful mission statement. Once again, I just want to thank you for sharing today. Really great advice.

I thought it was a very unique way to talk about how to bring digital accessibility to everything. I really appreciate your perspective and really enjoyed the talk today. Thank you. Thank you for having me.

Well, I’m also excited about what’s coming next for Alley Talks. Next month in March, we have another talk. It’s about accommodating neurodivergent learners. This is with Star Peterson and it’s going to be on March 13th at 11 a.m. Eastern time.

Don’t miss that or the great thing about these live streams is if you do miss it, you can watch it anytime. The only thing is you won’t be able to engage and ask questions. I just want to thank everybody for their questions today as well. We are always looking for speakers.

Even though we have a great lineup, we always need some more and it would be great to fill out the rest of this year with some really, really great speakers. Please visit our website, AlleyTalks.com and check out our page about how you can speak and how we can engage you and come up with a great topic to present. Please follow us and subscribe. You’re on YouTube right now and the Accessibility Talks channel.

There’s plenty of talks in the past that you can watch. One other thing about those talks is we are, for those of you that have IAAP certifications, speakers and attendees can get professional development credits through IAAP for your continuing education. Just know that. Please follow us and subscribe at all the things on YouTube, on X, on Mastodon.

We are in all the places and with that, I just want to thank everybody again and we will see you next month. Thanks for attending.

And Jesse here, you can start anytime. You’re muted. Yes, thank you. Now I’m sure no one else has ever done that before.

Thank you, Matt, very much. My name is Jesse Loesberg, as Matt said, and I am the web designer here in the UC Berkeley Library. And I’m gonna be talking today about manual accessibility testing. Can everyone, can you see my slide?

Yes. I’m going to take silence as the voice of simplicity and assume that if you can’t see my slides then I would have heard. All good. Excellent, thank you.

So manual accessibility testing. One of the great things about this particular presentation is I’m not gonna be talking about code. I’m not gonna be walking through any code. I will be spending time with at least one automated testing tool but you do not need to know code to do manual accessibility testing just like you don’t need to know any code to do automated accessibility testing.

We’re not gonna be talking about how to fix the things that I’m gonna show you today. I’ll spend a little bit of time talking about that because to do the fixes, it does help to know some code. We’re just really going to be talking about testing today and identifying problems and why manual testing is an important component of all the accessibility testing that you do. So before we talk about manual testing, it is important to talk about what automated testing is because that’s probably most of what we are familiar with and most of what we do.

So what is automated testing? I gotta move a little zoom window out of my way here. Automated testing is the use of any tool that scans a page, pages, or entire site and generates a report. This includes site improves, which many of us are probably familiar with, which I use all the time myself.

And it also includes browser extensions like HTML Sniffer, Axe DevTools, and Waves Chrome extension. And I have a little asterisk next to Axe DevTools because that’s the one that I’m gonna be using today. After site improve, I happen to like it a lot. But the other reason it’s asterisk is because the free version is excellent, but the paid version does provide tools for manual testing as well, which I will be talking about as well.

What is automated testing best for? It’s best for catching the so-called low hanging fruit of accessibility errors. It’s really great for catching color contrast issues. It will scan for images that are missing their alt attributes and let you know about those.

It will catch semantic structure errors. And by semantic structure, I mean the order of the elements on your page, like the order of your header elements, which is important not just for SEO, but if you have an H2 that precedes an H1 on your page, for example, that can trip up screen readers. And automated testing is also great for making sure that accessible text exists on your page or that all of the text on your page is accessible. And what I mean by that is if someone is using a screen reader and they are using a screen reader to read your page, that the screen reader is able to read all the text that it needs to read.

If there’s text on your page that is not accessible, screen readers are great for catching that as well. It’s great for catching many more things than I’ve just listed here, but this is what I think of as low hanging fruit. These are the things that screen readers that automated testing catches really well and are also not all that hard to fix. Automated testing is also really good for capturing the general accessibility state of your site.

If you’re just starting to assess your site, it can give you a sense of where your site stands overall. So if you have had the experience of setting up a Site Improve account and entering an existing site into Site Improve and having it scan your site, one of the things that Site Improve and other automated tests are really great for is just giving you an overall sense of what is the general state of your site if you are just starting your accessibility journey with your site. That initial score can really give you an idea of how much work is ahead of you. So along with identifying the kind of errors that I just mentioned, if you’re just kind of rolling it out on your site for the first time, it can really give you a sense of how much work do you have to do?

What are you looking at right now? Is your site in a pretty good state and just needs a bunch of tweaks or is the score pretty low and you’re gonna have to be thinking about some major overhauls? Automated testing is really, really great for that as well. So when I start talking about manual testing, it’s not manual testing versus automated testing.

It’s not that one is better than the other. These two complement each other. Automated testing is also a really essential part of your accessibility work, but it has all of these things about that are really great, but it does have some really large shortcomings. So what are those shortcomings?

What is the problem with automated testing? Automated testing only captures the page in a static state. It is unable to capture dynamic interactions, such as form interactions. If someone is filling out a form and there is feedback as the person is filling out the form or submitting the form, automated testing can’t necessarily capture all of that.

It cannot capture changes in dynamic navigation menus. So if you have a navigation menu that changes as your visitor moves through it, if there are pop-ups, if there are dynamic changes in the menu as somebody moves through it, automated testing isn’t necessarily going to capture those changes. If there’s an accessibility issue with a menu pop-up, automated testing might not catch that. Automated testing isn’t great for events that involve feedback or other notifications to the user.

So if there are things that happen on the page that require communication to the user, the page changes as they go through it. Automated testing may not catch that. It also may not catch changes in user focus, which is kind of related to what I was just talking about. User focus is where the browser is focused, where a keyboard may be focused as a user is moving through the change, as a user is moving through the change.

Changes in keyboard focus are a dynamic event. So what this all really kind of gets to is automated testing is really a snapshot of the page, oftentimes in the state that the page is in when it loads. Siteimprove, for example, calls the entire site, which is really awesome. What it is seeing when it calls is the state the page is in when it loads.

So if there are changes that occur as your visitors are using the page, Siteimprove isn’t necessarily going to catch those. If you’re using an automated browser extension tool like HTML Sniffer, for example, you can have it check the page in a state as it has changed. For example, if you submit a form and an error response has come and you want to check the page in that state, HTML Sniffer or AccuDevTools can capture that. But again, it’s only going to capture that in that static state.

It’s not going to capture changes as they happen. And that’s where manual testing comes in. The estimated amount of accessibility issues missed by automated testing is anywhere from 50 to 70%. That statistic comes, or that range comes from a few different locations.

It comes from some webinars that I attended by the Deque University. It comes from some articles that I’ve read. It’s a pretty broad range. I don’t know what that actual percentage is.

And that percentage can be pretty flexible, but the important thing to notice is that if you are only doing automated testing and you’re only capturing your pages in a static state without looking at the actual interactions that a user does, then you’re going to be missing a very large percentage of accessibility issues. And I’m going to step out of this for a moment. I have created some form pages to illustrate what I’m talking about, because like this slide says, manual testing can close this gap. So I’ve built this very simple form page, and it says form example bad, because there’s a lot of problems with this as you are going to see.

But if I run my inspector, and I’m going to use Axe DevTools for this. If I say, scan all of my page, here we go, scan, it says zero. That’s great. So as an automated test, this page has no errors on it.

If I walk away from this now, I say, great, this page has no errors, I’m done. I’m leaving many, many, many problems on the table, as you will see. So we’ve started off in a good state. So we started off in a good state.

My form fields are nice and big. We ran that test, which means that I have good labels on my form. It means that the input fields are all good. The initial state is pretty good, but I’m going to fill out this form with an error.

So my name is Jesse, I’m going to enter my email. But we have this message at the top that says all fields are required. I’m going to leave message blank, and I’m going to click submit. So what just happened here is the message form field just received a red border.

So intuitively we can say, okay, I was just informed by this red border that the message field needed something in it, and I didn’t put anything in it. However, if you are a colorblind person, then you may not be able to see that this border is red. If you’re using a screen reader, there is no text that informed the visitor that anything happened here. We have left a lot of errors here, because if we are only using color as a means to communicate to the user that something happened and we’re not using any text or anything, then screen readers are at a loss, visually impaired people are at a loss.

Many, many people click the submit button and may not necessarily know that anything happened. So let’s suppose again, that I actually complete this form correctly. Here’s my name, here’s my email, and here’s my message, hello. This looks all correct.

Now I click submit. What happened? Well, as far as I know, I got a little bit of feedback. The form fields are now empty.

That’s a common thing that happens when you’ve submitted a form. So that’s kind of good, but I received no feedback about what happened just now. Did my form successfully submit? I don’t know.

There’s no text that appeared to tell me that that happened. So people using screen readers don’t know. The other thing that’s missing here, if I try to use my keyboard to navigate this form, so I’m gonna tab through this page, which would normally allow me to get to all of the form fields. So I’ve hit tab.

The cursor is in the name field, but some designer decided that the outline that would normally appear on these form elements when you tab through it didn’t need to be there. Someone maybe, some designer maybe thought it was the wrong color, so they overrode them. So as I’m tabbing through this CRM, I’ve gotten back up to the top of my browser. I’m getting through all my browser links.

Well, that’s good, but then when I get into the page, it disappears. So automated testing said this form was fine, but now that we’re doing a little bit of manual work, and I will get into later the actual manual steps that I’m taking here, now that we’re actually manually testing this, it’s not good. There’s many, many problems with this form that automated testing missed. So I’m gonna go to my second form here.

So the name of this form is Better But Not Awesome. So why is this better? I’m gonna start filling this form out. Here’s my email.

Actually, I’m gonna leave email blank this time. Get rid of that. I’ll leave my message and we’ll say hello. I’m gonna click Submit.

All right, that’s a little better. So we still have the outline on the form field that was missing. We have some text that says this field is required. That’s great.

We have a message at the top here that says your submission had some problems. Please check the form. That’s good. I can also tab through this.

I can tab through this, and what the browser does with the outline, which I haven’t touched now, is present. So I’m able to more successfully navigate this with a keyboard. That’s great. So this is a better form.

However, I’m gonna bring Safari over here. I’m on a Mac. I’m gonna do the same thing. Oops.

Sorry about that. And we got our error. That’s great. I’m going to turn on my screen reader now.

Let me make sure I am sharing my sound. And this will start it up in a second. Can you all hear that? No, I cannot hear it.

No, Jesse. So you can hear it. I can hear it. I can hear it.

I can hear it. I can hear it. I can hear it. So you cannot hear it.

Is that correct? Sorry. Correct. So we cannot hear it.

All right. I’m gonna just quickly mess around with my Zoom settings. And if I can’t do it in just a couple of seconds, I will explain what’s going on. All right.

We’re not gonna waste too much time on that. All right. Let me explain to you what’s happening with a screen reader here. I turned my screen reader on and it identified the page and it let me know that there was a form on this page, but it did not let me know, one, that I had successfully submitted the form and the screen reader also didn’t notify me of this error.

So we’ve got the keyboard stuff down. That’s awesome. We have these visual error notifications. That’s also great.

But this page is not coded to work well with a screen reader. As far as the screen reader user knew, they press the submit button and nothing happened. The page didn’t communicate that. Now, since I don’t have my sound turned on, which is too bad, I do have this form here called best of the bunch because there’s actually still a ton of other problems with this form, but we’re not gonna go into right now.

This form has all the same features that we just saw, but the error notification field is coded so that it does actually communicate with the screen reader and the screen reader does inform the user that the form has been submitted. If the form was submitted successfully, it lets the screen reader user know that and it also announces if there are errors and the screen reader is also able to navigate through each individual field and know which ones have the error and which ones don’t. Again, if I use, I’m gonna go back here again. If I go to my DevTools, my xDevTools and scan the page again, it’s gonna give me, oh, well, that’s nice.

What are my two serious errors? Oh, excellent. I’m glad I was reminded of this. I did this on purpose.

So the big problem here now, even though we had all this good communication, is the color I have chosen to communicate the errors, this red, does not clear color contrast requirements. Those of you who have done some accessibility work, Site Improve is really great at catching this stuff. I’ve used this color red. The contrast is not sufficient.

The contrast ratio needs to be 4.5 to one and let’s see what we got with that red just out of curiosity. We were super close. Down here it says 3.99. All right, that was close, but it needs to be 4.5.

If I had just checked the form in its initial state and didn’t check it in this state, I would have not known that the color I chose for communicating my errors doesn’t pass the contrast requirement and people with visual impairments would not be able to see it. So these are some examples of what automated testing would miss and why manual testing in and of itself is important. What I’m gonna move to next is the actual nuts and bolts of manual testing. This is a good point to stop for some questions, I think, before I do.

Do we wanna do any questions? Anybody have any questions yet or shall I continue? I will continue. Let’s get back in slideshow here.

Okay, so basic manual keyboard testing. If you are a mouse user, hide the mouse. Take your mouse, unplug it, remove the temptation to use your mouse. Navigate through the page using only the tab key.

What the tab key does is it moves to elements that are interactive. It will hit all of the links. If there’s a forum, it will hit input elements and it will hit all the buttons. The tab key just gets to anything that can be clicked.

So the question you need to ask are, is the focused element plainly obvious? Does it have a nice big border around it? Are you able to access all the clickable elements? If this is a page that you’ve built or have worked on building and you’re familiar with it and you know that there’s something that should be clickable, but the tabbing doesn’t illuminate that element, that’s a problem to fix.

Is the focus order sensible? When you tab through the page, is the keyboard focus moving through the page in an order that makes sense? And in a second, I’m gonna show you a great example of a page that does not. You should also test any clickable elements using the return and enter key.

This is how a keyboard user activates an element that can be clicked. It’s how they click on links and how they click buttons. Are you able to activate clickable elements with only the keyboard? You should be able, anything that you can click with a mouse, you need to be able to click with a keyboard too.

Test modular windows or pop-up menus with the escape key. Any window that pops up or any dropdown menu that comes, you should be able to close with the escape key as well and not need to click away from it with the mouse. Okay, so let’s get to the screen here in a second. So I’m going to move out of this again for a second and I’m gonna go to my favorite website to hate, which is PG&E.

So my page is loaded. I’m gonna move through this page using the keyboard now. So I’m hitting the tab key right now. Where am I?

Well, someone with extremely astute eyes will have noticed that the cursor appeared in the username box in the sign-in. Now what’s good about that is that is what people mostly are gonna wanna do on this page. They’re gonna wanna know what’s going on in this page. So I’m gonna go to my favorite website and what people mostly are gonna wanna do on this page, they’re gonna wanna sign in, that’s great.

But if I’m visually impaired, I can’t see that cursor. Now I’m going to tab again. I’m in the password box. Okay, great.

But the password box didn’t illuminate. There’s nothing visually keying me or visually impaired user into the fact that that box has been selected. Now I’m gonna tab again. Remember my username checkbox is a little illuminated, you can’t really see it.

I’m clicking again. All right, the sign in button appeared and there’s a dotted line around the sign in. Well, the built-in function in Chrome for outlining a focused element is a blue outline. If your designer doesn’t touch this feature, that’s what appears.

But somebody at PG&E decided that this little one pixel dotted outline was the best thing to use. This is very small. Visually impaired people are not going to be able to see this very well. I’m going to tap again.

So now we’ve gone up to username. Now we’ve gone to forgot password. Okay, register, that’s pretty good. That illuminated.

And now I’ve gone up to skip to main content. So this dotted outline, here I am moving to the page. It’s not awesome. It’s not terrible, but it’s not perfect.

But I’m going to reload the page and I’m going to use a little browser extension here to show you what I mean by tab order. Why does tab order need to be sensible? Well, I hit tab and here we are in the username box. Now I’ve tabbed again, we’ve gone to password.

I tab again, over here to remember my username. I tab again, sign in. Now I’ve gone up to forgot username. Okay, now I’ve gone down to forgot password.

Is this the route that someone would normally travel through it? Maybe, I don’t think so personally. Oh, register, visitor, okay. Someone, where might they want to go next?

Well, I’m not really sure, but I’m going to hit tab again and see where PG&E thinks I ought to go next. Oh, I’ve gone up to the hidden skip to main content link. All right, now I’ve gone of the logo. Okay, now I’ve gone over here to remember.

So the nice thing about this little plugin that I use is it shows what the route is. This route should be pretty clear and it’s all over the page. I love the PG&E website for this reason. It always makes itself available for that example.

So this is what I mean by the tab order. The tab order should be sensible. Once we’re past all this garbage at the top of the page, it starts to make a little more sense for moving through the page in a more linear fashion. But this needs to make sense.

This needs to make sense to all of your visitors because if you are just a keyboard user, you don’t want to have to think too hard about the route that you’re going through the page. It needs to make sense to the user. I don’t know what PG&E is thinking, but that kind of goes for PG&E generally. I often don’t know what they’re thinking.

So that is an example of what I mean by tab order. So back to the slides. Basic manual screen reader testing. Something all you should do, everybody should do, is acquire some basic screen reader commands, and I will have some resources to this at the end of my presentation.

You should be able to navigate with a tab key. You should be able to navigate by line, which is simply the most basic way of moving through a web page. This is all with a keyboard, by the way, which is how most visually impaired users navigate using a screen reader. You should be able to navigate by heading by the H1s and H2s.

You should be able to navigate by landmark. And I have an asterisk here because landmarks are not something that is a visual element. It’s on the code level. It’s how content areas of the page are marked off and is one of the ways that screen readers can navigate a page.

You should be able to list all of the form elements that is something a screen reader can do. And you should also be able to list all of the links. Just some very basic ways that a screen reader can navigate through a page. These are some skills that are pretty easy to pick up.

And it is something that anyone doing manual testing should be able to do. Then you should navigate through the page and perform some basic actions. You should be able to perform all the basic actions using a screen reader that a non-visually impaired user should do. So on that PG&E page, for example, you should be able to easily log in.

You should be able to easily find the login and you should be able to easily log in. And I’m not even gonna put a screen reader on that PG&E homepage. I did it once and my brain is still hurting from it. One of the questions you should ask as you navigate with a screen reader is does what you, if you are a non-visually impaired person and you are using your eyes at the same time that you are using a screen reader, ask yourself, does what you hear from the screen reader match your understanding of the page?

Is the person using a screen reader, will they be able to perceive and do all the things that a visual person can see and do? Which also gets to my next point. If you are non-visually impaired, are there things you are aware of that the screen reader is not calling out? If you’re navigating the page and the things you see that you knew you should have been able to perceive with a screen reader and a screen reader doesn’t catch it, that needs to be fixed.

But how do I decide what to test? I can’t do manual testing on my entire site. Well, no, no, of course not. And no one is expecting you to manually test your entire site.

What you should test though, you should test your homepage since that’s gonna be one of the most highly trafficked, one of the most highly trafficked pages on your site. So you should definitely manually test that. If you have a fancy navigation menu, if it’s got pop-ups, you should manually test that. If it’s got pop-ups, you should manually test that as well.

You should manually test all of your forms for the reasons that I showed with my test forms. You should make sure that anybody using assistive technology, anybody using a screen reader or a keyboard is able to fully interact with the form as someone who is not using assistive technology. Remember, just remember very importantly that the automated testing may look at a form and decide that it’s fine. It’s the manual testing that’s gonna pull out the fact that it’s not.

You should also manually test any custom built widgets. And I’m going to give you a quick example of that from my very own or our very own library website. On the library website, one of the things that we built, and we just rebuilt this last May. So we’re coming up on its one year anniversary.

We have a customized widget. We have a bunch of customized widgets, but I’m gonna show you this one. This area down here, we in the library, we referred to this as the vertical tab list. And this is a very common thing you see around the web.

When I click these, the content area changes, which if you are a mouse user and a non-visually impaired user, this works the way you would expect it to, click these, change it, no big deal. The thing is, this is custom built. These buttons here, these are not actual buttons. If you are familiar with HTML, this is actually a list.

This is an unordered list element, and these are all LI elements. And what’s causing us to change is custom JavaScript that we have written, which means if you’re a keyboard user, these things need to be accessible. So if I start tabbing through the page, here’s all the stuff. These are all tab-able, these links, that’s great.

All these links are tab-able, that’s great, blah, blah, blah. Okay, now we get down to our custom elements. You’ll see right now that the visit button is highlighted. This would not have happened unless I and my fellow web developer made this happen.

Without me specifically saying this is a focusable element, it should be able to receive focus, and it should act like a focusable element in that it should receive and it should appear with an outline when it’s focused. We needed to specifically do this. If we hadn’t done this, this would have failed this manual test. And also, so this needs to be navigable with the keyboard, which I’m doing, and the content needs to change as I navigate.

So this is a custom-built widget. This needs to pass the manual test as well. If you have custom-built widgets, it needs to do that as well. This is also coded so that a screen reader user is informed that this is not a regular unordered list, but that these are buttons that can be interacted with and that things happen when the buttons are interacted with.

So it needs to pass this screen reader test as well. So if you have custom widgets, your custom widgets need to be manually tested. The best reason to test manually though, or the best reason, one of the best reasons, this is one of my favorite reasons to learn manual testing, is that manually testing will expand your mind. All of the things that I listed here are little tests you can do and actions you can take to make sure that your site is accessible to people using assistive technology.

But equally important is that learning how to do manual testing, doing things like unplugging your mouse and pushing it away, or learning to use a screen reader, it changes your own mental framework. The way that you interact with things on the web and the way that you move through the world and interact with technology is all informed by whatever your abilities are, what your disabilities may be, your psychological makeup, your background, your life. All of these things are informed by your life experience. And we tie these frameworks and these structures around with us, oftentimes on a level that we are not aware of.

By learning how to test manually, by doing this keyboard testing, by experimenting with a screen reader and learning some basic screen reader skills, it changes the way you think about a website. And if you work on websites, it changes the way you think about your work. And it reintroduces you to the web pages that you work on, it introduces you to websites generally, and it introduces you, it reintroduces you to the technology that you use in a way that you were not familiar with, which is really a big step into adopting a full accessibility mindset, so that when you start on your next project, you have already primed your mind to think about your webpage in a multi-dimensional way. If you are a mouse user and you are not visually impaired, then you generally think of a website as an object that you click on things and that you vertically scroll through.

Using a screen reader shows you that not everybody uses it that way, that there are different points of access to a website, that it is not simply a visual medium, that moving your mouse around to click on stuff is not the only way. Your website is a multi-dimensional object that people with other backgrounds and other abilities and other mental frameworks come to in a completely different way, and this is one of the best reasons to learn manual testing, because it changes the way that you think, which is really my secret goal here. I’m trying to change the way that everybody thinks, but they’re good. Having said all that, we’ll now look at some of their resources.

This is a list of links for Quick for, let me start that sentence again. This is a list of short tech guide for screen readers. If you are a Mac user, you already have a built-in screen reader, it’s called VoiceOver. You can go into your settings and turn that on.

I’m talking about this in terms of the web. VoiceOver is for the entire operating system. It works on whatever you are using. These particular guides are for navigating web pages with it.

We have a quick guide from VoiceOver for Mac. There’s a quick guide for NVDA, which is a screen reader for Windows and interacts best. Yes, I see the question about all those links being sent. We’re gonna make the slide deck available, so you’ll have access to it, I promise.

NVDAs for Windows works best with Firefox. JAWS, which as I learned during my last presentation, is not free, it requires a license. But if you are fortunate enough to have JAWS, which works best with Chrome on Windows, here’s a quick guide for JAWS. If you really wanna dive in, and of course I encourage you to do this, I also have links here to using VoiceOver gestures on iOS, on your phone.

Turning VoiceOver on your phone turns it into an entirely different tool. All of the gestures that you’re familiar with on your phone, if you’re a slated user, all the tapping, turning on VoiceOver, tapping doesn’t work. Swiping doesn’t work. It changes what a tap does, and it changes what a swipe does.

It’s a great thing to learn. That is the guide for using VoiceOver. TalkBack is the screen reader for Android devices, and we have that quick guide there as well. Here’s some manual testing guides.

Of course, I have the requisite link to our own DIY accessibility checklist. This comes from the Web Access folks. The DIY accessibility checklist covers everything, but the reason I have it here is if you go through that checklist, it will naturally nudge you towards the kind of manual testing that you need to do. The things that has you checked for, many of them can be caught with automated testing, but some of them, you will have to do some of the things that I showed you here.

You’ll have to use your keyboard. You’ll have to check things out with a screen reader. This link for keyboard testing is also on the Web Access site. It’s a simple guide for how to do keyboard testing.

This webinar is from the Q, which itself is a really great resource. It is a webinar about simplifying manual accessibility audits, and it specifically uses Axe DevTools, which is also the next link that I have here. Axe DevTools is really great. It’s the one that I was using here, and it’s a really great tool, especially if you are a developer, because it runs in Chrome’s dev schools.

There is a paid version, which actually contains walkthroughs for manual tests. The license is very expensive. I think it’s around $500 a year, so I don’t use that, but the great thing about the paid version of Axe DevTools is it will walk you through manual testing, which is kind of awesome. And that is the end.

I am happy to take questions if anybody has them. Would it be possible to share the excellent presentation about the meeting? Yes. We generally send out the slide deck a couple of days after each presentation, so if you are on the webnet list, you will receive that link.

My contact information, I’m just gonna go back up here. I’m in the directory, but I am always happy to help. I’m always happy to answer questions. You can reach me at jloisberg at berkeley.edu, and if you’re not on the webnet list for some reason, and you don’t get that link, I’m happy to share this link.

Any other questions? I have one. Thank you so much, Jesse. And yes, folks, I’m gonna be sending you the recording of this and Jesse’s excellent slide deck in a couple of days, so thanks for your patience on that.

So, Jesse. Oh, my plug, were you gonna remind me about that plug? Okay, I’m just gonna, yeah. Before we get to your question, I’m gonna plug something.

I’m presenting at the UC Tech Conference in just a few months. It’s July 16th through 18th. UC Tech is on the Berkeley campus this year. That little field that I went off on about changing your mind is what my presentation is gonna be about.

It’s gonna be about adopting the accessibility mindset and the questions you need to ask yourself to change the way you look at technology in general and about websites in particular, and it’s also going to walk through the web design process and at every step of the way, what are the things people can do to change their mind? That’s my plug. Come hear my talk. Thank you, Lisa.

Is that your question? Well, you know, for those of us who may not go to the UC Tech, I’m hoping that you will redo it for free for your WebNet people, but we can talk about that. UC Tech costs money, it’s true. I’ll be more than happy to do that one again.

I’ll talk to your manager, to your agent. My question is, I don’t know if anybody else remembers the wonderful WebNet presentation a few years ago when Lucy Greco actually walked us through how to do the accessibility testing on an Android or an iPhone, and I was immediately lost. I mean, it was a complete s-show in my world. I was like, I can’t do this.

Is there one of the automated tools like Axe or WebAIM or whatever that does some kind of automated testing for a mobile device? You know, that’s a really great question. I don’t know of any mobile specific devices. A lot of the web accessibility stuff that you do for desktop is also going to apply for the phone.

So if you are getting a good score and if you’ve done a lot of manual testing for a desktop, you’re gonna have gotten most of what a phone gets. What I’m gonna say though, and this gets to my broader philosophical goal here, is that initial reaction that you had of, I don’t know what I’m doing with this. That is a natural reaction because when you do turn voice around on your phone, like I said, it totally changes it. It becomes something that you’re in a way not able to use.

So a few months ago, I restarted piano lessons. I took piano lessons as a kid and then forgot most of what I learned. And I came back to the piano and I could read music, but really my hands had no idea what I was doing. But I have, you know, in the months since I’ve learned that sort of magic moment where I’ve gotten familiar enough with whatever piece of music I’m trying to play that it clicks and I got it.

And that’s just a way of saying practice is what helps you get this thing, especially with the phone. Because with the phone, like you can’t just say, oh, I changed my mind, I’m gonna use my mouse. Oh, this screen reader is driving me crazy, I’m gonna shut it off. You know, with the phone, if it’s on, it’s on and shutting it off is actually a step.

So you just gotta like not be doing anything else and have that list of phone gestures in front of you and try some things out. You’re not gonna break anything. You’re not gonna break your phone. You’re not gonna accidentally call 911, I don’t think.

You know, just take the time to learn those gestures. First time I did it, I would completely lost too. And I also haven’t done it in a few months. If I tried to do it again now, I’d be just as lost as you.

It seems really scary at first, but once you do that, you have built those extra neurons and you have expanded your mind. Does that answer your question? It does. And I think I agree with that.

They use it or lose it. I mean, if we don’t continuously try these things, we’re gonna lose it. But Jesse, you really should see me with my phone, just trying to text. It’s really kind of hysterical.

Yeah. I’m gonna leave that kind of testing to you. But thank you. Sure, happy to do it.

Any other questions? We’ve still got 12 minutes left, if anybody wants some, or we can let people get back to their lunches. I have another one. Sure.

And folks, please just unmute yourself. We’re a small enough group that, or you can use the chat, of course. So, I’m gonna go ahead and start with the question. So, I’m gonna start with the question.

Or you can use the chat, of course. So, I think more and more, for those of us, even maybe people who are using Open Berkeley, it seems like a lot more of our content is being thrown up into our Google Cloud. I mean, maybe, since they’re gonna have the storage restriction that may change, but like a lot of forms, we’re not making them in Drupal anymore. We’re sending them over to Google Forms.

And I know that we can’t really control so much the accessibility of the Google products, but do you recommend that we still do some manual testing, and if it doesn’t work, we holler at somebody? Yes, I not only recommend, but encourage. Yeah, yeah. Yeah, I think even Google, they’re big enough to kind of do what they want, and I do recommend always testing a form.

Even if it’s a Google Form, I don’t think you should ever 100% trust a product that you haven’t tested. I haven’t ever tested a Google Form myself. A lot of the visual feedback I see on a Google Form looks pretty good, but Google is a corporation, and they’re about the money. And they need to get pressured in the pocketbook.

They need to get pressured in the wallet in order to make the changes that we want them to make. And if they’re not feeling that pressure, they’re not gonna do it. So I think hollering is a really good thing to do because we are a big client of theirs. Obviously, UC Berkeley is not gonna stop using Google, not at this point.

But if enough of us are finding that the forms are not accessible, and enough of us start hollering, we can at least create the momentum to create some pressure on the monster that Google is. But to answer your question, yes, you can test everything. Everything should be tested. Thank you.

Because I know, I mean, you have control over label text and things like that, and you know how the conditions. Well, in addition to plugging you at the UC Tech, I think Lucy’s doing a couple of accessibility Ooh. Talks. I have not seen the list yet.

So I’m gonna put the questions into it. Yeah, so folks, if you haven’t checked out the agenda, take a look at it. I think there’s some stuff that applies to what we all do for a living. So that’s exciting.

Okay. Well, I’m done with my question. Okay. For now.

Well, you know where to find me, Lisa. All right, well, if there are no other questions, then I will say thank you for coming. Feel free to get in touch if you would like to. And I’m sure I will see you all again sometime.

Matt, you wanna stop the recording? Feel free. Yes. Thanks, Jesse.

You’re welcome. Thanks for coming.

Welcome, everyone, to the first WebNet meeting of the 2024-2025 academic year. Our topic today is how to create a digital accessibility plan. And I am thrilled that the speaker is my dear friend and colleague, Jesse Loesberg. So I don’t, I’m not going to talk anymore.

I’m going to let Jesse just jump in and share his wisdom with you. So thank you very much, Jesse. Over to you. Thank you, Lisa.

I probably know most of y’all already or most of y’all know me. If you don’t, my name is Jesse Loesberg, like Lisa said. Before I go into all my title and stuff, if you do have questions, feel free to unmute. I am not a super awesome multitasker.

So if you raise your hand using the gestures, it’s entirely possible that I won’t see it. I also have trouble keeping an eye on the Q&A. So if you want to unmute during the talk, that is fine. Or we could just save questions for the end.

I have a feeling I’m not going to be going like the whole, I’m definitely not going the whole hour. I think there’s going to be a pretty good amount of time for questions. If you are using the gestures or the icons to raise your hand, or you drop in the Q&A and I don’t see it, it doesn’t mean I’m not going to get to it. It just means that my brain just does not do multiple things at the same time.

So like you see on the slide here, I am going to be talking about how to create a digital accessibility plan. My official title here in the library is library web designer. I am also the library web developer. You’ll also see here I say digital accessibility project manager, sort of.

The reason for that is I’ve kind of been the de facto digital accessibility project manager for a while just by virtue of my particular skill set, my commitment to accessibility, the fact that accessibility is one of the first things that’s out of my mouth whenever I’m working on a project. But soon that is going to be an official part of my title. The only reason the sort of is there is because it is not officially part of my job description yet. That particular aspect of my job is going on Berkeley time at the moment.

Soon it will be the official, it will actually be in my job description. I will be able to say without a parenthetical that I am the library’s digital accessibility project manager. So jumping right in, what is a digital accessibility plan even? We like to start with first principles here at the very beginning.

Well, the way that I have put it together, it is a map of your organization’s web presence. It is a plan for auditing the components of your web presence. It is also a plan for remediating accessibility issues. It is a plan for ongoing accessibility review.

And also a plan for communicating progress across your organization. So the plan that I am working on and that we are in the process of implementing but also has not been officially and fully implemented yet but is on the way there contains these features. This is the map that we are using for the digital accessibility plan that we are creating here in the library and I am spearheading. So the library’s web presence is composed of, it has many, many parts as you will see here and I will walk us through this table.

Your organization may not have quite as many parts, maybe it even has more parts. Maybe you have multiple websites, maybe you have only one. We have a lot here at the library and the guiding principle for how we organize this is really based on how much access do we here in the library have to the source code of the particular application in question and by extension how direct is the route to remediating accessibility issues that come up. So there are lots of ways to group all of the applications that we run here in the library but this particular approach is really accessibility focused.

When problems come up, how much access do we have to remediating those issues? So in the first column in the table all the way over on the left, we have the locally built applications and here in the library that includes the Drupal sites. We have two Drupal sites. It is our main public-facing library website but also our staff website is also on Drupal.

We have a handful of WordPress sites that are doing a bunch of different things but the most public one is the library blog which is called library update. That is a WordPress site. And then internally there’s a bunch of custom forms and APIs which are locally built. And the reason these are all in the first column is any accessibility issues that come up them, I or Lisa or other of my colleagues have direct access to the code that is running these sites.

So at the very bottom of this column here we see almost all issues can be remediated directly by our own developers. So even though the core code that runs Drupal and the core code that runs WordPress, we didn’t write that code, I can either patch that code directly if there is an accessibility issue or I can communicate directly with the WordPress or Drupal community and find out if there is a fix in the pipeline. Maybe someone’s already got a patch that I can use and then apply myself. But there’s also all of the custom theming and any custom plugins or modules that I or my colleagues have created that are running on these sites that I can then access the code directly myself.

So that is the first column. The second column is open source third party applications. And here in the library some examples of that are our digital exhibits platform, which internally we know as Tend. There’s Geodata, which is a map data resource.

We also have a short link generator that various folks here in the library use if there’s a very long URL that we want to condense into a very short URL for the purposes of sending out. These are all applications that are running on open source code. But we don’t necessarily have the access to remediate issues directly ourselves. Some of the issues can be remediated by me.

Some of the issues can be remediated by our own developers. But a lot of these platforms come from other places. In fact, we just announced this morning a platform called Dataverse, which is a repository for data sets that the library owns. That platform comes from Harvard.

So we can technically access that code, but we didn’t write that code. That code comes from Harvard. Our route to remediation for those items is not as immediate or as accessible as with our Drupal and WordPress sites. Finally, in the third column are our vendor applications.

The biggest example of a vendor application in the case of the library is UC library search. If you go to the library website and search for a book or a journal or an article, you are shunted over to UC library search, which is a third-party vendor platform. It’s run by a company called Xlibris. We do not have any direct access to the code that runs at that site.

We do have a little bit of custom code that generates the front end. Some of the styling is code that I manage myself. So I do have a little bit of access there. But to major accessibility issues, we are not able to even touch that code.

We have to communicate directly to the vendor. There’s also a platform called LibGuides where librarians can create guides to various collections and stuff like that. And there’s also our digital collections. Oh, I did a little conflation here.

Going back to that second column for a second, I’m sorry. Digital exhibits is different than digital collections. Digital exhibits is a platform called Spotlight. Digital collections is Tind.

Don’t worry about it. But Tind is one of those third-party vendor applications to which we do not have access to the code. When we identify accessibility issues, we have to communicate to the vendor. So these three categories are based on how quickly or accessibly can I do the remediation or can our developers in IT do that?

Or do I need to submit a ticket or communicate with a vendor? So the next question for our program is how do we then prioritize all these applications for auditing? There are a lot of them. I would like to be able to audit our entire web presence in a reasonable time frame.

But we do need to prioritize because there are so many. So I have asked a particular set of questions. The first question is, is it public or is it internal? Something public facing is going to get higher priority than something that is just internal only because the public stuff is getting used by more people.

It’s more visible. The rubber is meeting the road a little bit harder. It just means that there are more eyeballs on it. There are more people using it.

There are more hands on keyboards. Anything public gets prioritized higher than anything that is just for an internal audience of the library. Then there’s the question of how essential is it to core library services? So it may be an internal application, but if it’s something super important to how the library functions, we weigh that against the first question of whether it’s public or internal.

If it’s super essential, that’s going to get prioritized higher as well. Then there’s how much traffic does it get, which also weighs in. Then there’s a question of what is its current level of accessibility? With this one, obviously we don’t know what its current level of accessibility is until we actually audit yet, and we haven’t started the audit process necessarily.

I look at everything, and you can get a general sense, but a full dive in, of how accessible is this particular application. In the case of our public-facing websites, which are already in site improve, or I’ve already spent a lot of time working on the accessibility of, or in the case of our public website, which got rebuilt in 2022, we had an accessibility-first focus on that. I already know that a lot of our high-level public-facing websites have a pretty good state of accessibility, so we don’t necessarily need to look at those first. But these are all the questions that we ask, and we weigh all of these, and then I go to my spreadsheet where I have my applications and develop a prioritization structure based on these particular items.

There are a lot of companies that when they look at the prioritization of accessibility issues, they have an actual scoring system, a very complex and well-thought-out scoring system. I have not developed a scoring system, but I just attended a webinar this week about what a process like that might look like, and I’m starting to chew on how I might score our various applications priority-wise based on these questions here. How do you grow about auditing your applications? Well, there’s a really awesome Plan A, which we are fortunate to have here in the library, which is how someone like me, and who am I?

I am an IAP Certified Professional in Web Accessibility. IAP is the International Association of Accessibility Professionals, so I’ve gone through those certification processes. I’m also a DHS Certified Trusted Tester. DHS is Department of Homeland Security.

I never thought I would have a certification from the Department of Homeland Security, but here we are. I’m also an experienced SiteImprove user. I’ve been using SiteImprove pretty much since UC started their contract with them, and I’m also experienced with other accessibility testing tools. I can already do most of what is required to actually audit a site or application.

It’s unusual to have a person on your staff who has all of these things, so what is Plan B? Plan B is to educate yourself. You can register your site with SiteImprove. We’re going to be sharing out this slide deck later, but this particular link here goes to where you are able to register your site with SiteImprove.

In that same place, there are links to how you can learn to use SiteImprove. SiteImprove is a lot of how I got into the auditing process in the first place. If you start using SiteImprove and start getting into its nuts and bolts, you will automatically start learning a lot of the auditing process. It’s a really great gateway to getting into not just using SiteImprove specifically, but how do you audit and remediate a website in general.

There’s also getting familiar with the Web Content Accessibility Guidelines. I’ve done deep dives into WCAG in other talks. I’m not going to do a super deep dive here. I’m going to talk about it a little bit more later, but the Web Content Accessibility Guidelines are the generally accepted guidelines for how to make a website or application as accessible as possible.

Also, on the Digital Accessibility Program, you can review the steps for site owners and accessibility basics on the Digital Accessibility Program website. I won’t say these are high bars to clear, but there are a lot to ask of website staff here at UC Berkeley. We’re all very, very busy. We’re all doing a lot of things.

For a lot of us that are managing websites, that’s not the only thing that we’re doing. We’re doing many, many, many other things. Maybe managing the website is only part of what you do. The items that are on this list, I fully recognize that these are things that take time and they take energy, and they take effort, and they may not be in your job description, and you may not have been specifically tasked with them.

This is a best of all possible worlds kind of situation. Digital accessibility is very important. It’s essential to our mission, especially here in the library, but at UC Berkeley in general. I also recognize the reality of the environment in which we are working, where we are all being tasked with more and more, with fewer time and resources.

These are goals. These are things to shoot for. They are things I hope you are able to take on as you are able to, but when I say Plan B, this is very much Plan B. We are all working in a substandard situation for making sure that our web presence here at UC Berkeley is fully accessible.

What’s Plan C? Plan C, which can be done in conjunction with Plan B, is to hire outside accessibility experts. This takes a budget, of course. Not everybody has a budget for it.

Doing this also kind of contributes to the unfortunately highly siloed structure we have here at UC Berkeley. When you hire outside experts that other people have not hired, that really contributes to some of the haphazard and isolated way that we are all taking on accessibility here at UC Berkeley. That said, there are a few really great organizations that I have either taken trainings with or had interactions with or used tools from. Three of those I’ve listed here are Deque.com.

I use one of their browser extensions to do manual testing of sites that we don’t have in SiteImprove and also to manually test dynamic interactions that SiteImprove cannot capture. They’re really great. Usable.net is pretty awesome. Level access is also good.

This, of course, requires money, which is also a limited resource in our current circumstances. When it comes time to remediate, when you have done your audits and you have identified issues, this is the part of the plan where we identify who are the people who are responsible for actually remediating the issues that come up. Again, I have my three-part structure here, the categories in which I’ve broken out the applications here at the library. For the locally built applications over on the left column, the folks who are going to remediate are mostly me.

I’m going to be doing a lot of stuff. Lisa Weber, who you met at the beginning here, you all already know, also does a lot of great remediation work. Then for some things, depending on what the application is, those remediation tasks will go to other developers that we have here in library IT. Then once the remediation is done over here at the bottom, the subsequent action after that is to test it, is to rerun the test either in SiteImprove or in the other tools that I use and make sure that the remediation actually took.

For that second category, where it’s maybe a locally built application or it’s an open source application that we have some access to but not full access, the folks responsible for remediation are either the local IT developers here in library IT that are experienced working with that application or we can take the issue to the original application developer, let them know what we have found and ask them to remediate or provide us with a timeline for remediation. The subsequent actions there, if we were able to remediate the action locally, again we test. If we had to take it back to the original application developer, we have a communication plan where we follow up with the original developer, we ask them what their timeline is, we nudge them if we need to and when we have been informed that the remediation has occurred, again we test. The most cantankerous category is this third category, the vendor applications.

For each of our vendor applications, we have a local contact in library IT who is responsible for communicating with that particular vendor. I, as the digital accessibility program manager, will communicate with that particular person in library IT. We use JIRA for project management, so that will usually take the form of a JIRA ticket and I will ask that particular content to communicate the accessibility issue that we have uncovered to the vendor. I will supply as much information as I possibly can.

I will supply information that can be understood by an application developer. I will also provide a human readable explanation of what the issue is and who is affected by it and why it is important to fix and I will also supply steps that a developer can take to remediate the issue. The subsequent action after that is to annoy the vendor. I will tell you not to be shy about being annoying.

Being annoying is how accessibility issues that you are not fully in control of get fixed. A lot of third party vendors may not have accessibility as their priority and they should, but they might not. If they do not, then it is my job as the digital accessibility program manager to be the thorn in the side and to communicate that we take accessibility very seriously. We would like our vendors to do it too and I am going to be annoying and hope that my being annoying turns into actual remediation and when that remediation finally occurs, then again, we test.

Abigail, I am glad you appreciate my being annoying. I like being annoying in this case. It is the only time I like being annoying really. Otherwise, I like to be a nice person who people like to work with and enjoy hearing from and do not drive hearing from.

Jessie, this is Lisa. I have a quick question and you may cover it later. I do not know, but when you are talking about vendors, what is the VPAT thing we get from them? Does not that guarantee?

What is that all about? Excellent question. I actually did not include that, so I will talk about it now. I am really thankful that you raised that, Lisa.

Lisa referred to something called a VPAT. VPAT stands for vendor product accessibility template. What that is, it is a very thorough document that a vendor can step through. It contains all of the relevant web content accessibility guidelines and the vendor can demonstrate whether their application meets the web content accessibility guideline, partially meets it, or does not meet it.

VPAT is a blank template. A completed VPAT is called an accessibility conformance report, or an ACR for short. Vendors are not required to do this. The V in VPAT stands for voluntary.

It is voluntary. No one is required to do it. We as an organization can specifically ask for them. We can, if we choose, demand it and we can opt to not work with vendors who do not supply an accessibility conformance report.

The current circumstances that we are working on, we are doing a lot of retroactive accessibility work. We, and I am sure the library is not alone in this regard, work with a lot of vendors whose products we have been using for a very long time before accessibility became the front and center issue that it is now, and the why of that with the consent decree I will be getting to. There are vendor applications we have been using for a really long time where it did not even occur to the library that an accessibility conformance report was something we could ask for. It is something that we ask for now.

It is something that you should ask for. If a vendor says, what is a VPAT? What is an accessibility conformance report to me? If they do not even know, that is a sign that these are people you should not be even working with.

If they supply you with one, that is awesome. However, I am going to go on a little bit of a limb here and say a completed VPAT is not something you should take at face value. It is voluntary when a, oh, thank you, Abigail. In the chat, Abigail just supplies with a UCAT resource on what a VPAT is and procurement guidelines.

I will get to what we are required as an organization in terms of procurement. A VPAT is voluntary and you are relying on that particular vendor’s auditing and remediation process, which may or may not be good. We are dealing with a circumstance right now where one of our vendors supplied us with a VPAT and it was a completed VPAT. It is not correct.

When I do my audit of this particular product, which for the moment I will not name, I find locations where the VPAT is outright wrong. That is either because their auditing process was not awesome or it is because the VPAT is old, which is something that can also happen. Accessibility conformance reports should be a regular thing and they may provide us with an old one. Lisa, thank you for asking that question.

That is a very long answer but a necessary answer. Vendors should supply you with an accessibility conformance report. If they do, that is awesome. You probably should not take it at face value.

You should do a little bit of your own legwork. If they already know what an accessible conformance report is and they have supplied you with one, that at the very least shows that accessibility is something that they are aware of, that they know about, that they feel some kind of obligation towards and know that they need to communicate to their clients. Thank you, Lisa. Did I hit that?

Okay. So ongoing review. Accessibility is not a one-time thing and accessibility audit is not a one-and-done event. The remediation of accessibility issues is also not a one-and-one one-and-done thing.

Accessibility is an ongoing thing. So these are the guidelines that I have included in our digital accessibility program for when applications should be reaudited, and that is a big should because this is a high bar to clear. Things should be reaudited when an application has had an update. So in the case of Drupal, for example, we have two Drupal sites.

Any time Drupal releases an update to its core files or if a third-party plugin has been updated, that should trigger another audit. If the content has been substantially changed, content is where a lot of accessibility issues are. So if a number of pages has been changed, if you’ve got a new person on your staff doing content, if a really important public-facing page has been changed, that page should be reaudited and rechecked for accessibility issues. You should run another audit if it has been six months since the last audit because updates can go by without you checking.

Content can be changed without you knowing that it changed. Six months is a pretty good time frame in which you should feel like another audit is necessary. Or finally, if accessibility guidelines have changed. The web content accessibility guidelines do change very slowly over time, but they do change.

A new version was just published this past spring. That should trigger another audit. Now, again, this is a very high bar to clear. I am the only digital program accessibility manager in the library.

I do have help running audits from people. Most of the auditing is going to be done by me. These are guidelines that I can’t meet by myself, but this is the goal that we are reaching for. This is a good set of standards for when a reaudit should occur.

This is in the text of our digital accessibility program documents. Last part here that I think can very easily go by the wayside is you should communicate your plan and your progress. To a lot of people, digital accessibility work is invisible. For a lot of people, you can do, you can remediate an entire site.

You can get your site up to WCAG 2.2, AAA, and your entire community may not even be aware that you actually did this. It is very important that you take every opportunity that you can to communicate the work that you are doing and the progress that you are doing. Some good opportunities are to initiate speaking opportunities and take advantage of existing ones like this one. I talk at WebNet all the time.

I’ve done talks on many things, but accessibility is what I do a lot of talks about now. I do love to hear the sound of my own voice, but I also like to make sure that I am taking every opportunity that I can to let people know what accessibility is all about, what we are doing at the library to do it, and to let people know steps that they can take. If you are someone who has a role in accessibility in your digital presence, and I assure you that you do, when you have taken steps, when you are starting to make moves towards making your digital presence fully accessibility, do not turn down opportunities to let people know. When you do, make sure you share out tangible results.

If you are using Siteimprove, then you know that Siteimprove gives your site a handy little score. It scores out of 100. If you have a Siteimprove score that you want to share, if it has gone up a lot, or if it’s a particularly awesome score, do not be shy about sharing that. Let people know what you are doing.

Share your wins. It’s super important. When other people see the tools that you are using and the steps that you are taking and the results that happen, it will inspire them to do so as well. The last thing that I do, which Lisa can attest to, is talk about accessibility at every opportunity, and again, risk being annoying.

You should risk being that person who is always talking about accessibility. Every time someone talks about this great application or this awesome website, you are the person who raises your hand and says, is it accessible? You need to be that person. You should be that person.

You should be the annoying person, because even though people go, oh, God, here they go again, that means it’s in their brains. If they look at you and think that is the accessibility person, they are not just thinking of you as the accessibility person. It means you have succeeded in putting accessibility in their minds. That is a win, and you should take it.

Here are some of the challenges to the digital accessibility program. Again, we haven’t rolled it out, so these are things that I am anticipating or things that I just noticed and observed in the accessibility work that I’ve done so far. I am mostly a solo operator, and I put mostly in big, fat parentheses, because there’s a couple people here that are huge allies in this project. Lisa, I see Yvonne is on this call.

Thank you all very, very much for the accessibility work that I know you all do in the work that we all do here at the library. Also, if you are in a small department and you are running, or in a large department, you are running Open Berkeley, you’ve had a lot of your work done for you already. Not all the workers are responsible for the content or the accessibility of your content, but the folks who work on Open Berkeley, I think there’s at least one of you all here. Open Berkeley is always getting their accessibility worked on and tweaked, whether it’s WordPress or Drupal, that particular platform meets a very, very high accessibility bar.

Although in the library I’m kind of remediating on my own, I am auditing on my own, I am always surrounded by people who are doing lots of really great work. But some other stuff that I ran into is a misconception that people with disabilities are someone else. That when you are doing accessibility work, you’re not doing it for somehow people you know or people in your life. There’s a group of people who use assistive technology out there in the accessibility work you’re doing is for them somehow.

And even if you know people with disabilities in your life, in the actual work of remediation, that concept may still be lurking in the back of your mind. I am talking from personal experience, even as someone with a disability myself, that somehow the remediation work that I’m doing is for an invisible group out there. And that is never the case. We all know people with disabilities.

We may be the people with disabilities that we are working for. The group that is people with disabilities is a flexible group. People come in and out of that group all the time. We join the group as we age.

The people that we are doing our accessibility work for is everybody. It is ourselves. It is our loved ones and our family. But we often have to work against this notion that it is some external group and we’re just doing these remediation tweaks for people that we somehow don’t actually know, which is not the case.

For a lot of teams, a lot of IT groups or content owners, accessibility is, quote, one more thing to have to think about. Accessibility should be woven into everything we do. But it is true, like I said before, that we all have our jobs. We all have a limited amount of time and a limited amount of resource.

And for a lot of folks who are learning on accessibility now as a result maybe of the consent decree, it does feel like one more thing getting piled on of all the tasks we have to do. That, to me, is a cultural and institutional failure. It is not a personal failure. It is not your fault that your resources are limited and that you only have so much time.

And accessibility, oh, my God, I have to think about that, too. It is an understandable mindset to have. It still needs to be worked against. It is still something we need to remove as we incorporate accessibility into our day-to-day practices.

But it is a challenge in any digital accessibility plan. Moving on here, there is also a lack of understanding about how to bring accessibility practices into one’s role in the application development process. Again, this is also a cultural and institutional failure. A lot of people are working in very siloed environments.

If you are in the application development process, you may not know what your role is in digital accessibility. That is an unfortunate fact that a lot of us have come to development work without knowing that. But, again, it is something we can learn. Everybody in the application development process has a role from the designers to the developers to user testers to content owners.

Everyone has a role. And educating people about what their particular role is, what is the low hanging fruit that they can grab in order to make their work fully accessible, that is an educational task that, as the digital accessibility program manager, I will be taking on. And then, of course, there is a lack of knowledge about what resources are available to you as someone who has a role in your organization’s web presence. The digital accessibility program here at UC Berkeley has a lot of great links.

There is a lot of great resources that I have listed here. I have done a lot of other talks where I have listed resources. There are a lot of great ways to find out what is available to you as someone who has a role in digital accessibility. When I was doing my slide deck, I couldn’t remember what the word for the opposite of challenges are.

Benefits, supports, good stuff. But here are some of the good things as I step more fully into this role. Here at UC Berkeley, institutional support already exists to bringing digital accessibility into your work. There are resistances for sure.

But in the private sector, digital accessibility is looked at as something that has a price tag and it is looked at as something to deprioritize because making that money requires your attention to be elsewhere. Here in UC Berkeley, in particular, with our history of a relationship with the digital, with the disability rights movement, there is already institutional support. I did not encounter resistance to the idea of developing a digital accessibility program. In fact, I think it was suggested to me.

There is already a culture for it. We do have a culture of supporting people with disabilities, of being community-minded and community-focused. You are not working upstream against a body of shareholders who are looking at their profits and saying how much is digital accessibility going to cost me. That is a big advantage here.

Your organization here at UC Berkeley, if it has a mission statement, it likely already supports accessibility as a value. The library certainly does. If you are moving into this work, you can point to your mission statement and say digital accessibility fits really easily and arises naturally from our mission statement. That is an easy win right there.

Also, UC Berkeley has a complicated historical relationship with the disability rights movement, like I mentioned. The disability rights movement has one of its sparks and one of its initiating moments right here on the UC Berkeley campus. The reason I say it is complicated is because UC Berkeley as an institution, and you can point to this history many ways, whether it is the free speech movement and also now in our relationship with Indigenous communities, one of the first things that the UC system does is it resists before it gets on board. The UC Berkeley specifically did resist the disability rights movement and did push against it before it started to roll with it.

You can leverage that as well. If you are encountering resistance in your digital accessibility efforts, you can point to the fact that UC Berkeley resisted it at first and wouldn’t it be nice if it got on board right away instead of resisting. You can leverage that to your advantage. Lastly, and I won’t say most importantly, but carrots and sticks, this is a stick, we are under a consent decree with the Department of Justice.

Now, let’s talk about that consent decree. The consent decree was entered into on December 2, 2022. The consent decree requires all Berkeley.edu sites and subdomains to meet WCAG, that’s Web Content Accessibility Guidelines, version 2.0 level AA as of June 2023. That’s WCAG version 2.0.

WCAG has different levels, single A, double A, and triple A. Single A is the minimum. If you don’t meet this, your website is not even accessible. Double A, which is better, and triple A, which is super awesome, though for many reasons sometimes hard to meet.

The consent decree requires level AA version 2.0. There are longer compliance timelines for audio and video content. The consent decree is a lot more complicated than that. These are the most salient features for what I’m talking about now.

There’s a link here to a highly readable explanation of the terms of the consent decree. The consent decree itself is a legal document. I’m not a lawyer. It can put me to sleep, but this particular link is pretty excellent.

But there are some issues, in my opinion, with our response to the consent decree, so I’m going to list a few interesting little facts for you. WCAG 2.0 was published in December of 2008. The most current version, which was released, I keep saying spring of this year, but it actually may have been late last year, so if anybody knows or wants to jump into the chat and say, straight me out on this, but 2.2 is very recent. That discrepancy, that gap has a few problems, but the one that I like to point out the most is the first iPhones were released in November of 2007, and they became more and more widespread over the next few years, obviously, and now a tremendous number of people interact with web content on their phones, maybe not even on a desktop computer at all.

So WCAG 2.0, one of the big things that it does not include for accessibility is interactions with mobile devices. The guidelines in 2.0 do not address that. It’s in version 2.1, and I don’t remember precisely when that was released, but it’s in 2.1 that you start seeing the first WCAG guidelines that deal with the accessibility of mobile devices, making sure that items that you view on a mobile device are correct size to be able to be interacted with, that makes sure that content reflows quickly so that a site is actually readable on a phone. I’m sure you all have seen how tiny a website looks if it is not responsive at all, if it’s just rendered on a phone the way it would be on a screen.

So WCAG 2.0 doesn’t deal with any of that, but that is the standard that our current consent decree is asking us to adhere to. And then on top of that, the Department of Justice signed a rule on April 8th of this year designated WCAG version 2.1 as the technical standard for state and local governments. So theoretically, if we were to enter into the consent decree today, if that was the route things actually took, we would be asked to adhere to 2.1. Now the consent decree is signed and sealed, so there is not going to be a retroactive requirement to adhere to 2.1.

But events are leaving us behind here. The fact that the standard that we are required to adhere to is a standard from 2008 means that if you strictly adhere to that standard, you are not going to be producing fully digitally accessible applications for your department or in the work that you do. So the last thing I will say here is adhering to WCAG 2.0 will keep you compliant with a consent decree. Adhering to WCAG 2.2 will make your sites more accessible to people with disabilities.

So in the documents that I and Lisa and other folks have worked on for our library’s digital accessibility program, we are naming WCAG 2.2 level AA as the standard to reach for. I am ignoring 2.0. 2.2 is retroactively compliant with 2.0, so there’s no issue here with compliance with a consent decree. But 2.0 is not sufficient.

2.0 will not keep your work fully accessible to the people who need and want to use it. So I encourage you as you move into this work to work towards WCAG 2.2 to use that as your guideline, and that is what we will be doing in the library as we roll out this plan more permanently. That’s what I got to say. Do you have questions?

I’m going to jump right to a question from Vaughn here who dropped a question into the chat. Will the consent decree require 2.1 compliance at UCB by the end of summer of 2026? I am not a lawyer. I am not an expert there.

I am going to go out a limb and say I believe the answer is no. The consent decree is not going to get rewritten to my knowledge. I have asked the digital accessibility program a couple of questions regarding how the DOJ’s audit of our web presence is going to get rolled out and how it’s going to be communicated to the larger UCB community. I do not have an answer to that yet, so the most honest answer Vaughn is I don’t know, but I’m inclined to think the answer is no.

Any other questions? I’m going to take a look and see. I don’t have the Q&A open. There’s no questions in the Q&A.

We do have about six minutes left in our time. You’re welcome Vaughn. Jesse, it looks like Abigail just put something else in the chat. A good resource for accessibility is the DAP digital accessibility workshop series.

It’s possible. Do you think, Abigail, that maybe that workshop series would address Vaughn’s question about the consent decree going forward? That accessibility workshop, from my understanding, it’s very practical things like sign-improve, captions, color. There’s recordings of all these.

They’re like 15 to 20 minute little touching on a topic and how to make that information accessible. How are your headings accessible? How do you make lists accessible? How do you make transcripts accessible?

It doesn’t look like they have a specific one on that, but on the website somewhere there might be more information about it. Thank you, Abigail. Also, I’ll say a lot of those resources, I have not taken those specific workshops, but I’ve looked at what they covered. They do cover what is considered the low-hanging fruit of accessibility.

No training is bad. No training is going to teach you anything wrong. It’s only going to teach you good stuff. What I see covered in those trainings are great.

If you were able to meet all of those things that those workshops tell you about, you will have a pretty accessible site. Anybody else? Well, then I’m going to thank Jesse for yet another very informative and entertaining presentation to WebNet. I’m going to encourage everyone to come to the November presentation as well.

Jane Lee, who’s on this call, Jane Lee is going to present, and she is new at the College of Engineering. She has a digital accessibility role and she’s going to talk about what she’s up to there and why. Why was this position created? It could be very interesting.

But I want to thank everyone for attending. Thank you for your questions and your attention. And, Jesse, people can find you and ask you directly, right, if they have questions? Oh, they can, yes.

I’m always happy to answer questions. I love accessibility questions. When I get one, I often drop the thing that I’m supposed to be doing and then answer the accessibility question. So, yes, please feel free to reach out with anything you think I might be able to help you out with.

I’m always happy to help. Fantastic. And so I will be sharing the recording and Jesse’s slide deck through the WebNet email list. Alrighty, friends, thank you so much.

Have a terrific rest of your day and I hope we see you next month. Bye, everyone. Thank you and thanks again, Jesse.