How to Maintain Accessibility on a Website with Many Contributors: Amber Hinds

>> Amber: Well, hi everybody, I am Amber Hinds. Welcome to “How to Maintain Accessibility on a Website with Many Contributors.” I’m excited that you’re all here. [audience members chattering] I’m gonna start with a story, I think it’s interesting to learn a little bit about how people have gotten started with accessibility, and I think that this is good backstory to kind of where I’m going on the presentation.

So I have up on-screen an image of myself, it’s an older photo from about 2016. I have long brown hair, and a green flowered shirt on, I’m holding a laptop with a lot of stickers. You can notice, I now have a Mac, I used to have a PC. [laughs] That’s been a great debate in my web agency, which is where I work. I own my company called Equalize Digital, but that is a recent rebrand. Originally when this was created, my company was called Road Warrior Creative, hence I’m standing in front of a map of the country. And I really kind of got into building websites in a very iterative kind of way almost, I didn’t really expect to. I worked in marketing for two colleges when I first got out of college, Marist College and Bard College on the east coast, if you’re familiar with them. I did graduate and adult enrollment at those colleges. And I sort of maybe got my toes wet a little bit in some accessibility on our marketing. But really not, because this was 2007, and while accessibility probably existed, I think most of those colleges that I worked at then, they weren’t really talking about it, and it wasn’t a big thing.

And then when my first daughter was born, she’s 12 now, I realized I didn’t like traveling to graduate school fairs. And so I quit my job to stay home with her, and I was like, “How can I make extra money? Oh, I’ve been working on websites, I’ve been working on marketing, I can do those.” So, I did that as a freelancer for a while. And then in 2016 was when my husband and I decided we were gonna make this into a real business, [laughs] not just Amber doing things part-time while babies are happening, now it’s business. And around that time, we started working with Colorado State University, and that was when we really got serious about accessibility.

Colorado State University at that point in time was starting to figure out, they had just created a whole accessibility committee, they were starting to have official audits before websites launched. And that, for me, was a little bit of trial by fire. So then we figured out how to make websites that are accessible, they’ll pass the accessibility committee audit, they will go live.

And then what happens? We would watch them slowly, over time, become not accessible.

And so this became a challenge for us between, I want to say like 2018 to 2020, we had a lot of conversations. What do we need to do in order to ensure that websites that are edited by a lot of people, some of whom are faculty members or student workers that have no idea about web design, no idea about web development, no idea about accessibility, how can we ensure that they stay accessible? So that’s really kinda the story behind this talk and some of the ideas that I’m gonna be sharing today.

Most of the websites that we launch are WordPress websites. And I have two statements up here. The first one, it’s actually the same statement, but it says, “Nontechnical people can edit anything!” And it has a party emoji next to it. Because coming from, we built PHP websites, where if they wanted to change a heading, they had to contact us, and we had to do it for them, going into a content management system was fabulous, because it gave non-technical people the power to make changes, and then websites could change more rapidly, which is really what needs to happen in this day and age.

But I have that same statement following it, “Nontechnical people can edit anything,” with the screaming emoji. Right? Because the implication there is that as new content gets added, as existing content is edited, in WordPress, you have plugins, as plugins are updated, or someone says, “Oh hey, I wanna add a Twitter feed, I’ll just go install this plugin that pulls in my Twitter feed to the bottom of my website.” Suddenly there are accessibility errors everywhere. Right?

So we have this great thing, which is we’re giving users control over their website, over the content, over maybe even the functionality of their website, but if they don’t have the proper tools, or the proper training, then it’s not going to stay accessible. So —

>> Male: Sorry. Could you try not to move your arms around, I think it’s picking up a lot of sound from them, so just try that now.

>> Amber: I will try not to move my arms. [audience members laughing loudly]

>> Male: Sorry guys. I don’t wanna, but.

>> Amber: Maybe I can just stand behind the podium.

>> Audience Member: Oh no. [Amber laughing]

>> Amber: Okay, so what we’re gonna talk about today is, one, how to educate website contributors on accessibility. Two, some ideas for accessibility governance and what that might look like at an organization that is larger, and has more than one person managing the website. Three, some ideas for proactive website accessibility that can be added into processes to shorten launch times and reduce retroactive remediation costs. Four, I’m gonna share with you some examples of some in-CMS accessibility guidance, not all of which is WordPress. And then at the end, because this is kind of a longer session, we’ll do some Q&A, but I would also really like to open this up for community discussion around some different ideas.

So, I have questions, and I have slides that don’t have anything on them, and I’m hoping we can fill them in together, [chuckles] so we’ll see how that goes. And I’ll try not to wave my hands too much. [audience members laughing]

All right so, Part 1: Training Contributors on Accessibility.

So, we all know, I think all of us sitting here know the why of accessibility, but what I always like to emphasize, and this is something, we work with a lot of clients, not all of whom are in higher ed space, we work with enterprise businesses, nonprofits, a lot of different website owners. And what we have really found is that website collaborators care more about accessibility and making it central to their practices if they can connect it to their bottom line.

And yes, I 100% wanna say that we could just use the ethics. It’s the right thing to do, but the reality of selling accessibility, whether it is to a for-profit business or to a faculty member who has, you know, a class load of six different classes, and has to do research, and has to create all of the documents that students can access online, and oh, guess what? Now you are online, ’cause it’s COVID, and we’re not meeting in person.

You have to draw the line to their bottom line, otherwise, unfortunately, the good thoughts get left behind. And so for us, what we have found, I have a few bullet points up on the slide, and I sort of have them, they’re not numbered, they’re just bullets, but I sort of have them in order of what we have found works best.

So, if someone, whether this is a higher education university or a nonprofit, or whether it’s even a department within a larger company, if you can draw back the connection to having accessibility will help you maintain your funding for your department, for your college, for your research project, whatever that might be, that’s a really big bottom line for everyone. “I will get money if I do this thing.”

Legal compliance is a big one. Obviously, we don’t wanna be scary, but at the same time, legal compliance matters, and it can help.

The next one that works really well, especially in the for-profit sector, is search engine optimization. There are a ton of things with accessibility that help search engine optimization, adding alt text to images, having headings and using them in the proper numerical order. These sorts of things will help with both making content show up in search and also keeping people on the site. If someone can navigate through the site, their bounce rate is going to be a lot lower then somebody who gets there, and they’re like, there’s no skip links, I can’t find out what I want, I can’t add a product to my cart. They leave, and now Google is like, “Oh, I’m seeing a high bounce rate on this site, maybe it’s not so good, I should rank it below this other site that doesn’t have this bounce rate.” So, search engine optimization is a great selling point, especially if we’re talking for-profit businesses.

And then the next one is achieving the fundamental goals of the organization. So, looking at what the organization is. Whether they’re a company, or an institution of higher education, or whether they’re a government agency, what are the goals of that institution? What does that organization have as their mission statement? Or their vision statement? What are their corporate values? Can you draw parallels to accessibility and reaching all people from those value statements? And if so, that’s really going to help them to understand “If I put an alt text on my images, it helps me achieve our corporate value of everyone matters.” Right? So trying to think about whatever that might be.

And then of course the bottom line, which we would prefer to be the first, [chuckles] but in reality it is not, like try to appeal to their ethical or moral compass. Trying to present examples of a challenge that a user might face is really helpful in them creating that empathy and understanding.

So, what is a real life example? So, we want to make it really easy to understand. I have a video, which I’m going to attempt to play, and I believe I have shared my sound, [laughs] but if not, if you are Zooming and the sound does not come through, this is the “Introduction to Digital Accessibility” video that the University of Delaware has put out. There’s link to it on the slide, and it’s right on their campus accessibility website.

>> Male: You don’t have your sound on.

>> Amber: Yeah, I was like, what do I need to do? I need to turn this on, sorry.

>> Male: Don’t worry, I gotcha.

>> Amber: There we go. [laughs]

>> Male: Play it.

[upbeat instrumental music]

>> Video: [Narrator] What is web accessibility, and why does it matter? Misconception number one: web accessibility is for people with disabilities. Actually, web accessibility is for everyone. Everyone is different, we experience the world in different ways. That means we also experience the web in different ways. On desktops, laptops, tablets, mobile devices, inside, outside, in a loud environment, in a quiet environment, with or without assistive technology, everyone should be able to access and appreciate your content. How we see, hear, move, and think affects how we perceive and interact with digital content. Bottom line, the more people that can access your content, the better.

Misconception number two: Only web designers need to consider the accessibility of their content. Actually, everyone needs to consider the accessibility of their content. Web accessibility is more than just websites, it’s any digital content or platform, including social media, apps, PDFs, and presentations, to name a few. Don’t alienate some of your audience, create digital content with inclusion in mind. Misconception number three: web accessibility is optional. Actually web accessibility is mandated by federal legislation. Research programs and institutions like UD must comply with federal accessibility standards like the Americans With Disabilities Act and the Rehabilitation Act of 1973. Discover how to make your content accessible to everyone at www.udel.edu/accessibility.

>> Amber: Okay so. So what I really like about this video, what I really like about this video is that, sorry, I’m hearing echo. All right, maybe not. Is, first of all, that was maybe a four-minute video. So, it’s pretty short. It’s not a big long, you know, let’s do a 20-minute training. Which 20-minute trainings are excellent, but if you’re just trying to explain why does this matter?

And it’s very, it had the misconceptions, right? And it started with the idea that it impacts everyone. And it shows different screens, and it provided very specific examples, in a quiet environment, in a loud environment, on a desktop, on a laptop, on a mobile device. Right? So, it’s really providing very specific examples for the content creators about how this impacts everyone, and why accessibility matters, and drawing those connections in easy-to-understand segments.

And so I think when you are starting to think about how you would communicate this, whether you’re doing it for your own clients, or whether you’re doing it in-house at your organization for the people who create content for your website, trying to think about how can you create bite-size segments.

Now, do you have to have a professionally designed video like this? No, I don’t think so. Maybe you share this one, right, if you don’t have the budget to create your own. I think if you do have a short video like that, that’s super helpful. But it doesn’t have to be like that. But trying to think about short ways that are very digestible and easy for everyone to understand.

Oops, try again. There we go. All right. So, when we’re thinking about who needs to be involved in a website’s accessibility, I think there’s the obvious, where we think about website content editors, so the people who write copy, but there’s a lot of other people that also need to be included.

So, developers that are maintaining the site, and I think it says post, it should say postlaunch. So, developers who are maintaining the site postlaunch, they need to be aware of accessibility. Because let’s say it is a WordPress site, or something like that, whoever runs plugin updates has to able to recognize how to test for ongoing accessibility after plugins have updated, right? Did XYZ plugin, not maintained by our organization, introduce an accessibility problem? So, website developers.

And then the next one would be graphic or print designers. So, as mentioned in that University of Delaware website, and I think many of us in this room know, website accessibility is not just about the website. If you’re linking to PDFs, if you are linking to brochures, anything you put on the web, that’s gonna come into play. And so it’s really important, even if you have someone who’s like, I work here, I only design our trifold brochure, or our print handouts that we give to prospective students, our course catalog, but I don’t design the website at all.

It doesn’t matter. They still have to know how to make those things accessible, because in this day and age, we don’t say, “Oh, no, I’m sorry. I won’t send you a PDF, you have to give your address and I’ll mail it to you.” No, we wanna get our materials in someone’s hands as easily as possible, so we need to make sure that our graphic designers understand accessibility.

And this is really important too if they do get involved on the website, and really understanding like color contrast, that applies to print documents just as much like it’s actually printed out. It applies to signs. If you’re designing a billboard, you want things to be readable. So, really having designers included in this process is important.

Stakeholders and decision makers. It is super important to have stakeholders and decision makers aware, not only of why website accessibility matters, but also what the general guidelines are. Otherwise what happens is you get the, here’s the design of the website, it’s fully accessible, and X, Y, Z president or VP of Marketing says, “Let’s just make this a lighter blue.” [Amber laughing] Right? And so you need them to understand about some of those basics, about heading hierarchy. They don’t have to know about alt texts, ’cause they don’t ever put an image on website, but there are some things that apply to the design decisions that will come into play. And if the stakeholders aren’t aware of why it matters and what those guidelines are, then they’re gonna start requesting changes that don’t support following web content accessibility guidelines.

And then you need to have your support team, for receptionists, if you have someone answer the phone, be involved in website accessibility. And why is this? Because if someone has a problem on a website, they may try to engage through live chat, if it’s accessible, [laughs] they may submit a support form, they may call you on the phone.

And there are two ways this can go. One is the support person or receptionist can just say, “Oh, I’m so sorry you had that problem on our website. Let give you the information you need.” And then they can help that person, which is phenomenal. But what happens if it ends there is that they don’t report the problem through the proper bug reporting channel, and then future users will experience that same difficulty on the website, because no one in web development was notified that the skip links are broken on this one page on the website, or there’s a download link on a page of downloads, and they all just say “download.” [laughs]

Right? So, it’s really important that those frontline support people, whether they are answering the phone, where they’re a support rep on live chat, or someone who responds to support tickets in the support desk, they have to know what happens in our organization when someone encounters an accessibility problem on the website. Yes, number one, they help that person. Number two, how do they report it, and what do they do? That’s really important.

So really, my bottom line bullet is everyone should be involved in website accessibility. Everyone who touches, engages with customers, or has anything to do with marketing needs to be involved.

So, we know all these people have to be involved. How do we train them? So, there’s a few different ways you can go.

Number one is creating a documentation library. There are tons of universities out there that have really great examples of these, you can just like dive into them I think, there are quite a few that are very helpful. If you are able to, in an ideal world, record, or find, but in an ideal world you might record some custom videos. They don’t have to be fancy. It could be you on Zoom, sharing your screen, walking through a few different kinds of tools.

So one, assistive technology. Anyone who is building or editing content on your website has to know how to use a screen reader. They don’t have to be an expert at it, they don’t have to be able to listen to it at six times speed. [laughs] Right? But they have to not be afraid of going into voiceover, or installing in NVDA, and turning it on, and just running through a page, or hitting tab and listening to what it says. It’s really important.

And I cannot tell you how many developers I have spoken with at WordPress events that have never tried a screen reader. I mean, you are a web developer, everyone needs to use a screen reader! But content creators should too. And this is something, so with CSU, is every individual department or college has their own website, and there are thousands of people who work on these websites. And it’s not always the case that a developer is making the change. And so, a content creator needs to know, if they do something major, like install a plugin that adds some sort of functionality, how to turn on and test with a screen reader.

They don’t have to know how to fix it, they might just say, “Okay, I tested this was voiceover, and it said this thing, and it sounded weird.” Or, “It just said button, but it didn’t tell me what the button was.” They don’t have to know how to fix that, but they have to know how to find the problem so they can then flag it to the person in the organization that is able fix the problem for them.

Then the other thing is, whatever content management system the website is built in, have videos that expressly show how to create content accessibly in that content management system. It is helpful to have written, step-by-step instructions, and some people like that, but what I have found increasingly is a lot of people really like having a video where they can just be like, “I don’t remember how to add the alt text, I just want someone to show me in WordPress. How do I add alt texts?” And they wanna watch it in the video instead of having to read the instructions and figure it out themselves.

So, making these videos, again, they don’t have to be fancy, they don’t have to be super edited, but spending time figuring out what are the top problems that might occur in our content management system, and how can we report these videos, and then show people how to add the content accessibly?

So, then the next thing would be either recommending or requiring training courses. So, if someone new is coming on to work on the website, they have to go through a training course. Maybe you have a very large organization, and once a month, or once a quarter, you have a website accessibility training course that you run in-house. That’s awesome. Maybe you don’t, and so you might say, “Hey, through the IAAP, we’re all members, you can get the CPAC training course through, is it Princeton? It’s basically included for free!” [laughs]

Anyone this in our membership can do that, right? So, if you’re gonna work on our website, you have to go through this training course. You don’t even have to, maybe you don’t tell them take the exam, but doing the course. So, either finding courses that exist, or creating courses that you do regularly, that’s very helpful.

And then the next thing would be creating some sort of checklist or quick reference guides something that can be printable, which sounds crazy, but there are a lot of human beings I have found who really like to print things. I’m just weird, like I hate paper, I don’t even think printers should exist anymore, but there are people that really like, they benefit from that. So, creating a short reference that will tell them every time you create a new blog post, check for these few things, right? So, having that available for people who do wanna print it is super helpful. I’ve seen things where like, I’m meeting with them in person, and they have it taped on their desk next to their computer. Right? So, that kinda thing can be really helpful.

So, I do have a few documentation examples, which I think we have a couple of time, a few minutes that we could look at that. So, Harvard is one that I think has a really good example if you’re looking for, “What could our internal website look like?” They have a quick start guide, right? They have guidelines grouped by who you are. So, content creators, developers. You can sort of self-select into, “What do I think I need to know?” And then they have some news and information.

I think that this one is a really great example, because they have training. So they have, again, on-demand training, which would be those recorded videos we talked about, they have regular trainings, ’cause they’re a large institution, they have different resources and specific techniques, and things that you can learn. So, if you’re trying to get inspiration, I think this one is a great resource.

I like the University of Florida’s Quick Guide to Digital Accessibility. And the reason why I really like this one as an inspiration is, so I have opened up this PDF, so again, I have not tested this PDF, I do not know if this is accessible, [audience members laughing] but I’m really hopeful that it is, it’s a great guide, so let’s look.

But what I have at the top of the screen, in case you can’t see this, is they have a section about, it says in a heading, Avoid “Click Here.” And they have a subheading for a poor link example. And they have a sentence, “Donald Tapscott, in his paper, Growing up Digital.” and then it has a full, naked link. So, a naked link, if you’re not aware, is something that says http: blah, blah, blah, and it visually shows it. “Says these students.” And then they have a link, which we’ll go to in just a second, that says, “Listen to a bad example of audio from a screen reader.” And then they have another subheading for a good link example. “Donald Tapscott, in his paper, Growing Up Digital” And in this instance, Growing Up Digital is linked. “Says these students.” And they have, “Listen to a good example of audio from a screen reader.” So, I’m gonna click on the link to listen to the bad example. And.

>> Digital Voice: Tapscott and his paper growing up digital quote link links to an external site HTTP colon slash slash w w w dot ncsu dot edu slash meridian slash jan98 slash feat underline six slash digital dot html links to an external site says these students.

>> Amber: Okay so. Okay. So, that link that I just opened provided a screen reader example of what a bad link sounds like. And I think that this is a really great example of how you can, just in a short snippet, make it really clear for someone. And they have the other example, where it just reads it out like normal, and it would say, “David Tapscott, in his paper, link, Growing Up Digital, says these students.” Right? So, it’s much easier to understand.

And so we’re trying to figure out, how do we explain this to somebody who doesn’t know about accessibility? I love providing examples like that, because anyone who listens to those two things is gonna instantly say, “Well, which one do you prefer?” “I prefer the second option where it’s not a naked link.”

So, trying to think about, as you’re creating your documentation, where are just small, tiny snippets of things that you can provide that just obviously contrast and show people.

The next link that I have clicked in my slides is, it’s kind of small font, but it’s the University of Western Australia. Let me see if I can zoom in a little bit here. And what I like about this, is this is specifically, it’s a page titled “Advice for staff: Web accessibility.” And this is where I was talking about how we have to get support staff involved. So, they have a subheading for support, and they talk about who are all the different groups that provide support.

And then they say, “What is our complaint handling procedure?” So if we get a complaint, what do we do? They say, “We assess the complaint.” Use empathy and willingness to replicate the issue, that’s very helpful, right? So first, you try to repeat the issue, see if you can repeat the same problem that the person had. And they talk about empathy, and how you might communicate with people that have accessibility concerns.

And then how would you then respond? So, if you’re unable to repeat the issue, make sure you at least understand it. If you can do it, we want to figure out, you know, what someone might be able to do to get access to the resource. So, they have a lot of that kind of stuff. And then they just talk about, it’s a valid complaint, what’s next. And so they talk about, “what happens in our organization.”

So, if you’re trying to figure out putting together a guideline for your support people and in your organization of what to do when an accessibility problem is identified on your website, I really like this as an example, because it’s very clear. Like, this is how we respond, these are the steps we take, these are the different options that we have for moving forward. So, this is a great example.

And then if you are on the website and you’re thinking about putting together guidelines for your web development team, 10up is a WordPress development agency. You may have heard of them, because they built the most recent whitehouse.gov site. And they have on their GitHub, so this is their engineering best practices guide. And one of the things that I like, basically, if you cannot see this, I’m showing the table of contents, and it has different sections with subheadings, and then links to different areas.

And what’s important about this is you can see that they have Markup, and the second item under Markup is Accessibility. Under CSS, the second item is Accessibility. There’s accessibility in a couple other places, accessibility tools, different things. And so they’re really taking examples and saying, “For each of these different sections, this is how we, as developers, address accessibility.”

So for example, I’m just gonna click on the CSS accessibility section. And it’s jumped me down to that section, and we have a heading for animation, and they talk about how not every animation brings pleasure to the end user. [laughs] In some cases it can cause harmful reactions, so we always wanna make sure that we’re respecting prefer-reduced-motion CSS media feature, right?

So, they’re talking about different things relevant to that in accessibility. So, you wanna think about, across your organization, who needs the guidance and where, and then fine tune it for different groups and different audiences.

All right. So, once you’ve created your document, ideally you’re planning live training sessions. We generally recommend, when we do them, when we’re launching websites, or as part of our consulting work, we group sessions by role. So, we’ll have general awareness sessions that everyone attends, content-specific training for content creators and designers, and then more technical accessibility for developers.

The worst thing you can do is say, “We’re just gonna have once a month an accessibility training, it’s gonna cover all these things.” Because what happens is your content creators get in the room, and you start talking about CSS, and respecting preferred motion, right? Or how do we write button tags in the right way, and they just glaze right over.

And all of a sudden, like they can’t hear anything else, ’cause they’re just thinking, “This is overwhelming, this is scary, I can’t do this.” So, it really is important to group your live training sessions so that you can have content appropriate to the skill level, or technical level is maybe a better way of putting it, of the users. And only really teach them what they need to know, and if they get very excited and they want to learn more, you can point them to resources, but don’t, by default, group everyone into the same training.

And then recording sessions for later reference is very helpful. You can put them in your library, or you could just send them out to the people who attended that specific one, that gives them the ability to look back.

And then scheduling regular refresher or update sessions, this is really important. I think a lot of us in this room know, accessibility is not a one time thing. Well, accessibility training is also not a one time thing. People get busy. People have other roles as part of their job that sometimes are the majority of what they do, and editing the content on the website is something that maybe they do once a quarter. It’s easy for them to forget. So, you want to not just have that initial training process, but you wanna figure out, at your organization, what is the ongoing training cadence that makes sense based upon the number of people you have, what does a refresher course look like? And have that really planned out, because it can’t just be a one-time thing.

And why can it not just be a one-time thing? Beyond the fact that, people, if they’re not in it every day, might forget, also you have to remember that you may have turnover at your organization, you may have new staff join, and so you really have a process for ongoing accessibility as your team changes.

So, when we approach accessibility training in the new build, I was like, this is interesting. What I have up here is a timeline that shows how we approach new website builds, it has different sections, and the different parts of the builds mapped out. And it starts for us with Discovery, then we go to Content, Design, Development, Test & Debug, User Testing and Remediation, Launch, and then we have an additional Training & Post Launch Support period. And above all of these sections, I have an arrow that points both directions, it’s very big, and it says “Accessibility,” spanning the entire process of the build.

So we work with external clients; we’re not building, I mean we have an internal website for our stuff, but what we are primarily doing is helping people with accessibility on new websites that we build around their current website. And it would be easy for us to say, “We’re gonna handle all of the accessibility, and then we’re going to leave your training until this. We launched the website, now we train.” And what we have found is that that causes a challenge for us in a few spaces.

One, when we start designing a website, and we’re sending them over designs, we have those things where we talked about before with stakeholders being like, “Well, why can’t it just be this light gray color?” Right? We have problems where, in development, or maybe I should say in Test & Debug when we hand them their website, and they’re all like, “Well, can’t we just have all these things go shoom, shoom, shoom.” Right? Flying, and I waved my hands again. [laughs] [audience members laughing] That is literally what —

>> Male: Not at us.

>> Amber: Yes. [laughs] That is literally what they ask for sometimes, right? And so what we have really found is that accessibility starts early, and it starts for us during Discovery.

So what does this mean in our different phases? So during Discovery, when we are on calls with clients, and we’re talking to them about, “What does this website need to do? Who are the audiences that are going to use this website? What are the user journeys that people are going to go through? What are some inspiration sites that you really like?” We’re talking about accessibility.

Then user journeys. We have to map out user journeys, respecting people have different abilities. So, if we say they have to submit a form, we need to make sure we know that user journey. This has to be something accessible, right?

Or if they say, which we’ve had come up, with a government agency, where they said they submit this form, and then they schedule a phone call with one of our team members, like a literal phone call, and that is how they move forward with getting their government benefits. And I’m just like, well, what happens if that person is deaf? Can we create an alternative way? Because they might not even have a phone number. Do we have to require a phone number in our fields? What if they don’t have a phone number? How can they move forward with getting their government benefits, right? So, thinking about user journeys in that way.

When they show us inspiration sites, this is my subtle accessibility training for them, and they don’t even really realize, we’ll look at a site, and they’ll be like, “This is cool.” “Ooh, this doesn’t look accessible. Oh, I dunno if I would do that way, I’m might make it have darker color contrast.” Right? Just very subtly. Let’s hear what you like about this website, but let’s start to get you thinking about what on this inspiration site might not work. And so we start there.

With content, we sometimes write content for clients, but not a lot, especially online during enterprise builds. And so they will have a training session before they even give us content, we get content before Design in our process, because we expect them to provide us content with the appropriate headings in the appropriate heading levels. And they get trained on how to do that in our content collection system.

And we train them on link anchor tags, all of those things. So, what’s helpful about that is the content team has learned about accessibility, all the way over here, and they’ve had a review of their content before we even design. And we say, “Hey, look, you’ve got picture links. Can you go fix that?” Right? Before they even get to, “Our website is launched, and now need to edit it.” And so this is really reiterating throughout the process, and that helps to cement and help them learn better.

So, I have a GIF up here, [chuckles] of a very sad kitten, and the kitten says, “I wish I could enjoy that video with the other kittens, but it isn’t captioned.” [man laughing] And on my slide I say, “But that’s not enough.”

So, we’ve done all this training, and we’ve put together resources, and we have PDF sheets that we hand out to people that are quick guides. And what happens? It’s still not accessible. Problems still come in, right? Because we’re all human, mistakes get made, someone moves quickly, someone new edited the website that maybe didn’t go through training. So, this is where accessibility governance comes in.

So, what you need to do is create organizational policies that help you to create what your plan for maintaining accessibility is. Some questions that you are going to answer, and I’ll talk a little bit more about these in just a minute, but who is responsible for ensuring ongoing accessibility? How will we measure success or acceptance levels of conformance? What tools and methods will we use for reporting? And how restrictive of publishing will we be? What happens if accessibility problems go live?

That first question, “Who is responsible for ensuring ongoing accessibility?” You need to ask. Is it the original content creator? Or is it someone else at your organization who comes along later and audits? Is it one person? Is this only one person’s job? This is the accessibility person in our company. Or is it a committee? Are you including people with disabilities, and real users, in this process? Is this part of people’s everyday roles, which means it will be super important to them? Or is this an extra task that you said, “Hey, beyond all these great things you have to do in your job, you also need to do this.” Right?

And then does this one person, or this committee, these people, do they have the authority to take action when accessibility problems are identified? So, these are all the questions that you need to ask for your organization.

And then the next big one is, “How do we measure success or acceptable levels of performance?” Is it a total number of errors? A total number of errors across the entire site? On a per page basis? Is it error density? Which I would describe as the number of errors relative to the number of elements on a page, so therefore a page that is very short but has two problems is actually a worse page than a page that is really long with those exact same two problems. Is it the total number of pages with errors out of the total number of pages on the site? Are we giving higher priority to certain problems over others? Like missing alt texts, or ambiguous link anchors is more important to us than headings out of order? Or buttons that are actually divs [laughs] are way more important than anything we just talked about. Right?

So you need to really talk about this internally in your organization and decide how you’re gonna measure it. Because if you do not have a ruler or stick for measuring against, it’s really challenging to know if you’re being successful at maintaining the accessibility on the site. Yes?

>> Male: So when you’re saying errors your definition of errors, is it like what counts as an error in WAVE? I mean, ’cause like from where we come from, zero is the acceptable number. [laughs] And are you talking about grammatic, or reading level? I just wanted like to understand what angle you’re coming from.

>> Amber: So, the question was, for people on Zoom, when I’m talking about errors, am I talking about errors in WAVE, or am I talking about something else like reading level, or grammatical errors, or what might it be? I feel like we could give a whole talk on measuring this.

>> Man: Yeah. [laughs]

>> Amber: I could give a side pitch later for Karl Groves, he had a presentation on this at CSUN, and he’s like giving it virtually for my meetup in June. [chuckles] But like, I feel like we have a whole talk about that. Right now, at this moment, I am supposing that your organization has to decide what is an error, and what is a problem, but not an error.

>> Male: So, I’m saying when you’re talking about the guidelines, like what to check, you know?

>> Amber: So, the way we approach it, everything we build, we go for Web Content Accessibility Guidelines, WCAG 2.1 AA. That is our standard. Technically, some organizations only have to meet 2.0 AA, and that is legally fine, and if their organization wants to do that, then maybe that is fine. There may be others that say, you know, I was just talking to someone from a county in Florida, and he said readability and reading level was really important to them. And while the WCAG guidelines for readability is more of a AAA guideline, they didn’t care. Everything had to be ninth grade or lower, or they wouldn’t publish it, ’cause they’re like, “We’re a county government, like anyone can be on our website.” So, I think you kind of have to decide in your organization what makes sense based upon the audience that you’re serving.

>> Male: Your legal responsibilities.

>> Amber: And your legal responsibilities in a lot of those things. I would say that starting with web content accessibility guidelines is a really great starting point, and it’s measurable, which is what’s good about them. But there may be other things beyond that, that impact usability that don’t show up as a guideline, and that might be very important, and it might become a guideline that you have.

So then you need to talk about, so this is kind of getting into that, what tools or methods will we use for reporting? So, are we gonna use automated testing, or manual testing, or some combination of both? What are the frequencies of the tests that we’re going to run on our website? Are they gonna be weekly? Monthly? Quarterly? Maybe it’s weekly automated scans and quarterly manual testing. Are we gonna use a SaaS solution, like Site Improve, or Monsido, or PopTech, something like that? Are we going to use something that is free? So, maybe we’re just gonna use Wave’s Chrome extension, and that’s it.

Or are we gonna custom code our own accessibility auditing solution? Again, are we gonna use something that’s in the browser? Are we gonna use something that’s on a separate website? So as I mentioned, Site Improvement, Monsido are two tools, to see the report, you have to go log into that website. Or are we gonna use something that’s actually in our CMS? And then do we need to track error counts over time so we can see trends either up or down? ‘Cause some tools, so if you just use the free Wave Chrome extension to address the problems, unless you literally fill out a spreadsheet every time and say, this is the URL, this is the count, right, you’re not gonna have any sort of history from that.

But if it’s important for your organization to have history, then you might choose a different tool, or you might say we’re using this free tool, but this is the process in which we record, so we can then report on it over time.

And then do we need to notify additional stakeholders? So do we need something that sends an email every month to the VP of marketing, with the count of accessibility errors or problems that have been identified? Or do we create a process manually where we do this, or we report on it at our panel company meeting, and we talk about our progress? Who are we notifying, and what tools or methods need to be used?

So, we talk a lot about automated tools can only identify, depending on who you ask at which company, anywhere from 20% to 50+, [laughs] if you’re Deque. But regardless of what that percent is, most of us in this room probably know that automated tools cannot find everything.

So, why would we use automated tools? Here’s why. Because automated tools can definitively identify some things that are obvious WCAG failures, and they can then speed up the identification of many problems in bulk, and rapidly provide a full set assessment. It may not be a 100% coverage of what the problems are that exist, but it can most certainly tell you a large percent of problems very quickly.

And then you can have your user testers, or your professional auditors, spend time identifying and reporting on problems that cannot be identified automatically. Right? I don’t need to make a blind person go on my website and tell me, list out 500 images missing an alt text. That’s a waste of their time, right? What I wanna know is, can they get from Point A to Point B, and can they find the information they want in a usable and quick way? Or are there things they get confused about? Right?

So, that’s why automated tools are helpful. And that saved time is then saved cost, which is really important when we’re talking about budgeting for accessibility.

So, the next thing you wanna think about is how restrictive of publishing will we be? So I have been involved with a university where if the website failed, if the department is publishing a new website, and if it fails the accessibility test from the accessibility audit, they won’t allow it to go live. Which sounds great, assuming they have support for the content creators who created all this content. Because I’ve actually been in a situation where they’ve said, “You know what? We don’t know how to fix this. No one in the department is telling us how to fix it, we don’t have time, we don’t have budget for you to fix it, so we’re just not gonna launch our new website.” Right?

So, you really wanna think about it. Are we blocking a completely new website? And maybe you are, but you need to be able to explain that, and you need to have a process. Or are we just blocking the publishing of new pages? So, there are certain tools in CMSs where you can say, you can’t hit update, or you can’t publish of this new blog post if X, Y, Z problems exist.

Are we blocking uploading PDFs or other file types? This is something that I know one of my friends, she works at the web services team for a University in New York, and she built something that attaches to WordPress, and if anyone tries to upload a PDF, it hijacks the PDF, does not put it in the media library. It emails it over to someone in their auditing team, and then the faculty member, or whomever tried to upload the PDF, gets an email that’s like, “You have a 10 page PDF, here’s your price for us to audit it.” [laughs] [man laughing] And then once it’s been audited and remediated, then they add it through an automation sequence to the website, and then it’s available on the website.

So, are you going to like block certain things that you know cause common problems? Are we going to limit access to headers, footers, and sidebars? So, are we gonna certain content creators can only edit this main area?

So, what happens if accessibility problems are live? If something slips past restrictions and goes live, how are you gonna handle it? Is there a warning process, or will it immediately be taken offline? What are the implications of immediate take down? Is it bad SEO? Is it a 404 problem ’cause this is a page that just got marketed a whole bunch? You know, what will happen if we take it down immediately?

What policies do we need to have in our organization for, quote, “repeat offenders?” People who are creating content that is not accessible, despite us coming back to them and saying, “you need to do XYZ,” and they just don’t do it. So, you need to have all of these things in place.

So now, I’m gonna talk a little bit about proactive accessibility. How are we on time?

>> Male: We have about a half hour.

>> Amber: Okay. Good, I am on track. [laughs]

>> Male: You’re on track.

>> Amber: All right. So, a lot of the tools we talked about, and the governance we talked about, was a little bit more reactive. Monitoring or trying to watch for problems, and then coming policies about how to handle those problems. Running monthly scans and performing manual audits of live content, and then fixing problems. This is what I call reactive remediation, we wait until the problem is live on the website, every month we have our SaaS software scan, we find the problems, we go back and fix them.

Remediation is always more costly than doing it right from the beginning. It’s always more costly than doing things right from the beginning, so you don’t want to reactive.

So, we talk a lot about shifting left with accessibility, moving it as early into the process as we can. And so what we want to do is we wanna give our content creators the tools to identify problems in the content management system as they edit or create new content. Because even if they have a PDF, or a printed out quick list guide, or a website that they can go to, and I said, you know, it’s important to have these, if it’s not right there staring them at the face when they go and add their content, they are likely to miss something or forget something.

So, I have an image up here of our tool, we’re gonna look at a bunch, but it’s basically showing a laptop with WordPress on it. You can see we’re in the admin, and there is the WordPress admin bar. And then right in the middle of the screen, really big, is a report that shows 80% passed tests. And it’s kind of small, so probably you can’t read, but there’s like 18 errors, 12 contrast errors, 16 warnings, and 3 ignored items, and it says 12th grade reading level. So, this is actually in the CMS.

Really, the idea behind this is you don’t want people to have to reference a document or remember guidelines, you don’t want them to have to wait for a weekly or a monthly scan, you don’t wanna make them go somewhere else to check for separate websites. You wanna make meeting accessibility easy for people who are not super familiar with it. So, I have a few tools that I wanna show you that I think are useful and helpful.

So, we have a free WordPress plugin called Accessibility Checker. And what it does, this is, I have up on the screen right now, I’m in WordPress, and it’s showing the block editor, sometimes called Gutenberg. And the page is being created in there. And at the bottom of the page, it puts a report.

It’s very similar to if you’ve used a tool like Yoast SEO, or Rank Math, or one of those other SEO tools. And so a lot of content creators are used to that, I create my content, and I go look at my SEO tool, and I figure out, “Oh, I forgot to put a link to an external site. And I forgot to enter a meta-description.” This is the same kinda idea, trying to create something where they’re editing content that as they hit Update, or as they hit Publish, it scans, and then it shows them errors.

So on this particular page, which this is a big website, so it has a lot of kind of random errors on it. Right, so Broken Skip or Anchor Links, as I mentioned. So, there’s a lot of links here that are just hashtags, right? But it’s flagging them, because it’s like, “Well, this doesn’t have an ID that matches.” This would actually be a broken link. And so they can see what they are, they can go up, and they can find the problems, and they can fix it, and then eventually with the goal of having their summary say zero errors, zero contrast, zero warnings. And maybe you ignore some things ’cause they’re a false positive.

The next one that I wanna show you that is from Princeton University, so if you use Drupal, this is available to you. So, this is the demo of Editoria11y, which is spelled, if you can’t see it, E D I T O R I A 11 Y. And what this does is it adds a front end text on Drupal websites. I have hit an element, and this is, I have done some keyboard testing, and it does work fairly well with keyboard only without a mouse. So, it puts a little box in the bottom that I can activate, and it will highlight items for me right on the front end of the Drupal website.

So I can see right here, it’s highlighted something in yellow. Which they use yellow, we won’t talk about color alone, [laughs] but they use yellow to signify warnings and red to signify errors. But they’ve highlighted what looks like an empty box, which if I do not have this turned on, I might not even notice that I accidentally had a heading there and didn’t type anything in, right? But they’ve highlighted this and I can see, “Oh, this is an empty heading.” So I can fix this.

And you can sort of see, here’s an image that does not have alt text on it. And so this tool, it’s on GitHub, so if you have Drupal and use this, this is something that you can add to your Drupal sites for free to test them for accessibility.

In WordPress core, I have two screenshots up that show you two things that have been added recently to WordPress core. Well, one is a little bit more recent than others. But in the block editor, there is a setting on the side where you can choose, I have a paragraph block open, and we can choose the color that we want for the text and the color that we want for the background. And in this instance, the text is gray and the background is white, and it’s kinda a light gray. And there’s a warning now that shows up in WordPress core that says this color combination may be hard for people to read, try using a brighter background color and/or a darker text color. Same thing on the image settings, we can add alt text, and below it, they have some guidance. “Describe the purpose of the image.” Which is an external link, it actually goes over to, it’s a W3C guidance on, I think it’s the alt text tree decision, where you decide if an image needs alt text or not. And the board says it says leave empty if the image is purely decorative.

So, the first two things I showed you are Accessibility Checker plugin, and the Editoria11y for Drupal. These are tools that kind of test and prevent, provide reports right in the edit experience. What we’re starting to get into now is providing guidance as content is added. And I think in the long run, and this is something I would love to do, but we’re gonna look at a couple of these, because I think this is ultimately the direction that will be most useful for our content creators, which is when you add an image, you’re presented with this, and it says, “Put in alt text.” And in the long run, I think it’s even better if maybe you have rules where you say, you either check a box that it’s decorative, or alt text is filled in, otherwise, the image cannot fully be added to the page, or the page can’t be published.

The next one I wanna show you is University of Illinois has been working on the CKEditor, which they’ve actually, they use it in a WordPress environment. So, they used the old version of WordPress with the Tiny MCE, and they replaced it with CKEditor. And this is their demo for its a A11yFirst for CKEditor. And what they have done is they have added some of that accessibility guidance right into it. So, I’m gonna show you for example, this right here, we’re on a heading, and this is an h2 heading, I’ve opened the dropdown that shows us it’s an h2 heading. And if I wanted to go here and add another heading, so I just entered, I typed this as a heading, and if I select it, because I wanna turn it from paragraph to heading, you’ll notice that I have the option of turning this into an h2, or I have the option of turning it into an h3 heading. I cannot make it an h1, because our page title is supposed to be an h1. It’s literally not available to me, and there’s already one up here. I also can’t make it an h4, because an h4 can’t follow an h2. So in this instance, I must now either make it an h2, or in this instance, I made it an h3.

So is an example, I think, that is really cool of what you can do with your content management system, depending upon, you know, if you’re a developer, if you have developers at your organization, where you can start to actually corral users into making certain decisions so that they almost only have accessible options.

Another thing is, let’s see, I think on our image. Can I edit this? Right so, this is sort of what I was mentioning before. I’ve clicked on the image, and it opened up the image properties dialogue. And it’s the same thing where they’ve said, “What’s the alternative text?” And they put in parenthesis, spoken by a screen reader, which makes it even more clear what does alternative text do. Or, again, I can check a box to say it does not require alternative text. They also say, is a long description needed, and if so, where is it required? So if the alternative text is not gonna be sufficient, then we could say we’re gonna add it, it’s in the document before the image, it’s in the document after the image, it’s both before and after the image.

But really creating something in the content management system that guides people into making more accessible decisions. So, another one that I have some screenshots of is the Gravity Forms. Gravity Forms is a premium WordPress plugin, and they used to build forms, and they recently went through a whole process, not connected with that at all, but I thought this was for me. They got an external audit, they went through, and they figured out, “What do we need to fix so that the output of our forms are super accessible?” And they found out that there were certain things that they have within their plugin that, for backwards compatibility reasons, they couldn’t remove, like certain fields. ‘Cause if they removed it, it would break, I don’t know, millions of forms on the internet.

And so they have done the same thing, where they’re adding guidance into their tool to help people make the right decisions. So, I have two screenshots up here. The first one shows conditional logic. And they have a setting that allows people to use conditional logic to show the submit button on a form. So, we’re only gonna show the submit button if someone says they’re in the United States, because it’s our job application, and we can’t hire people out that aren’t legally able to work in the United States. Well, that could be really confusing for somebody, like it’d be better to just have a message or something. Right? And so they couldn’t just get rid of the conditional logic on the submit button for that backwards compatibility reason, and so they now have added a warning that shows up if you turn it on that says, “Adding conditional logic to a form submit button can cause usability problems for some users and negatively impact the accessibility of your form.”

There’s another one where they’re showing someone has added a name field which has First and Last below it, but they left the top blank. And they’re saying an empty label violates WCAG, please use descriptive text for your label. So, they’re really providing guidance. And so if you have the ability to either select tools that do this kind guidance, or add this kind of guidance into your content management system, that makes a huge difference.

So, before we dive in and I do a little community sourcing, I wanna see what questions can I answer? No?

>> Man: I have a question on one of the slides that appeared, how strict can we be on publishing? And what is the best option for that?

>> Amber: So, the question is, how strict on that, what is the best answer to how strict should we be about publishing? And again, it’s a little hard, ’cause I think it depends on your organization. Internally at ours, because we are accessibility focused, [chuckles] I don’t allow, but my content writer, she’s not certified. You know, she knows a lot about accessibility, but she doesn’t have advanced training, she has to, we use our own plugin, and it can’t have any issues flagged in there. And she has to do also just a Wave Chrome check on a preview of her things just to make sure. And if there’s problems, it’s not allowed to go live right? If she doesn’t know how to fix ’em, then she has to come ask someone on the team who can.

I mentioned before about the university that hijacks PDFs and doesn’t allow them to be uploaded, that particular university was sued for accessibility, and went through a very costly process, and so they got very serious about things like PDF accessibility. I know we all talk about, or are aware of some of the issues with YouTube videos from universities not having captions, and a lot of them decided they’re just gonna take them all down and not have open courses. Because they said the cost of putting corrected captions on these, we can’t do right now. Right?

So, I think it sort of depends on your comfort with the legal risk, your comfort with the fact that people in your audience might encounter inaccessible content on your website. If you serve a lot of people with disabilities, and you know that, I mean, we all serve people with disabilities, but there are some organizations where that is what they do, then it matters a heck of a lot more. [laughs] Right? And so, I don’t know if there’s a one size fits all. I wish I could say, like, here’s a list of eight things, and we should block everyone from publishing any content if those eight things are not met. Right? But that’s harder.

>> Male: Yeah, it is. I’d be curious what other people in the room think about that question?

>> Man 2: We ask legal and our accessibility department.

>> Amber: Okay so, someone said they ask legal and their accessibility department. [chuckles]

>> Man: We see a lot of people who started with the shift left approach that you mentioned earlier. So all the content that is going to be published must be accessible, out of like 500,000 pages out there in the production, so we can all go there, and fix it, and then meet all of them at this point. But in case you can start making accessibility by sometime in the future may be accessible, right? So, for example, sometimes PDFs, even though we are implementing the shift left, there is a businessman that comes like, I need to go to market tomorrow, I want this video to be published, though it is not accessible. So, we always see these kind rush hours, [laughs] so we said, “Okay, you can go to the production, but we’ll give you two weeks of time, and we can republish it in two weeks.” [man continues speaking distantly]

>> Man 3: Like a waiver, basically.

>> Male: Yeah.

>> Man 3: We’ll revisit it.

>> Amber: So he said, just for people, sometimes they go, I’m gonna repeat, ’cause I think people on the Zoom probably wanna hear. So you said sometimes people will come to you, and it’s a rush, and so you’ll give them a time limit, “We’ll push this to production, but we have two weeks to fix it.” Yeah, I mean I think that works as long as you hold, like stick to that. ‘Cause the biggest problem is when organizations say, “Well, we’re just gonna release this feature, and it’s not accessible, but we’ll fix it within two weeks.” And then it never gets fixed.

>> Man: Yeah.

>> Amber: So, that’s like that’s the biggest thing. And I feel like for us, like the way we talk about it with some of ours, and for some of our clients, is really assessing, like, the line is new things. So, maybe you’re working on a timeline and a process to remediate old content over time. Maybe your annual report from 2000 is not an accessible PDF, and you’re not sure if that makes sense to go remediate that. But any new PDFs that you add, or any new websites, any new webpages that get created, are not going to have accessibility problems on it.

>> Man: There are people in the market who especially want to access, this legal requirement of accessibility, and they both are big companies. Okay, your PDF from 1998 is not accessible, [laughs] we’ll send you a legal work case. [laughs]

>> Amber: Yeah. I think that’s where having an accessibility statement, so you said what, your PDF from 1990 is not accessible, I think, you know, that’s where maybe you have an accessibility statement that acknowledges some of our older documents are not. And just have a process for people to contact you, and then you like, okay, we can remediate that one, and we will hand you. Right? Like you can request things from a very long time ago. It gets harder with documents, like libraries I’m sure experiences this, ’cause they probably have a lot of just like scanned books or scanned magazines, right? So, the whole thing would have to be retyped. [laughs] You know, for a long time ago. So I thought it would be interesting to know, and I was gonna, I guess I have to actually go out of this. Would anybody be interested in sharing ways that they maintain accessibility at their organization?

>> Male: Sure.

>> Amber: Yeah, what do you do?

>> Male: So, we do have a vision around this first off, and then we’ve actually incorporated this into our definition of done. We’re an agile, iterative company, so every sprint, every PBI, or story, or every faction, has to have definition of done included for usability, as well as WCAG compliance. That includes documents, that includes content. We have, you know, 15, 18 scrum teams, and all of them could be a contributor to a website, a single one for a component. They own their component, so they are accountable to making sure their components are accessible before they get integrated or merged. And then we also do quarterly scans and production for VPATS. But all of the scanning is done in CICD every time something is checked in, so that’s looked at continuously, and they can take that feedback immediately and remediate.

>> Amber: Awesome. Hopefully I’m getting this right. Continuous scanning and quarterly audits, right?

>> Man: Yes. Quarterly VPATS.

>> Amber: Would anybody else be interested in sharing? They do?

>> Male 2: So we actually do, we’re really, really young, [laughs] we have some immaturity, so we actually did this in phases for doing it. So, the way we did it was we actually did the automation gate check. That automation gate check started as, “Did you actually run accessibility scan? Yes or no.” Right? ‘Cause the pushback of being like, “hey, you can’t have any critical or serious issues go out the door,” will make everybody lose their mind right away. So, we did a soft gate check, then worked into a harder gate check. And then actually what we did from there is we, similar to what he had mentioned first time through, like the scrum teams, instead of 15 teams, we had like 1,500. [laughs] So, what we started to do is actually introduce small manual testing they could do on their own. ‘Cause we had to do accessibility in smaller chunks to make it kind of get bought into. And so, what we had to do was start the accessibility scans, think into the hard checks, and then give them kinda small manual testing. So, “Hey, here’s a keyword test. This should be keyword operable.” Right? And what we found is, kind of naturally off of that, screen reader testing works a lot easier. Hey, I’ve already been doing these manual checks with just keyboard only, no assisted technology. Now when I start turning that on, it’s a little easier for me to be able to do that. So, we’re not there yet, but the final piece will be including those small manual tests. It’s part of our definition of done too, so that’s kind of what we’ve done along the way. And again, it’s hard when you’ve got a scale that’s so massive. That’s what happens. So something like that really helps kinda introduce accessibility easier than, [chuckles] I’ve worked it multiple places, so I’ve done the like, “Hey no, this can’t go out to production.” And everybody comes at you with pitchforks and torches right after that, like, no accessibility is terrible. So, kind of introducing it as a slow roll, like building up over time, has worked wonders for us.

>> Amber: All right so, slow roll rather than blocking production out the gate.

>> Male 2: Yep.

>> Amber: Does anybody else have any thoughts on how they do it?

>> Amber: I’d like to know what your companies are, what your companies are that you work for?

>> Man: So, I’m in American Specialty Health.

>> Man 2: Penelope Investments. [audience members laughing]

>> Man 3: That’s what I was wondering. Two of us are in here with the comptroller, and so that’s why I was wondering, well, who was beholden to what rule? Like obviously, every one of our customers is anybody in the state or nation I guess. But so, we’re beholden different levels of, you know, legal stuff. But also, you know, like you said earlier, when I was asking about an error, you were like, well what your yours is defined as. Like, oh, ours is very specifically defined. [laughs] To outside of us. But we don’t get to do that. And they tell us, you know, we have an accessibility department, this is exactly what you will meet or, you know.

>> Amber: Yeah see, I mean, you’re probably at the comptroller talking about, WCAG 2.0 AA. Unless they’ve decided to be proactive and get on 2.1.

>> Man 3: I can’t speak for their department. I don’t know offhand. Han, do you know? [audience member speaking distantly]

>> Amber: That’s the legal requirement, so it would only be if somebody decided they were going to go beyond that.

>> Man 3: They do push for WCAG, to do those, so.

>> Female: Screen reader policy on the public website have been. [indistinct] Before we publish, we should know our policy content is supposed run past. [indistinct]

>> Amber: Yeah, so you would create a PDF, it would go to an accessibility group, they would approve it before you can make it live

>> Female: Yeah.

>> Male: But if somebody else created that PDF file by the way. [audience members laughing] [woman speaking distantly]

>> Man: If they’re one of those folks that are making it accessible?

>> Male: They absolutely are. Yeah but, we’re whipped. [man laughing] We don’t make PDFs.

>> Amber: Okay. Yeah. Do you wanna?

>> Man: You want me to read them to you?

>> Amber: All right. Okay, so it looks like we have a couple of comments from chat. Susan is from Mouser Electronics, which is a large company, they have seven agile teams. “We have front end developers that are being trained as SMEs on each team. They use Usable Net AQA to test biweekly or monthly. Aside from the UI team, designing with accessibility in mind, we do accessibility checks for requirements and user stories, and during development, I try,” she says, “I try to catch errors on lower environments.” Jason says, “There are issues with self adaptation,” so I think attestation, which I think is a response to the comment of, we ask our developers, did you test this? [audience members laughing] And they have to self-report. So Jason says, let’s see, “There are issues with that with large companies unfortunately. Someone that has knowledge someone that has knowledge that starts and ends with, “does it have alt tags?” will happily confirm it is accessible when it absolutely isn’t. We require a 95% or above automation check before giving a tentative sign off.” Let’s see. [man speaking distantly]

>> Amber: Yep. So, there are a lot of different ways, but that’s why I think it’s helpful to talk to other organizations and find out what do those organizations do. And some of them obviously are a lot more strict than others. I know one thing that we’ve heard a lot with our tool, it’s relatively new, like it’s only been out for about a year, and so we’re like constant, it’s kind of what we consider our MVP, but we have regularly heard from our users, and we have in our roadmap now, to actually have the ability for them to check off. We have about 40 different checks for them to choose the ones they want, and then they can restrict publishing. Because we’ve heard that a lot of things are saying, you know, these are specific problems that we’re not willing to have on our website. And so I don’t think you would be alone if you went back to your company and said, “We need to create a list of things that we do not allow to be public, or in our product.” Or whatever that might be.

>> Male: What, ’cause I’m at a university, I’m at UT, in the Fine Arts department. I mean, what do you recommend? ‘Cause we can’t refuse to publish the School of Music’s Website, you know, for their headers. I mean, we’re constantly, and though a lot of these, these tools and recommendations were really good, and I’d love to implement them, but how do you recommend, you know, where is the stick, you know? And when they know that we’re not gonna stop them from publishing their website, or we can’t, that we eventually just have to let it go, and then hopefully we can encourage them to continually remediate, and they’ll remember these things. I mean, yeah, what do you?

>> Amber: So the question is, he’s at UT in the English department? Or fine arts department. You know, what can we do if we can’t refuse to publish? So, I mentioned it earlier, a university where they refused to publish a new website. And it was the president, or it was the website for the office of the vice president of diversity and equity inclusion. And they were just like, “No.” Which I will say, like, it was frustrating for them, there were no problems in the theme, we built their theme and then they did all of the content, ’cause they didn’t have budget for that. Because their current website, which was old, had accessibility problems on it. But like the law, the way the law works is that new content, new websites, have to meet the guideline, and so that was the university’s way of being like, we’re protecting ourselves, we would rather you have the ancient website with accessibility problems than a brand new website with accessibility problems. So, I have heard of universities doing that for very major departments.

>> Male: Yeah, yeah.

>> Amber: But I mean, if that’s something the university isn’t going to do, then I think, you know, there’s trying to figure out, where can those proactive things. So, if you use Drupal, use Editoria11y. If you use, you know, WordPress, get like Accessibility Check or something. Or like teach people about how to use Wave. I don’t know if UT, does UT have like an accessibility committee that crosses like campuswide that different people in different departments are part of?

>> Male: It’s so, largely centralized, and you know, we’ve all complained about this. And you know, there is a department that implements the automated testing. I mean, they just changed the tool, but they’re just concerned about those numbers, they don’t really go, you know, and they got sued last year, but they fixed that thing they got sued about. But really every college and school kind of rolls their own. I think we did a really good job. We have documentation, we have tools, we have three different websites, one for WordPress, one for Drupal, one for just general that has accessibility information.

>> Male: For our content managers, we have built in Qualtrics. We have a little, oh, this is how, you know, general web stuff with a lot of accessibility built in. We do checks, but we’re all rolling our own at UT in each school and department. So you know, to get to the main, it’s just they don’t have the staff, or whatever to kinda reach out to.

>> Amber: I think when you’re part of a large, decentralized institution like this, that you really have to try and think about accessibility, like what can be done from the bottom up? Because it may not be, I’m not super familiar with UT, right? But some universities have a web service as far and everything goes through them. Some don’t. And some it’s like, we just went and hired our developer that is over here. Right? Because it was like, the faculty members’ cousin who knows how to build websites, right? [chuckles] And we see a lot of difference too, between like, even brand standards, right? And that’s a challenge I think universities have, like, how do we maintain our brand across all of these things? And so, almost think about accessibility in the same way. So like, what has been done to establish like, “This is how our logo is used at UT.” Right? Like what can those things be? And then really trying to come up with, maybe you don’t control the computer science websites, but you control the fine arts websites, or you have a say in that, like what can you do in the fine arts department to at least ensure that your website is accessible?

>> Male: Yeah.

>> Amber: And, again, like making some like, we talked about adding small steps, rather than just straight up blocking from production at the beginning. But there are small changes that can make a big difference for users.

>> Male: Yeah, and since we’re building our own things, or using, you know, the CMS, I mean, we do build in the accessibility ourselves. It’s just the content owners, which are, are wonderful and overworked, [laughs] it’s just like, how hard do you go when you’re like, “Okay, this alt text is terrible. These headers are wrong.” You know? I mean, I’m saying that here, I would never say that to content owner. [laughs] But you know what I’m saying?

>> Man: You should.

>> Amber: Yeah. You should. You should. I mean, I think that’s where sometimes —

>> Male: I would never never say something horrible to anybody because —

>> Man: It’s part of the education. I mean, people not understanding what good looks like.

>> Amber: And that’s where, so what we we’re talking about for people on Zoom, and then I think we’re about at lunchtime, right? Yeah. So, I think it is okay to go to them and say, “This is a failure.” Because it is a literal, in some instances, a web client accessibility guideline failure. Right? And I don’t think it’s about like, as long as you do it in a constructive manner, like I don’t think it’s about like, hurting people’s feelings, it’s about educating them. And that’s where some of the examples that I provided, like when we looked at the PDF from Florida State, where they have the two different screen reader examples. And what’s handy about that actually with the naked links, ’cause that’s something I see and think all the time, you could grab those like examples, and use them, like send them out and just be like, “Listen to these two things. What would you rather hear?” And it’s very clear. Right?

And I think the other thing is, is if you do use an automated testing tool of sorts, whether UT has one, or whether you’re just like teaching people to use Wave in their browser because it’s free, and you don’t have the budget in your department for that, like you can then like explain to them, there are some very clear things that we don’t consider acceptable, and here’s a black and white test. And that’s a good first step before, you know, and then it’s like we talked about screen reader testing, or we talk about having users in it. Another thing is just find a student in your department who has disabilities, and ask them if they would be willing to give a talk to all the faculty in your department, and sharing their personal experience. Because then they can be like, “Oh, I know Susie. She’s in my class.” Or “I’ve never had a class with her, so maybe I didn’t really realize the challenges she experienced, but I’ve seen her in the hallways, and she’s a student in our department, in our major, and now I can put a face, and I know why this is important.”

>> Male: I’m disabled too, so it gets a little personal. [laughs] [audience members laughing] Yeah. Another reason I don’t feel too horrible. But yeah, no, I think that’s tremendously useful. And I like the, I never thought of training our content users to use the tools that we use. That’s brilliant. And it would, you know, just sort of gameify things too. It just like, that’s —

>> Amber: That’s the thing we hear from our end, and they’re like, “Ugh, I just want it to turn green.”

>> Male: Right. Right. [laughs]

>> Amber: So, I think that we’re at time. I appreciate everybody, but I’m happy to talk with people more.

>> Man: So one quick question, I’m not a user of the content industry, the tools. but just outta curiosity, the tools that you’re listing for accessibility, is there a common engine those are based on, or are they all independent?

>> Amber: So ours, we wrote our own rules. So we don’t pull from any rules. I mentioned PopTech earlier, PopTech uses the WAVE API, So it uses WAVE’s. I’m pretty sure Monsido and Site Improve, those are other SaaS companies, they have their own rules.

>> Man: So Site Improve is — are they using UAAG’s rules?

>> Male: I don’t remember what they use, we subscribed to them in a previous agency I was with, but they were really big in sales, and I had to debounce everything, you know? But there’s also a website or whatever about —

>> Man: Do you know what I mean? [audience members chattering]

View “How to Maintain Accessibility on a Website with Many Contributors” slides on Google Slides.

(Narrator) [Upbeat music] What is web accessibility? And why does it matter?Misconception number one: Web accessibility is for people with disabilities. Actually, web accessibility is for everyone. Everyone is different. We experience the world in different ways. That means we also all experience the web in different ways. On desktops, laptops, tablets, mobile devices… inside, outside… in a loud environment, in a quiet environment… with or without assistive technology, everyone should be able to access, and appreciate, your content. How we see, hear, move, and think affects how we perceive and interact with digital content. Bottom line—the more people that can access your content the better.Misconception number 2: Only web designers need to consider the accessibility of their content. Actually, everyone needs to consider the accessibility of their content. Web accessibility is more than just websites—it’s any digital content or platform including social media, apps, pdfs, and presentations, to name a few. Don’t alienate some of your audience. Create digital content with inclusion in mind. Misconception number three: Web accessibility is optional. Actually, web accessibility is mandated by federal legislation. Research programs and institutions, like UD, must comply with federal accessibility standards like the Americans with Disabilities Act and the Rehabilitation Act of 1973. Discover how to make your content accessible to everyone at www.udel.edu/accessibility.