« Return to video

Creating and Providing Training on Accessibility [TRANSCRIPT]

SOFIA LEIVA: Well, thank you, everyone, for joining us today for the webinar entitled “Creating and Providing Training on Accessibility.” I’m Sofia Leiva from 3Play Media, and I’ll be moderating today. And today, I’m joined by Emily Ogle, senior regulatory strategist of accessibility at Cerner Corporation. And with that, I’ll hand it off to Emily, who has a wonderful presentation prepared for you all.

EMILY OGLE: All right. Thank you for that introduction, Sofia. I’m really happy to be sharing the thing that I have learned over the past year. And so I want to share a little bit about me.

I am a hard of hearing user. I have been wearing hearing aids my entire life. And I am also a lifelong closed captioning user.

So I’m very dependent on those. This has segued into me taking a more active role in accessibility in general. And I am a never-ending advocate for those with disabilities.

So some objectives that we are going to cover today– these might be a little bit misleading. It seems fairly simple, but we’ve actually got a lot of content to cover. So I’m going to go over the introductory, mid-level, and detailed ways of providing training.

And I’m going to be demonstrating this through a series of triangles. Because when you have introductory training, that might only be a small subset. But if you’re going to have mid-level training, that is going to need to include introductory training. And then any detailed training is going to need to include introductory and mid-level training. So it all builds upon each other.

First, we’ll go over the introductory section, starting out with the basics. I would plan on an hour for providing this training. And what you’re going to do during this training is provide a very high-level perspective of accessibility.

You’re going to try to summarize accessibility as much as you can. It can be a little bit daunting, because accessibility is quite complex. You’re going to want to be talking about the primary users, the primary beneficiaries of accessibility. And you’re going to do that to try to build empathy, so people walk away thinking about this and the users.

The high-level perspective of accessibility is really going to talk about the key themes of accessibility– so keyboard, assistive technology, color considerations, responsive design. Those are all areas of accessibility that really need some introduction to help people understand just the relationship. As you discuss each subset of accessibility, you always want to relate that to the end user and what they experience.

You really want to be speaking to that perspective. I recommend providing demonstration of good and bad accessibility. You want to talk to the steps as you are demonstrating. So don’t leave your users or participants guessing as to what you are doing.

So if you are tabbing through a screen to demonstrate keyboard accessibility, you’ll say, I press the Tab key, or, I’m using the arrow keys. I’m using ctrl-plus. Let people kind of understand the steps that you’re taking.

When you are demonstrating with a screen reader, you are going to want to provide that expectation before you actually navigate through something. So if you have a Save button, for example, you’re going to say, I’m going to Tab to this Save button, and then I expect to hear “Save button.” And then that kind of helps set the expectation that if you don’t hear a Save button, then you can talk about why. What’s going on? And then you really want to highlight the benefits of accessibility– such as employment, retail access, education access, software access– and highlight how everyone benefits from it.

Who are the primary users that you will need to highlight? There are five or six main categories– people with vision impairment, people who are deaf or hard of hearing, like I am, people with limited mobility and strength, and the neurodiverse population. And so people who are blind and can’t see– so we’ll talk about how they need textual or audio support.

And then those with low vision, they can see some, but maybe relying on magnification software or the zoom capability in a browser. Those who can’t perceive colors, they need symbols or text in addition to color. It’s not that you can’t use color, but you just need something in addition to that.

Deaf or hard of hearing people need closed captioning. So for example, right now, I am seeing the closed captioning on my second monitor. And those who have limited mobility or strength might not be able to use the mouse. So they may rely only on the keyboard.

The neurodiverse population has a lot of dependencies on some of the other areas of accessibility. There’s not necessarily a lot of rules or criteria that focus on that. And we’ll talk a little bit about that later.

When you are doing activities, you are really going to want to be keeping the training interactive. You’re going to want to leverage everyday situations and apply that accessibility lens. For instance, banking– before accessibility, some people had to rely on others to tell them how much money they had in their account.

It’s something that we do everyday that we can all identify with. And bringing that everyday situation kind of helps us to relate to that user. And then we also want to talk about how everyone benefits from accessibility. So

Wheelchair ramps– how many parents use these ramps for a stroller? Or if you’re using a grocery cart, are you just going to go down the steps? No, you’re going to use the wheelchair ramp.

I wanted to point out some things that started out, as I mentioned, for people with disabilities. And texting is a great example. Texting is the best invention, from a hard of hearing perspective.

And what’s important to note is that, when you are taking activities to build empathy, you want to avoid empathy exercises that are reductive, such as having all participants use a wheelchair. That does not get to the experience that they may have everyday. You really want to leverage the everyday experience in building empathy.

Let’s discuss mid-level training. So this is going to be building more of a foundation of knowledge. So again, we had the introductory section, and then we had the mid-level section.

So we have an hour for introductory section and one to two hours for mid-level. Training is going to be focused on key areas of accessibility. So you mentioned the key areas of accessibility in the introductory section. You’re building on that in the mid-level training. And then we want to always be emphasizing the user experience– so providing more examples, more opportunity to understand who the user is.

Some of the key areas for accessibility are, again, going to be keyboard, assistive technology, color, responsive design, forms. You’re really going to go into more detail. So keyboard at an introductory level is, can you access everything using the keyboard? Well, the more detailed level is going to be, do you have good visibility of where you are on the screen?

For assistive technology, are you provided instructions as you are using assistive technology? So it’s going to build upon the introductory thing. You’re also going to want to talk about where accessibility fits into the software lifecycle. So it needs to be integrated with the design, development, testing, planning, all of that.

And then you want to discuss who all owns accessibility. And so that’s going to be the designer, the user experience designer, developer, tester, end user. I have an asterisk on the end user, because I’ll be going over that section in a little bit more detail.

When you are providing further detail on key areas, you’re going to want to talk about why it’s important to test the keyboard separately, like a keyboard and a screen reader. You can have a completely different user experience taking that sighted keyboard user perspective compared with if you turn on a screen reader and you’re trying to use the keyboard. Additionally, there is a very close relationship between keyboard accessibility and assistive technology.

And I have a quote here, an unattributed quote. “Developers can ensure programmatic capability for all elements, but if users can’t get to it, they might not even know it’s there.” So if you are discussing remediation, how to fix some of the issues, we want to kind of concentrate on that keyboard accessibility.

Because if you don’t have that keyboard, you’re not going to have that screen reader or assistive technology capability. And then you can do some simulations of low-contrast content. There are lots of browser extensions that can kind of simulate vision. It’s a little bit different from what I was talking about earlier, in terms of, just don’t take a reductive approach to building empathy. It’s just really good at kind of showing how important low-contrast is.

So I’ve got an image here with two tabs, About and Academics. And I’m going to show what that looks like if it’s blurred. And it is blurred now, and you can barely even see that there are words there. And that’s because those texts were using a grey and a yellow, and it just wasn’t good color contrast.

I recommend providing charts, flow diagrams, to show how accessibility fits in. I have a diagram here that shows the relationship between all of the roles. And so we’ve got the end user, the user experience, designer, developer, tester. And really, I would have wanted to put a line between all of these nodes in this chart, because they really are all interrelated.

I have the end user here. I’ve called this out. And it is because you cannot really create a good experience without the end user’s input.

It’s important to humanize accessibility. Devote the time for several different user groups who benefit, in particular, from accessibility best practices. And so we’ve got blind, low-vision, color blind, deaf, hard of hearing, keyboard users, neurodiverse users.

And then we want to talk about how some groups take more time to make accessible, or the consideration for making that more accessible to these users is much more complex. So we have a lot of criteria for making content accessible to the blind. And it’s because making everything and creating that equivalent for everyone is very complex. There’s just a lot of nuances.

Then others, very straightforward– deaf and hard of hearing, give me closed captioning. I am good. I have an email setting on my Outlook that flashes whenever I get a beep indicating I have a new email. So that’s the visual equivalent of that sound.

And then keyboard users– I sometimes debate whether I should include that here– pretty straightforward– include to make sure that you are making everything keyboard accessible. But if you have not been keeping keyboard access in mind from the beginning, it can be really complex to retrofit software so that it’s keyboard accessible. And I mentioned earlier with color blindness, it’s really all about the supplement, ensuring that you include a symbol, like an asterisk, or, in text, what that data is. Charts and graphs tend to be a common culprit for using color alone to convey information.

And then we have some user groups that don’t actually have enough accessibility consideration. Low-vision users comprise a good chunk of those with vision impairment, but they don’t actually have as many accessibility considerations. And that’s changing as more criteria are added to the existing standards. And I’ll talk a little bit about that as well.

And then cognitive disabilities or neurodiverse consideration don’t have enough. And the main reason for that is because neurodiversity can be considered subjective. And the accessibility criteria were generally written to be measurable. And so it’s been a challenge making sure that we are accounting for the neurodiverse population.

I’ve got some examples on how you can maybe create a set of profiles or set up information, if you’re wanting to just provide deeper context for vision examples for the vision user. I’m not going to go through all the uses, because this is a pretty long presentation. But I wanted to give you an example of what it may look like to really go into a little bit more detail.

So for vision, we have the blind user. We talk about, again, the relationship between keyboard accessibility and assistive technology. We talk about how they may need to use a screen reader to operate a web page and then the importance of ensuring that all elements have that programmatic equivalent or that textual equivalent. And we also want to talk about how blind users may browse content in a non-linear way, so ensuring context is key. So if you have a bunch of links that say, click here, click here, click here, the blind user might not have any idea what that “click here” is referring to.

I’ve got a screenshot here of a radio lineup in Kansas City. I live in Kansas City. And what I’m going to show in the next animation is going to show some of the higher-level consideration that we need to think about when we are accounting for the blind user.

So I’ve got arrows leading to three Go buttons. And I’ve got another set of arrows that are leading to four input fields. And then each of the Go buttons need to have unique button descriptions, like Go To Call Sign, Go To Zip Code. And then each of the input need a unique label. And so you can really provide a lot more detail than what I’m showing here. But it can be a good demonstration to help people understand just the sheer amount of nuances that we see.

Low-vision users are going to be needing color contrast. They may be just reflowing. Reflow screen means that they are re-sizing their screen and the content reflows correctly.

You’re really going to be relying a lot on responsiveness. And as I mentioned earlier, the consideration for accessibility for this user group is lagging behind. And that’s changing.

And one thing I wanted to note is, something that you would want to convey in any sort of training when you’re talking about low-vision users is, make sure participants in the class don’t assume that a low-vision user is going to be using a screen reader. They could be using magnification software, or they may just be needing a larger font size. So the bucket of low-vision users is quite diverse.

So here, I’ve got a screenshot. And on the left is black and white text. And on the right is black and purple text.

This resulted when I re-sized my screen to 400%. And that content did not reflow well, and it overlapped with the dark purple section, meaning it becomes extremely low color contrast. So providing those examples can really help think in for what people with low vision may encounter.

Color blind users encompass about 8% of the population. It’s concentrated in men. Red-green deficiency is most common, but you also have blue-yellow. And very rarely, you do have monochromatic deficiency. And the key here is that data can be lost if you don’t have anything supplementing that color.

I want to emphasize, though, color can still be used, but it shouldn’t be the only thing. So I’ve got a screenshot of the COVID map. And there are several different colors– red, orange, green, yellow. And each of these colors represent how well a county is doing in their COVID approach.

And on the next animation, we can see that without color. And then the orange and the green become indistinguishable from each other. So that information is completely lost to me as a user.

Creating activities for mid-level training– I recommend doing a gut-check. And I would do this in-between the introductory training and the mid-level training. Just have a gut-check.

Have people just open a tool that they use, like Outlook, or Teams, or Zoom. And have them look for barriers that they hadn’t noticed prior. So they take that introductory training, and then start finding some of that. And then, during mid-level training, you’ll have more time to be able to have participants do hands-on assessment.

And I recommend having everyone kind of assess a website and then compare. And see what people find. Some group activities can be, again, focused on the user. So you can take a persona and assess the website from a specific user’s perspective.

Have polls or knowledge checks throughout the training. And then another thing I like doing is having a comparison exercise. Let’s say you have comic one, comic two.

Comic one is a little bit more accessible. Comic two is not so accessible. But just have people instinctively guess which one is better for them– not necessarily which one is more accessible, but which one they prefer. And in the exercise that I tried this in, the more accessible version is usually the one that was picked.

All right, let’s dive into the detailed section. So the outcome that we would be looking for with the detailed training is being able to leave the training and apply it to your work. Again, introductory section is included, mid-level training is included, and then detailed training encompasses anywhere from two hours to two days.

So it can really vary. It depends on the targeted topic or the theme that you’re wanting to teach on. When you are putting together a goal for detailed training, you really want people to be able to walk away being able to incorporate what they learned in the work. It’s not to say that you don’t want them doing that with the mid-level of training or the introductory training, but the intent is that they are actually doing work to incorporate accessibility into their everyday lives or work.

We can have some themes that are more targeted. And so I’ve got here criteria, user groups, personas, assistive technology, regulation, documents. And you can have all of the above.

What I wanted to note is that this is not, by any means, exhaustive. You can have training on web accessibility versus mobile accessibility, for example. So there’s a lot of different ways that you can target specific subject areas within that accessibility.

Accessibility is complex. And there are so many different ways that you can train. We want to emphasize that training and learning doesn’t really end. And there’s always going to be some new technology or innovation that brings about new accessibility consideration.

For example, when 3D printing came out, it opened a potential world for people to learn using tactile accessibility. And so that is a new innovation that could potentially provide a lot more access to people who can’t see. And again, I’m sure I’m going to be sounding like a broken record. Always incorporate the end user in any training.

I’m going to talk a little bit about criteria-based training. And this is going to be among the most exhaustive detailed training that you can provide. You can provide information on the specific criteria. Most people would start out with Web Content Accessibility Guidelines, or WCAG, levels A and AA. It’s kind of the foundation of accessibility criteria.

User groups need to be integrated throughout the training to be effective– so always relating it back to that end user. And when we go over the activities, I’ll talk about how we can do that. Participants, they may be taking the class because they are maybe filling out a VPAT. And VPAT is a voluntary product accessibility template– V-P-A-T. And so they need to learn how to test for it.

Or they may be wanting to expand their skill set, including accessibility considerations, into the design. And they may also just be wanting to fix some of their criteria. This learning will take time. So I recommend putting aside two days of training. And again, this will be in addition to the introductory and mid-level training.

WCAG’s core principles provide the structure for the training. And that is perceivable, operable, understandable, robust. And you can separate your training into those categories, if you so choose. When you are doing activities for criteria-based training, you want to really kind of provide demonstration for criterion or level. By level, I’m referring to WCAG level A, WCAG level AA.

Or you can concentrate information around a set of like criteria. So have all of the demonstration for keyboard in one demonstration, and then just point out which criteria goes with which. You can visit some predesigned inaccessible pages.

W3C has five pages that provide before and after accessibility. So you can have your participant visit those sites. Washington University has a set of pages that they call Accessible University. Again, it’s a before and after.

And I have a screenshot of the Accessible University web page, to just demonstrate what that looks like. Name That User game is not necessarily a game, maybe more of an exercise. But for each criterion, you name the user who may benefit.

Not going to get too technical, because not everyone knows the criterion name, but if you are talking about the proximity of a label for an input field, who would that user be who benefits from that consideration? And so it could be somebody who has low vision and may have their screen magnified to 200%, 400%. If the label’s not close to the field, they might not know which field goes with which label.

User groups and persona training will really go into a deeper understanding of what we’ve already learned. So it’s not that you’re going to rehash the user groups and persona training. You’re going to be more focused on focus groups and user acceptance criteria.

And so some tips that you would want to ensure is making sure, in a focus group, that you’re allowing the users to provide feedback in their preferred environment. You want to ensure that you are using inclusive language. And always ask about and provide the preferred communication method.

So if you were to ask me what my preferred communication method is, it’s going to be chat. I would prefer chat over email. Because then it’s more of a conversation.

And then you want to leverage the assistive technology that users are already familiar with. Don’t make them provide feedback on an assistive technology that they don’t use, unless it’s a focus group on assistive technology itself. And if you’re looking for feedback on how accessible your website is, what the actual user experience is for them, you want them to be able to use it on assistive technologies.

You can also start going over some of the best practices for creating user stories or user acceptance criteria test scripts. Developing persona to create the development requirement– really, again, it just relates it back to the user. And these personas can then be leveraged throughout the development lifecycle.

So as a user who has decreased hearing, I need to view this video with closed captioning. And I am doing this work and viewing these videos. And so in my work viewing these videos, I need to have that closed captioning. User research is going to be critical in order to create user stories. So you’ll want to engage UX human factors and really just leverage the detailed research that can come about from including users with disabilities.

All right. So some activities that you can include in user group/persona training– you can include a Who Am I exercise. Very similar to Name That Disability. Read a story that describes the barriers the user experiences.

I get to a website, but I don’t know what the name of it is. And then the participant can talk about what the potential disabilities are that are associated with that barrier. So people who rely on a screen reader, they need to know the title of each web page so that they understand the purpose of the page.

People with distraction disorders may need a page title to help reorient themselves, if they get distracted and then they come back. I have an activity that I like using called Who’s Left Standing? It’s a visual exercise. So certainly, any time you provide a visual exercise, you want to make sure you’re talking through and describing the result of that.

But I’ve created a list of everyday scenarios– so going back to that everyday scenario that you include in the introductory training. And it’s a set of scenarios that everyone is likely to experience, or at least they’re likely experience some of them. At the beginning of the exercise, you can have people stand, or the equivalent if they can’t stand.

And then, when the scenario is applicable, have them sit and remain seated, again, describing, updating people. OK, a few people have sat down. We still have most of the room standing up. And then go through all the scenarios and see who is still standing.

And that really kind of helps dive into what people experience on a day-to-day basis, the barriers that they may experience. And you can have the opposite of this visual and have them stand back up when they experience something that removes those barriers. And so it’s a good visual. But again, you want to make sure that you are descriptive throughout.

Assistive technology training can be really hyper-focused. And participants may be doing this to learn how to develop for it. They may want to have a better understanding of the user experience. They may be getting some sort of certification.

And because assistive technology can really encompass a lot of criteria, a lot of nuances, I would recommend setting aside six to eight hours. So if that’s four hours on two days, or all in one day, that would obviously be up to you. I do want to talk about the different types of assistive technologies.

So there are all kinds of assistive technologies– screen reader, speech input, puff detection, eye tracking. We have stick devices. Your glasses count as assistive technology. My hearing aid counts as assistive technology.

So you want to really just talk about each of those. And again, bring back the user. Talk about how the user is affected by the lack of accessibility. And then talk about how the assistive technologies facilitate gaining an equivalent experience.

Screen readers, speech input devices– these are considered user agents. And there’s a whole set of guidelines that are focused on making user agents accessible. I’ve got a link here to the user agent accessibility guidelines, or UAAGs.

These user agents have their own set of rules that they have to follow in order to be accessible. So it’s not like a screen reader can just flout the rules. They have their own requirements that they’re supposed to meet.

Browsers are considered as user agents. So they have a requirement that they have to meet in order to be interoperable with assistive technologies. And then it’s important to emphasize the following best practices.

Use semantic code. Don’t take shortcuts. It’s really important to emphasize that.

When you are doing activities for assistive technology training, I recommend having people or participants download a free screen reader, if they’re not already using a screen reader. NVDA is one such screen reader that’s freely available. If they’re on a Mac, they will have VoiceOver as standard. VoiceOver is another screen reader.

And you can also have them concentrate on using the screen reader or voice commands on their mobile devices. And you can test a web page using browser extensions. There’s lots of browser extensions that will kind of highlight some of the gaps for accessibility. The caveat there is that these browser extensions don’t catch all of the things that we need. But it’s good for people learning about assistive technologies to be able to see what a web tester will catch and compare that with the actual user experience.

It’s important to remind people that those who use assistive technology, like a screen reader, aren’t necessarily going to use or browse content the way we might expect them to. And I’ve got here a screenshot from the JAWS screen reader– that’s J-A-W-S, Job Access With Speech. That’s a screen reader.

And it’s a list of HTML features. And so it includes anchors, article, headings, list, link, graphic. And screen reader users can browse content using only the links list. And that’s, again, where that context is important. So if you have a whole bunch of links called Click Here, and the screen reader user is using a links list, it can be problematic for them when they’re trying to navigate.

I am a regulatory strategist. So I’m very in tune with the regulations around accessibility. And this one isn’t necessarily going to take as long, but I would recommend maybe doing it in conjunction with that criteria-based training, just because regulations do compel those criteria. And you want to include information about the Americans with Disabilities Act, which is in the US. Or if you are providing that training in a different country, you can provide those equivalents– so the Equality Act in the UK.

WCAG and its various iterations track back to India. And I’ve got here WCAG 2.0, 2.1, 2.2, WCAG 3.0 silver. So there is a lot of progress.

So accessibility, we like to say that it’s not a destination. It’s a journey. And the continuing expansion of accessibility criteria demonstrates that.

And then there’s the fact that some governments are compelling accessibility. So we have government regulation. The one that I’m the most familiar with is Section 508 and EN 301 549.

Section 508 is the US standard. EN 301 549 is the European standard. And what we see is a lot of other countries adopting variations of either Section 508 or EN 301 549.

There are not really necessarily a lot of activities for regulation training. It can be a little bit dry. I have here, though, a tree chart, showing the hierarchy of the regulating body.

So the Rehabilitation Act of 1973 in the US has a subsection called Section 508. And then Section 508 includes WCAG 2.0 and chapter five. And it includes several chapters, not just chapter five. But having your user understand that hierarchy can help guide them to really understanding the dependencies or nuances between EN 301 549 versus Section 508.

And then we have some document trainings. So you will see here that I have designated two to three hours for most documents and one day for PDFs. And PDF accessibility experts are in high demand. And if you are providing training, this is really going to require a lot of detail. There are just so many parts and pieces to making a PDF accessible.

And so we talk about software. We talk about web pages owning accessibility. But the fact of the matter is, documents need to be accessible as well.

And we do have accessibility checkers that come with certain programs. So PDF has an accessibility checker, depending on the Adobe Acrobat version that you’re using. And then most Microsoft products come with an accessibility checker as well.

Converting from one form to another has its own set of considerations. You can’t just convert a Word file to a PDF, for example. You have to talk about the typing process and the additional steps that you need to take to convert properly.

I recommend having an activity where people run the accessibility checker and make note of things the accessibility checker does not catch. They’re not going to catch color being used to convey information, for example. They’re not necessarily going to catch when a link is not unique.

You also want to make note of false positives, things that are not actually a violation, but flagged by the accessibility checker. Microsoft Word and PowerPoint, for example, flag all shapes as needing alt text. But they don’t need alt text if they have no purpose.

And then I may recommend doing the flip side. Create a document that passes the checker, but is otherwise unusable, like using color contrast where the colors clash, but they meet minimum requirement– again, using color alone to convey information. And that really demonstrates the importance of user experience inclusion.

Because we want that feedback from the end user. Because if it looks awful for them, they’re not necessarily going to care that it’s technically compliant. We also want to demonstrate that checkers do not catch everything.

All right. So we’ve gone through most of those types of different training. And I want to just note on making your training accessible itself.

You want to practice what you preach. If you are including videos, you want to make sure that the closed captioning is included. Describe the images of visuals.

So throughout the presentation, when I have an image that is relevant to the topic, I’ve been describing the purpose of those images and what they mean. You want to avoid using references to location, shape, direction. Demonstrations tend to be an area where this is the culprit.

So people might say, click over here to select this button. And they’re assuming that the end user can see what button that they are about to select. You really want to ensure that you’re being very descriptive and very precise in providing that demonstration.

Select the Save button. Select the Ally button. No, you just really want to be descriptive. Place links behind text. When links are not placed behind text, it can end up being noise for a screen reader user.

And it can be https://. And it can be this long string of characters. Additionally, if links are not put behind text, people who are maybe using a speech input device may have a harder time selecting that link.

When using charts and graphs, provide table equivalents or shapes. And by shapes, I mean that, instead of having my different data sets be noted by red, green, yellow circles, use red triangle, yellow circle, and then green checkmark. That’s just an example.

Again, it’s not that you can’t use color at all. You just need to supplement it with some sort of symbol, or shape, or text. You want to determine accommodation need prior to training. So some people get accommodations confused with accessibility.

You don’t need to make your presentation accessible if you don’t have an end user. It’s more, if you know somebody is going to be hard of hearing, they may need a court stenographer. Or if American Sign Language is their first language, they may need an interpreter. You want to determine that before training.

Throughout training, you want to ensure that you are using inclusive language. This can be a little bit tough if you are not necessarily familiar with some of the terminology that is used when it comes to people with disabilities. So I had been using “disabled people” and “people with disabilities” somewhat interchangeably. It can vary based on where you are.

If you are in India, for example, that preferred term may be “differently abled.” And you want to avoid using words like, “normal,” “normal people.” I caught myself saying that. And instead, I switched it to “expected behavior.” And so it’s really important, that. Kind of be mindful of that.

If you’re not sure if you’re going to have an easy time remembering that, I recommend putting that in your PowerPoint presentation notes, in a Word file, or just maybe practicing using that inclusive language. But yeah, it’s important that we are practicing what we preach and ensuring that everyone, all of our participants, are able to feel included. All right, that is a lot of information.

I thought we could open it up. It looks like I have about 12 minutes. We could open it up for some questions.

SOFIA LEIVA: Yeah, thank you so much, Emily. This was really wonderful. And we definitely have a lot of questions that have come in. The first question we have is, do you have any ideas about ice-breaker or intro activities that would be ideal for this type of training, specifically in a virtual environment?

EMILY OGLE: Yeah, so what I’ve done for virtual training for having an icebreaker– I provide assessment training a lot. And I have put a gut-check exercise, where I might have a criterion, and I might have a response to that criterion. And it’s like a gut-check.

People say, OK, is this good? And they can go into a breakout group, depending on the software. Not all conferencing software has breakout groups. But it’s a way to kind of highlight that people do have some instinct as to what makes sense to them and what they maybe take for granted.

The exercise that I mentioned with Last Person Standing, that really doesn’t necessarily have to be just in mid-level training or detailed training. That can be an introductory exercise, where when people are all standing up, and then they’re all sitting down. It kind of starts the conversation. And you might hear some muttering. And that can be a really good exercise to just kind of sink in for people, to help them start really listening to the presentation.

SOFIA LEIVA: Great. Thank you so much. The next question we have is, what are some great, low-contrast content testers that you know?

EMILY OGLE: I use the Paciello Group’s color contrast analyzer. Some of the web checkers do have checkers where they are comparing the contrast ratio in HTML. The color contrast analyzer, I like that one because it calculates to an additional decimal point, compared with most of the accessibility checkers that you find with webbing. Microsoft Word has where you can check the color contrast.

SOFIA LEIVA: Thank you. The next question we have is, how do UX user experience writers come into play in the diagram you showed at the beginning?

EMILY OGLE: So sometimes, people get user experience with UI. The user experience person is going to be concerned with the end user’s actual experience.

So the assistive technology considerations are not just limited to the UI. That’s a problematic consideration. That’s going to be in the development aspect.

The user experience is going to want to make sure that we guide that programmatic aspect to be informative, to be not providing a lot of information that’s not necessary, ensuring that the actual screen reader experience is beneficial. If we don’t pay enough attention to the user experience throughout all of development, design, we can end up missing out on the screen reader or assistive technology experience.

SOFIA LEIVA: Perfect. Thank you. The next question we have is, what screen readers are free, besides Chrome?

EMILY OGLE: What screen readers are free, besides Chrome? So NVDA stands for Non-Visual Desktop Access. That is a freely downloadable screen reader. Windows machines do come with Narrator built in.

There’s not necessarily a lot of support for Narrator. VoiceOver comes standard on the Mac. And then some Microsoft products have an immersive reader that can also provide some of that experience.

SOFIA LEIVA: Thank you. The next question we have is, my college uses an LMS– learning management system– that is not keyboard accessible, although the company who provided it said that it was accessible in their VPAT. What ways can I advocate for people– or, I guess, other teachers and my college– to use a more accessible version?

EMILY OGLE: Yeah, so one of the key things to note about a VPAT is, one, the person filling it out needs to be an expert in accessibility. Or they need to at least have a QA process that utilizes an expert. And then the person consuming that VPAT– let’s say someone in your legal team, someone in contract management– they need to understand those nuances of that VPAT.

There are certain red flags that you can look for in a VPAT. If they provide no supporting explanations alongside their performance result, that can be a red flag. Because they’re not actually saying how it’s accessible. And then that is something that you can kind of push back on and say, OK, how is this accessible?

And then, when you are experiencing something that conflicts with that VPAT, hopefully, we’re going to know that not everyone is procuring with accessibility in mind. But if you have a contract that states accessibility as a requirement, you can leverage that VPAT validation and say back to the vendor, no, this is not accessible. What are you going to do to fix this? Ideally, we would procure accessible content to begin with. But that’s still kind of a lingering doubt throughout the accessibility industry.

SOFIA LEIVA: Thank you. I believe we have time for a couple more questions. The next one we have here is, this is a great framework for multi-step training. Is this meant to be general enough to introduce everyone at the same time, or are there suggestions on how to target specific groups of people, specifically with different rounds of testing? And they mentioned that they’re thinking between the differences of designers, developers, and product managers who all can contribute in different ways.

EMILY OGLE: Yeah, certainly. When I started talking about the detailed level of training, I mentioned that is not an exhaustive list. And certainly, you can have very targeted trainings. So you can have role-based training.

And the introductory and mid-level training, they still all need to be included. Because unless you are training a bunch of accessibility experts, you can’t really know how much they’re going to know. But you can absolutely have training that focuses or is targeted to designers, focused or targeted to developers. And then the assistive technology section is probably something that would be similar to what you might provide for role-based training.

SOFIA LEIVA: Awesome. Thank you. The next question we have is, what are your thoughts on refresher trainings? How would you structure those?

EMILY OGLE: Refresher trainings. So refresher trainings are always beneficial– obviously. That’s kind of stating the obvious. So refresher trainings, I would recommend at least an annual cadence.

It kind of also depends on the roles that are targeted. If you’re going to have someone who is a tester, for example, you’re going to want to have more iterative refresher training. Because they’re not going to be a validation expert.

A refresher training doesn’t necessarily need to get to the level of detail. So it’s probably just going to include introductory or mid-level training. I wouldn’t say refresher training would need to necessarily be that specific at the detailed level.

SOFIA LEIVA: Perfect. The next question we have is, is there a color blindness simulator for PC or Android that you know of?

EMILY OGLE: Mm-hmm. Yes, there is. My favorite that I use is NoCoffee.

That’s one word, NoCoffee. I don’t know why it’s called NoCoffee. But not only does that stimulate colorblindness, it also simulates the various types of impairments that people with low-vision might have.

So people might have reduced acuity. They might have really blurred vision. And that NoCoffee simulator, which I believe is available only in Chrome, does a really good job of providing that at a glance experience.

SOFIA LEIVA: Great. It’s a great name for– [LAUGHS] –a product. The next question we have– I believe we have time for one more– is, do you recommend a minimum font size to use for trainings and materials?

EMILY OGLE: Yeah. You know something? That’s something I thought a lot about during the presentation.

I was trying to manipulate some of my fonts to be more readable. Because I was getting a little bit frustrated, because it just wasn’t cooperating for me. I do recommend keeping it 16 to 18-point font.

You want to really kind of avoid text- heavy slides, which I know a little bit ironic, considering the presentation I just gave had a lot of text-heavy slides. But you really do want to provide text that is an easily-readable format. So I would recommend larger text, like 15 or 18-point.

SOFIA LEIVA: Great. Well, thank you so much, Emily, and thank you to our captioner, Bonnie, and our interpreters, Sharon and Ben, for being here with us today. And thank you, everyone, for joining us.