MONICA OLSSON: Alrighty. Good afternoon again, everyone. Welcome to today's training. Before I begin officially, go ahead and give me some sort of visual indicator, a thumbs up or a nod, that you can hear me OK and also see my screen share. Awesome. Great. Cool. 

Well, welcome. My name is Monica Olsson. I'm the accessibility policy associate here at the State Board. I'm just almost at my year mark. Prior to that, I was the director for student accommodation office at one of our CTC colleges. And you're here today to spend a couple of hours together learning about Web Accessibility 101 with myself and my copresenters. 

So I'll move on to the next slide. And again, I've just introduced myself. I'm going to go ahead and turn it over to my colleague Marilyn to introduce herself as well. 

MARILYN VARELA: Hello, and happy GAAD day. My name is Marilyn Varela. I'm the website administrator, which means I support the external website and intranet. And part of my job duties are testing web applications for accessibility. 

MONICA OLSSON: Thank you. Greg. 

GREG GAMBLE: Yeah. Hello, my name is Greg Gamble. I'm a programmer here at the State Board. And I do the majority of the websites that are used by the State Board and the peoples. And I'm going to be showing some technical stuff for you. 

MONICA OLSSON: And Shaun. 

SHAUN HEGNEY: And I'm Shaun Hegney. I'm a program specialist at Spokane Falls Community College. There, I work in Disability Access Services, specifically intakes for students who are heavily visually impaired or have cognitive impairment. I'm also responsible for all the technology for our office. And I also do textbook remediation and document correction. And I'm here just to help out and provide you all with a screen reader demo. 

MONICA OLSSON: Thanks, Shaun. So today's training is just about two hours long. We have divided it into four distinct sections. Section 1 will be presented by myself. I'm going to provide us a working definition, an intro to the concept of web accessibility, definition and examples of disability and assistive technology, and the legal landscape that we all should be aware of as state agency employees. 

Section 2 will be presented by Marilyn. She's going to go more in depth about WCAG, technical standards, and POUR. And she's also going to log into Omni and give a site demo. 

Section 3 will be presented by our guest presenter, Shaun. He's going to talk a little bit more about screen reader technology specifically and provide you with a live demo. Section 4, last but not least will be presented by Greg Gamble. This is perhaps the most technical section of our presentation and is specifically geared to the web developers in the room today. 

Before we launch into the actual content, I do want to mention a few housekeeping items. We are recording today's training. Professional live captioning is provided. If you need to follow along for access please hit the CC button at the bottom of your Zoom screen. 

If you don't see the CC button, you might see on the right-hand side the three-dot ellipses. You can press that. And there should be a menu with several options. And Show Live Transcript, I believe, is the option that you want to press to see captions. 

We do have a short five-minute break scheduled after part 2 or section 2 of today's training. And you should have received an email with links to all of our presentation materials today, including the slide deck materials and resources. I can work to put that in the chat here in a few moments as well. 

OK. Section 1 is Intro to Web Accessibility. And forgive me, I'm going to minimize my screen just for a second to make sure I can put a link in the chat that might be helpful to you all. And then we'll get right back to it. Okey-doke. So right now what I'm copying and pasting is a Google Doc with all of our materials, links, and resources. 

If I can find the chat-- here it is. That's coming at you. The second Google Doc that I'm going to put into the chat is a little blog post that I wrote and recently published internally for State Board staff around GAAD, Global Accessibility Awareness Day, which is today. So you all are doing a good job celebrating by being here. 

So here's a link to that post. Now we're going to go ahead and navigate back to our PowerPoint presentation. Can you guys still see my screen? 

CHRISTOPHER SORAN: Yes. 

MONICA OLSSON: OK, great. Thank you. So before we jump into the more technical components of our training today, we all need to have a common working understanding of web accessibility, what it is. 

SHAUN HEGNEY: Sorry, we wanted to talk about questions before we got too far. 

MONICA OLSSON: Oh, thanks for interrupting me, Shaun. So we might be a little pressed for time during today's training, so we will be moderating the chat for questions. And we hope that at the end of each specific section, that presenter will be able to take between one and three questions. If there's a really urgent question in the chat, whoever's moderating the chat will let the presenter know. Thanks, Shaun. 

OK, moving on. So what is web accessibility or digital accessibility? And what does it have to do with disability and including people with disabilities? We can talk about it in a lot of different ways. 

Broadly speaking, what it means is that websites, apps, digital tools, and content are designed intentionally and developed intentionally so that people with disabilities who use assistive technology to control their computers and navigate the web can use all of these things equitably and as independently as possible. 

Specifically what this means is that people with disabilities can perceive, understand, navigate, and interact with web content. It also means that there are accessible avenues for people with disabilities to contribute to the web and create their own web content. 

What does accessible mean? The definition that I've chosen to share with you today comes from the Office for Civil Rights, or OCR. Back in 2014, they were involved in an investigation with the University of Montana, looking into some complaints around possible disability discrimination that was reported by several students at the University who were having trouble accessing their alternate format materials for their classrooms in time within a reasonable time frame. 

And from this resolution, we now have a very strong working definition of accessible that we can lean on, which means that individuals with disabilities are able to independently acquire the same information, engage in the same interactions, and enjoy the same services within the same time frame as individuals without disabilities or nondisabled people with substantially equivalent ease of use. 

Now I'd like to take an opportunity to show you a four-minute video. It is Introduction to Web Accessibility and W3C Standards. It's produced by the W3C Web Accessibility Initiative. W3C stands for World Wide Web Consortium. So let me pull up that video that I've preloaded. And then we'll move on. 

And then please, one of the other copresenters, please interrupt me if the audio is not working well in this video. OK, here we go. 

SHADI ABOU-ZAHRA: Hi, my name is Shadi Abou-Zahra. I'm the accessibility strategy and technology specialist at W3C, the World Wide Web Consortium. And today I'd like to tell you about web accessibility. The web is for many people an essential part of daily life at work, at home, and on the road. 

Web accessibility means that people with disabilities can use the web equally. For example, somebody who cannot use their arms and uses a mouthstick to type or someone who cannot hear well and uses captions to watch videos or someone who cannot see well and uses a screen reader to read aloud what's on the screen. 

Accessibility has many benefits. For example, captions benefit anyone in a loud or in a quiet environment. And good color contrast works better when there is glare. Also people with age-related impairments, such as reduced dexterity, benefit. In fact, everyone has a better user experience with an improved layout and design. 

A lot of accessibility can be built into the underlying code of websites and applications. Web technologies from W3C, such as HTML, provide support for many accessibility features, for example, features to provide text alternatives for images, which are read aloud by screen readers and also used by search engines. Also headings, labels, and other code supports accessibility and improves the quality overall. 

Good authoring tools, such as wikis, content management systems, and code editors, help create accessible code, either automatically or with input from the author. Also web browsers, media players, and apps need to support accessibility features. 

W3C provides standards to help make the web accessible, which are internationally recognized by governments and businesses. Most well known is the Web Content Accessibility Guidelines, WCAG. WCAG is also ISO standard 40500 and adopted in the European standard called EN 301549. 

It is built around four core principles. First, perceivable, for example, so people can see the content or hear it. Operable, for example, so people can use the computer by typing or by voice. Understandable, for example, so people get clear and simple language. And robust, so people can use different assistive technologies. 

Besides WCAG, W3C also provides the Authoring Tool Accessibility Guidelines, ATAG, which defines requirements for content management systems, code editors, and other software. And the User Agent Accessibility Guidelines, UAAG, defines requirements for web browsers and media players. 

There are over 1 billion people with disabilities or around 15% to 20% of the population. The UN Convention on the Rights of Persons with Disabilities defines access to information, including the web, as a human right. Most countries around the world have ratified this UN Convention and several have adopted binding policies too. 

Yet regardless of any laws and regulations, implementing the accessibility standards is essential for people with disabilities and useful for all. For more information on web accessibility, visit w3.org/wai. 

MONICA OLSSON: All right, everyone. Thanks for watching that video with me. I really appreciated sharing the fact that between 50% and 20% of our world population are people with disabilities. So it really is a good business to pay attention to accessibility and web accessibility in particular. So we'll go ahead and move on. 

So that video was produced by the W3C WAI, or Web Accessibility Initiative. And this group is the group that's responsible for developing the internationally recognized technical guidelines and web accessibility standards. We in shorthand, in the accessibility world, refer to those guidelines as WCAG or WCAG 2.1 AA. 

WCAG 2.1 AA are also the technical standards that are referenced in Washington state's web accessibility and IT accessibility policy, which we refer to as Policy 188. I'll talk a little bit more about that here in a minute. And Marilyn is going to go a little bit deeper into WCAG during her section as well. 

What is a disability? I've chosen to provide you with a working legal definition of disability that is given to us by the ADA, or the Americans with Disabilities Act, which was passed in 1990 and then amended in the early mid 2000 to expand the scope of disability that this federal law covers. 

So as I present this definition to you, I also want you to think about your own personal experiences with disability, whether those might be your own experiences, whether you have friends and family members that have physical or mental health disabilities or you know that you work with some colleagues that identify as someone with a disability. Think through those experiences and how those people might benefit from universal design and web accessibility principles. 

So the ADA defines disability as this. A person who has a physical or mental impairment that substantially limits one or more major life activity. Now, we can think about major life activities, and certainly the law does, in terms of things like cooking for oneself, bathing, personal care, that type of thing. But the ADA also recognizes learning and concentration or focus as a major life activity, which those things could very well be impacted by a number of different disabilities or impairments. 

This definition also includes people who have a record of having such an impairment. And it also includes individuals who maybe do not have a disability or perhaps are not considered to have a disability by their medical professionals per se but are regarded by society as having a disability. So those people would benefit from the protections of the ADA as well. 

This next slide is titled Disability in the Web. And I'm going to explain the picture or graphic that I've chosen to include here in a minute. The web accessibility standards that we're going to learn about here, WCAG 2.1 AA, those standards or guidelines that the WAI group have worked to write and develop strive to encompass all different types of disability experiences that might be affected by interacting with web content. 

And so today we can think about four main categories of disability. In the visual category of disability, we might think about people who have low vision. They have some vision. So perhaps those people use screen magnification software to enlarge the content on their computer so they can see the content. We might think about people who are completely blind and rely on screen readers to navigate web content and control their computers and people who are color blind. 

Auditory as a category of disability might include people who are fully deaf or partially deaf and hard-of-hearing. It also could include people who have auditory processing disorders. Motor as a main category of disability might include people who have limited fine motor skill or control. That would include me. I'm in this category. 

I experience a disability called CP, or cerebral palsy, that affects the left side of my body. And so I can't do things like turn a doorknob, pick up a cup of coffee, or type on my keyboard with my left hand at all. I use a special keyboard that allows me to type only with my right hands. But some people might not be able to use a mouse at all if they don't have any upper body mobility. So they might use voice control software to navigate the web and control their computers. 

Cognitive as a category could include people with learning disabilities, focus and attention disabilities, such as ADHD, and people who struggle to focus or take in large chunks of information at one time. So we might think about blocks of text that are not appropriately sectioned in different heading levels on a web page that might be hard for someone to take in and navigate. 

So now we're going to move on and spend a little bit of time reviewing the legal landscape as it pertains to disability civil rights and IT or web accessibility. I don't expect you all to become ADA or 504 experts by the end of this presentation. We're certainly not going to quiz you on it. 

But I do think that as a group, when we think about the content we're creating and putting out there for our colleagues, our students, et cetera, in our system to use and engage with, that we do want to be mindful of the legal landscape. 

So first I'll talk a little bit about two federal laws, the ADA, I mentioned earlier, and Section 504 of the Rehabilitation Act, which was passed in the '70s. And Section 504 was the first civil rights federal law to protect the rights of people with disabilities passed ever in the US. So it's really important part of our history. 

These federal laws work together to make sure that people cannot-- people with disabilities, excuse me, cannot be denied services or program access due to their disability. People with disabilities are entitled to use appropriate accommodations. So if someone needs a specific accommodation to access an event or a classroom activity, they're entitled to use that accommodation. 

These laws also ensure that people with disabilities have access to material of the same quality or rigor and within the same time frame or reasonable time frame as that of nondisabled people or people without disabilities. 

We also want to know a little bit about Section 508 of the Rehabilitation Act. This law specifically requires that all-- excuse me, I let someone into the weight room. This requires that all federal electronic and IT information is to be designed accessibly to people with disabilities. And that is the public as well as federal employees. 

There was a Section 508 Refresh that took place not too long ago in 2017. You can learn more about that by navigating to this hyperlink that I've provided in the slide deck. I think the biggest takeaway around Section 508 of the Rehab Act that I want you all to understand today is that the Refresh has a specific focus on functional technical accessibility. I'm missing a word on the screen that I'm realizing. 

And it also aligns-- the Refresh did a lot of work to align specifically with WCAG standards, which is important because Washington state, the state that we all work in, has a policy called Policy 188. And this policy states that all Washington state agencies must meet minimum IT technical accessibility standards. And they're referring to WCAG 2.1 AA. 

The policy explains to us that the procurement, development, and implementation of things such as instructional, administrative, or communication technologies and content must be accessible. So this includes things like college websites or the state board website. 

It includes things like our learning management tools and systems, student information management systems, training materials-- so if we're creating training materials that are going to be available system-wide on how to do or use something, we need to be thinking about how to develop those materials in accessible way to people of all different abilities and disabilities-- and assessment tools. 

OK. I know I'm going a little bit fast. You all are doing great staying with me here. We're going to now move away from the legal landscape. And I'm going to give you a brief introduction to AT, or assistive technology. You're going to explore this a bit more with Shaun in section 3. 

Broadly speaking, AT can be hardware and/or software. It can be low tech or high tech. And these are tools that help people with disabilities complete a task as independently as possible. So this might include things like screen readers for people who are blind. But it also could include things like voice command or voice control software, such as Dragon NaturallySpeaking, if someone cannot use a keyboard or mouse at all. 

It could include someone who uses a mouth stick to control their computer. And it could also include people such as myself who use adaptive keyboards or computer mice to operate their computer. The image that I've included on the screen today is of a person who is sitting in their wheelchair at their desk. And they are using a mouth stick that's connected to their iPad to help them control and operate the iPad. 

That concludes section one y'all. Thank you so much for giving me your time and attention. I'm going to hand it over to Marilyn now. Oh, actually, I do have time to take two questions. So are there any questions for me about section 1, intro to web accessibility? 

Don't be shy. And there's no silly questions. There's no wrong questions. 

OK. That's OK. We will provide our contact. We do have our contact information in one of those Google Docs. So if you think of questions later on or you want to chat more about web accessibility with me, feel free to shoot me an email with that. Thanks again y'all. And I'm going to turn it over to Maryland. 

MARILYN VARELA: OK. Thanks for hanging in here with us. If you make it through this section with me, we'll give you a short break as your reward. This part of the training is going to cover accessibility standards that our website must validate against. We will cover what the standard is, how we know if we meet it, and what we can do to make our website pages more accessible for everyone. 

To make our website content accessible, we need to understand our users and how they consume our content. We must be aware of the roadblocks we may create and how that affects them. The illustration that's on your screen shows that one size does not fit all. 

A standard bike does not work for someone in a wheelchair or for tall or small people. By making modifications to the bike, it works for everyone. We can do this with our content as well. We need to be aware of our users and what their needs are in order to provide content that works for them. Next slide. 

The standard we hold our web content to is WCAG 2.1 AA. WCAG stands for Web Content Accessibility Guidelines. The current specification is 2.1. And we adhere to level AA, which is a medium target. A is low. And AAA as high. AAA is almost impossible to achieve. AA includes all of A as well. 

To understand if our site meets the specification, we need to check for POUR. POUR stands for perceivable, operable, understandable, and robust. What exactly does that mean? Let's look at some examples. 

Perceivable. Perceivable means that someone can hear, see, or touch your content. In order to be perceivable, your pages should provide text alternatives for nontext content like charts and graphs, alt tags for images, captions for videos, and include an audio description of what is happening in a video like an onscreen text, characters' actions, scene changes, et cetera. 

Operable. Thank you Monica. I can't walk and chew gum at the same time, so Monica is driving for me here. Can someone interact with your site? Is there an alternative way to fill out forms or control a video? An accessible site should allow for the ability to input information in form fields through a keyboard or mouth stick. This includes word documents, Google documents, and PDFs. 

Tab items in the correct order. Keyboard users should be able to tab through interactive elements in the correct order. And I'll show a demo of this later. Headings should describe topic or purpose. Touch targets should be big enough for large or impaired fingers. 

Understandable. Is your content understandable by someone with a cognitive disability or someone who speaks English as a second language? We writing for the web is different than other types of writing. You already know how to use plain language, bullets, and whitespace. Summaries and illustrations can also help users grasp content quickly and meaningfully. 

Things to check for include, the site functionality should be easy to navigate. The link should be obvious and indicate where they will take the user. Form controls must be labeled. Greg will cover that later. Navigation must be consistent and predictable. 

Robust. Does your web content work on all types of devices and older browsers? Do you have large images that take time to download on a mobile device? Does your content change size to fit the user's screen or do they have to scroll? If we build websites according to WCAG standards and we use valid HTML and ARIA, which stands for Accessible Rich Internet Applications, they should provide a robust experience for all of our users. 

ARIA is a set of attributes that define ways to make web content and web applications, especially those developed with JavaScript, more accessible to people with disabilities. Robust criteria are accomplished through the coding of websites and applications, which Greg will cover more in depth in his segment. Items that pertain to page managers are, a telephone number input field in three parts must announce all three parts, the area code, the prefix, and the suffix. Use button HTML code, not a div or a span tag. 

Now we're going to talk about semantic HTML starting with heading structure. Heading structure is important for those using assistive devices or not. When using headings, keep it simple. Do not skip heading levels. List headings in the correct order. 

Think of headings like a nested list or subitems. There should only be one H1 on a page. In this illustration here, it shows subcategories under main categories. So level two is the main category and heading level three through six are subcategories that should be in the correct order under the main category. 

Alt text. When you're using image alt text, it should not include picture of or image of. Screen readers automatically announce an image as an image. So an alternative text image of an apple would be read aloud by a screen reader as image of an apple. 

When using alt text, we need to use correct grammar such as capitalizing the first letter and ending whole sentences with a period. There's a link here and in your handout too that goes further into how to write good alt text. 

Hyperlinks. No more click here. Hyperlinks need to be descriptive. Click here and read more do not tell a screen reader user if the link is worth clicking on because they don't know where it will go. Since screen readers can read all the links at once, click here is useless and many click heres are annoying. Shaun will demonstrate this in his section. 

Color and tables. To achieve good color contest-- crap, contrast, use approved color themes from Communications. The link is in your handout materials and on this slide. The guide is on StaffNet. This applies to word documents, PDFs, and presentations as well. Templates for these documents, which are accessible, are also on StaffNet in the same area. 

Don't use tables for layout. Tables are for data. Use simple table structure or markup complex tables correctly, making sure the headings are correct. So now that we've gone over that let's see these concepts in action. In this demo, we're going to-- oops, can you back that up a second, Monica. 

MONICA OLSSON: Yes, I stopped my screen share too early. I was trying to give you control. OK, we're back. 

MARILYN VARELA: So in our demo, we're going to check for accessibility on your pages or how to check for that, how to use styles for tables, how to set header rows for tables, and how to identify and fix broken accordions. And then I'm also going to show you a tab order on a form. OK. 

MONICA OLSSON: OK. Are you ready to take over control now? 

MARILYN VARELA: Yeah. 

MONICA OLSSON: OK, I'm going to stop my share. There you go. And as Marilyn's pulling up her screen share and she's walking through a live demo with us, I can help moderate the chat in case there's an urgent question that needs to come through. 

MARILYN VARELA: Can you see the screen OK? 

CHRISTOPHER SORAN: I can see the Omni CMS. 

MARILYN VARELA: OK, thank you. Sound like Christopher. Appreciate that. 

CHRISTOPHER SORAN: That's me. 

MARILYN VARELA: All right. So in order to check our page for accessibility, it needs to be checked out and then you go to Page Check. And I would encourage everyone who is a page manager to run this before you submit your page for publication. It will tell you if you have spelling errors, broken links. 

But what we're going to look at today is W3C valid errors. And this is telling us that this beautiful page that I created for Shaun for a demo is totally broken on purpose and that it doesn't have-- it's missing an alt tag. And it's missing it on this image. 

We also have some accessibility problems, such as our headings are not in the right order. We have text that doesn't have a good enough color contrast in order to be accessible. And again, we're missing an alt tag. And we have a suspicious link text Click here. Read More should also pop up there. 

And then I want to talk real quick about the color contrast of text. This will tell you-- it should be 4.5 to 1 or for large text, three to one. And the first number is the luminance of the light colors relative to the second number, which is the luminance of dark colors. So now that we know what our problems are, let's go fix them. 

OK. So this looks like a header. But it's marked up as a paragraph. And so it's not a header. It should be a header two, which means that a screen reader would totally miss the content because somebody who's navigating their screen with headers is going to not get that because it's marked up as a P instead of a header. 

Our next header on the page is an H1. There should only be one H1 on the page. And the pages all have the H1 as the title right here. So we know that we can't have an H1 down here. So this right here should be an H2. And I'm not going to actually fix them because then Shaun's demonstration won't work. But I think you guys all know how to fix that. 

The next issue we have is a table that doesn't have any headers. So a screen reader would not be able to associate the columns with the cells. So to fix that, do a right mouse click. Go to row properties and change this from body to header. And here again, I'm not going to do that because then it will work. 

And then we need to check-- our Click here link needs to have a better description. And then for other issues in our other column, we have text that is not sufficient contrast. So to fix the text, you would go to StaffNet and get the approved color palette and then pick the color. And you can put in the RGB or the hex value for that color, which is in the guide on StaffNet. 

The next problem we had was an image that did not have alt text. So we would need to put descriptive alt text in here that basically explains what this image is portraying. Then the other thing I want to show you is right here we have some red text. It says, don't close this window until you are finished. And then we have a green check and a red check. 

So I'm going to-- no, I don't want to save my changes. Thank you. OK. So in order to check colors on our website, you would press Control-Shift-I on my Windows machine, which brings up your developer toolbar here. And we want to go to Accessibility. That little window is like right over there. And then we want to pick simulate. We're going to go with the no red. 

So this will show us what our website looks like to someone who doesn't see red. And that text that I told you about right down here that says, don't close window until you're finished, is not going to stand out to somebody who can't see red. 

If you use color to indicate progress on a web page, somebody who can't see red or green is not going to see the difference in your color. So you need to use another way to indicate that. And then for no green, this is what the site looks like to people that don't see green. So here again that red text doesn't stand out. And the checkmarks don't stand out. 

Now, we talked about tabbing. So somebody should be able to tab through our page. We have this nice little skip to content on all of our pages, which is an accessibility feature. So basically, somebody should be able to use a keyboard and get through our page and be able to interact with it. So these tabs should all be in the correct order. 

And when you get to a form, you should be able to use your down arrow and your Enter key to tab through the form. And the fields should be in the correct order. And then you should be able to submit the form with the Enter key. 

All right. Now I'm going to go back and show you the accordions real quick. So one of the things that I've noticed a lot when I publish content is that we have issues with accordions. And they're not terribly user friendly. So if we run our page check on this page, it will tell us that we have a problem. 

We don't care about that one, we might about that one. But this is the one I'm looking for. So this is telling us that we have the id accordion1 being used twice on this page. And you can only have one ID. The ID on a page has to be unique. 

So I want to show you what that does. We have two accordions here. The first one and the second one. Since the idea is the same on both of them, the first one works. The second one does not. If you have an accordion that's broken, you have a pretty good idea that maybe there is something wrong with the accessibility on it. 

So in order to fix this, all we have to do is go into our accordion and find the name of the section. So there's accordion1 there. And there's accordion1 there. So if we change this to accordion2-- and I'd recommend that you give these a little bit better descriptive names but you don't have to. We're going to save that. 

And now when we go preview it, this one works. And this one works. And we shouldn't get that error anymore. So we still have an error but not that one. So that is all I had for my section. 

MONICA OLSSON: Thank you so much, Marilyn. That was great. I'll go ahead and screen share again. In the slide deck here, Marilyn's included a list of references and resources you all can refer to as you'd like. And we do have time for Marilyn to take a couple of questions. 

I know this is a lot of really good information to be soaking in, so you might also be processing. But if there's any question out there, especially from our web content managers, our page editors, feel free to ask away. 

MARILYN VARELA: Monica? 

MONICA OLSSON: Yes. 

MARILYN VARELA: I'd also just like to say that if someone has a page that they're struggling with or there's items on it that they don't really understand, that if they don't want to bring it here, that they can send me an email. And I can work with them on that also. 

MONICA OLSSON: Thank you for that offer, Marilyn. So as you're editing your pages and doing your W3C and accessibility checks, if you're not sure how to fix an issue, you can send Marilyn a private email. I've done that myself. There are error messages that I receive that I don't understand as I'm not a trained web developer myself. And so I still need to reach out and ask clarifying questions with my colleagues and get some support too. We're all in this together. 

So if there aren't any questions, then let me go ahead and make sure there's nothing in the chat that I've missed. Nope. We'll go ahead and take a five or six minute break now. So feel free to get a cup of coffee, go to the bathroom, do whatever you need to do. And we'll be back in our seats at 1:55 and ready to start again with Shaun at 1:56. See you soon. 

I hope you all are back in your seats. Without further ado, I'm going to hand it over to our guest presenter and colleague, Shaun, who's going to talk a little bit about screen readers with you and provide a demo. OK. So we're now in section 3 with Shaun. 

You all still see my screen here? I hope you can. OK. Thanks for the thumbs up Nanette. You have this in the Google Doc. I sent you in the chat. If you want to pull up those demo pages that Marilyn created, you're welcome to do so and follow along that way. So we have an accessible or good page URL link as well as an inaccessible or bad page URL link. 

And then I've also included a link to Deque University's NVDA screen reader keyboard commands in case you leave here inspired to download that free screen reader and explore yourselves. Alrighty, Shaun. So I've got the screen reader basics screen up and viable for everyone now. 

SHAUN HEGNEY: Thank you, Monica. Hello again, everyone. My name is Shaun. As a reminder, I'm going to be giving you a demo and talking about what it feels like to use a screen reader as a user in hopes that it gives you more perspective on why this is so important. 

Just to give a little background, I am actually a part-time screen reader user. I mostly use magnification, such as Windows Magnifier or ZoomText. There are other programs and other AT out there that people use access to computer. We're just looking at one variety right here. 

So what is the screen reader? A screen reader is basically a piece of software that someone with low vision or no vision uses to navigate and interact with their computer. The goal is to have independent interaction and operation of the computer. So someone shouldn't have to say, can you come sit here and help me with this? 

You should be able to fully interact on anything else someone else without a screen reader can do or can use. So you're going to see to use two different sets of screen readers, first party and third party. First party is something like Microsoft Narrator for Windows or Voice Over for iOS and Mac. Those tend to be built into the operating system. 

Another example would be Talkback on Android. Linux also has its own version. Some screen readers are third party such as JAWS and NVDA. They're made by independent companies. Some AT, such as JAWS, is purchase-only. So you need have to have a subscription or you need to buy a license outright. 

But NVDA, which is a product we're going to be dealing with today, is free. And you can download it, as Monica mentioned. NVDA is Windows only, just to be aware. So now I'm going to share my screen. And I'll get set up on the good page. And then we'll kind of walk through that page together. I'll try to explain what you should be seeing, what you are hearing. 

As a reminder for anybody who hasn't seen a screen reader, you're going to hear a lot of feedback of my talkback from a computer voice to you. The more experienced a screen reader user is, the less feedback they need. But since I'm only a part-time user, I need a little more feedback. 

It is a little uncomfortable, a little weird. Please just kind of hang in there because it's uncomfortable and a little weird to use one as a user. So we'll start with the good page and then move on to the bad page. And then I'll have some time for questions for you at the end. 

SCREEN READER: SBCTC trainings. 

SHAUN HEGNEY: Monica, is anybody getting-- can hear the audio come through? 

CHRISTOPHER SORAN: Yes. 

SHAUN HEGNEY: Thank you, guys. So this is our good page. And so I'm just going to-- what we're going to do is we're going to walk through the page using major landmarks. So first, we're going to try headings. Then we'll try lists, then tables, and then graphics. So I'm going to just walk us through the page. 

Just to note, you may not follow along exactly with what-- the image may not follow exactly what is being said. There's partly a limitation on NVDA not following exactly perfectly. And I'm using a little bit of magnification so I can see the screen. But I'll try to call out and make sense of what you're hearing. 

And you're going to want to notice on this page that you hear things that make sense. This should be reasonably navigable by ear. And then you can hear the difference when we hit the bad page. So we're just going to try to navigate by headings. 

SCREEN READER: No next heading. 

SHAUN HEGNEY: OK, hold on. So that's something else that sometimes happens. You get kind of stuck in the wrong spot in the page. That's kind of unfortunate reality of screen reader. You just have to kind of work to get back into where you want to go. 

SCREEN READER: A to Z. Search. Paying for college. Main landmark, the A to Z index is where you'll-- history frame. History grouping. 

SHAUN HEGNEY: Let's see if those are still working. 

SCREEN READER: Grants and allocations available for application heading level two. 

SHAUN HEGNEY: So it did skip heading level one. It is correct. It is there. When you saw that little error weirdness was just sometimes the screen reader is not focusing where I want it to. That's kind of the reality of using the screen reader sometimes. So you kind of bounce out of focusable elements. As I said, we're going to be moving down header by header. So those are the main anchor points on the page. 

SCREEN READER: A long list of links heading level two. Commissions and councils heading level three. Colors heading level two. This image has descriptive text that conveys what is in the image and doesn't say image of. 

SHAUN HEGNEY: We'll come back to that image in a second. But as you can see or here, excuse me, you should be able to kind of remember where you are relatively well, the tags are correct, and that they're going down the page. Then they increase, so H2, H3. Just think of it like an outline. If it makes sense, that's a good start. 

SCREEN READER: Colors should not portray important-- no next heading. 

SHAUN HEGNEY: I guess I reached the end of the headings. And then we'll skip back up to do lists and information in the list. 

SCREEN READER: Browser tabs toolbar. Navigate. Saved bookmarks to accessibility. 

SHAUN HEGNEY: That's a good thing I was going to point out. If you can navigate via tabs through your page, that's a good sign. That means that your order is reasonable. So if you ever wonder, just want to get a quick sanity check, just run through your page by using tab key only. 

Now we're going to look at list. So the list should give me indication of what the name is, how many items are in the list. And then it should give me a chance to-- 

SCREEN READER: David Kaufman. Click to search bar. Main landmark, the A to-- list with nine items. Bullet, Washington Association of Community and Technical Colleges, WACTC. 

SHAUN HEGNEY: So now I can also go down into the list. 

SCREEN READER: List with one items. White bullet, Presidents' Assistants for Community and Technical Colleges, PACTC. Bullet, Business Affairs link Commission, BAC. Link list. White bullet, Budget Accounting and Reporting Council, BAR. Link. White bullet, Operations and Facilities Council, OFC. Link. White bullet, Budget Accounting and-- list with seven items. White bullet. 

SHAUN HEGNEY: So what happens is you also can notice that we have good naming on the list here. They're not read here or click for more or the long address form address of a page. I can understand where I'm going, what I'm looking for. Especially in a list that's technical, that's really important because if it just say, for example, click here, read more, what am I even going to start. And then the user will kind of just basically not interact with anything. 

SCREEN READER: List with one item. List with eight items. White bullet. No next list. 

SHAUN HEGNEY: OK. So we've reached the end of the list. 

SCREEN READER: Public Information-- Remote Control. Meeting. More. Bullet. Mute. Audio. Meeting control has been docked to the bottom alert. Exit. 

SHAUN HEGNEY: So we also want to talk about the idea of alternate text. If you mentioned an image in the website or it's relevant, you definitely want to describe it. As we went through headings, there was an image mentioned through in passing. So we're going to come over back to that image as an example. 

SCREEN READER: Closed. Open app. HEUG logo has the outline of a graduation cap in orange above the navy blue HEUG text in all uppercase with sentence case text below that, which reads Higher Education User Group. 

SHAUN HEGNEY: That's good alt text. It's short. It's clear. Sometimes you may skip something like this since it's a logo. But since you mentioned it specifically in the page, you want to make sure, OK, I've used alt text that's clear and concise. So now we're going to move on to the bad page, which should contrast pretty strongly with this one. It would be less logical, harder to follow. 

MONICA OLSSON: This is Monica. Sorry for my interrupting. Before you move on to the bad page, could you show us table navigation and-- 

SHAUN HEGNEY: Yes, thank you. I totally forgot tables. Thank you, Monica. 

SCREEN READER: Application. Edit cursor. No next table. Navigation. Save. Skip to content link. Mainland mark, the A to-- table with six rows and four columns. Row one, column one, application. 

SHAUN HEGNEY: Like Monica I mentioned, we also want to talk about tables. As you can notice, we had a clear understanding of how many rows and columns. This is an application's table. This is super important if you have a table to make sure you mark it up correctly because if I was a visually-- if I had no vision as a user, I would never know where I'm going to be at in the table when it's not marked up correctly. So I'm just going to move you around in the table. And you can just listen to what that sounds like. 

SCREEN READER: Row two link, High Demand. Row three link, Perkins Leadership Block Grant. Release date column two, April 15, 2021. Due date column three, continuous through May 31. Final report due column four, July 31. Due date column three, 2022, 31. Final report due column-- row four application column one link, Perkins Nontraditional Gender Employment and Training Grant. 

SHAUN HEGNEY: So as you can see, when I'm moving through the application table, I know what I am or row I'm in. I know what information is relevant that we have. Here, it will play out-- it'll say out application, release date, due date. Without that, I'm just getting a bunch of information doesn't make any sense. 

So we'll contrast this with the bad page, which should be, like I said, a lot less logical and a lot more frustrating. So just give me one second. And we'll move over-- 

SCREEN READER: The A to Z-- Accessibility Demo. Washington State Board for-- 

SHAUN HEGNEY: So we're just going to try to go, again, through headings, lists, tables, and graphics. And we'll just see what happens. 

SCREEN READER: Main landmark, Accessibility Demo Bad Page, heading level one. 

SHAUN HEGNEY: So far, we're OK. The title heading within that's fine. 

SCREEN READER: Programs and Services, heading level two. 

SHAUN HEGNEY: And again that makes sense because that's following-- you only have one H1 and one-- from there on out, you'd be H2, H3, and so on. 

SCREEN READER: Grants and allocations available for application, heading level one. 

SHAUN HEGNEY: OK. Then that's confusing. Now I'm thinking, is this the actual title of the page? Is this what I'm supposed to be reading the title? If I had no vision, I don't know where I'm at now. Did I get pushed back to the top? Am I in the wrong window? What's going on? 

SCREEN READER: A long list of links, heading level four. 

SHAUN HEGNEY: OK. Now I'm really confused because I don't know where H2 and H3 went. So am I now in the list? Did I go to the wrong page? So now the user has to either start over again or just kind of hope they figure out where they're going because otherwise there's no logical flow to this page. 

SCREEN READER: Commissions and Councils, heading level two. Colors, heading level two. This image needs descriptive alt text, not just something that says HEUG logo. Heading level three. 

SHAUN HEGNEY: So that's technically correct. But because of the other parts of the page, I'm still not sure, am I on the right spot? I'm going to be missing something? 

SCREEN READER: Color should not put-- no next heading. 

SHAUN HEGNEY: So this is, again, a reminder a heading is very important because someone without vision needs those headers as anchor points to say, OK, I'm moving through the page in a logical way. And when you skip a header, you put in another H1, I literally don't know am I halfway up the page? 

Am I in a different page? We know what happens. And the more frustrated a user gets, the more likely they're not going to engage with your content. So something to keep in mind. 

SCREEN READER: Navigation toolbar. SBCT Saved. Bookmarks tool. Accessibility demo bad page. 

SHAUN HEGNEY: So now we'll try lists again. 

SCREEN READER: No next list. 

SHAUN HEGNEY: Come on. 

SCREEN READER: Navigation tool. Collapse. 

SHAUN HEGNEY: So there's one thing I want to also mention that your choice of browser and software can sometimes conflict. Sometimes it can change down to one release the way or from when you knew it was good, it can change. So if you're getting some weirdness from a screen reader, it might be software incompatibility. 

NVDA, it's free. And it's very honest because it's not quite as tricky and specialized as JAWS. JAWS may give you some false positives that something is going to work. But NVDA is a good minimum. And then it's more bare bones. And it's freeware, so just something to keep in mind when you're working through your pages. 

SCREEN READER: List with eight items. Bullet, Washington Association of Community and Technical Colleges. List with one items. White bullet, Presidents' Assistants for-- list with three items. White bullet, Purchasing Affairs Council, PAC. List with one items. White bullet, read more. 

SHAUN HEGNEY: So now what's that read more about? We're in a long technical list. And I have no idea where that link goes to. Am I going to click it? I don't know, maybe. But there's so many links here to explore that literally adds value-- that takes away valuable time from your reader. 

SCREEN READER: No next list. 

SHAUN HEGNEY: So now we're going to go back into the table and see what that looks like for that proper markup 

SCREEN READER: Browser tabs. Save bookmarks. Accessibility demo bad page SBCTC. No next table. Main landmark, the A to Z-- table with six rows and four columns. Row one, column one, application. Row two link, High Demand Funds Program. Row three link, Perkins Leadership Block Grant. 

SHAUN HEGNEY: So all that sounds right. It sounds fine. But I don't know where-- I don't know what am I actually reading about. I don't see the application point. 

SCREEN READER: Column two, April 15. 

SHAUN HEGNEY: That date means nothing to me. Is that a due date? Is that a release date? I don't know what I'm listening to. 

SCREEN READER: Column three, continuous through May 31, 2022. 

SHAUN HEGNEY: So what's continuous application, deadline, the due date? I don't know. So just to keep in mind that something that seems simple as just like a table and it seems like it sort of works, you have to think about, if someone has no vision, no visual reference at all, what are they going to hear? 

And I want to come back over to our alternate format image here, which this-- reminder, this image is mentioned right above the image itself, so therefore it's relevant. Therefore, you want alt text. And we had nothing. 

So now I go, well, what's so important about this image? Is it important? Am I missing something? And if content is important, you don't want your client or your reader to miss it. 

SCREEN READER: Colors should not-- 

SHAUN HEGNEY: Another example here is we have checkmarks. So if these were important, I wouldn't know they're here. Another bad example of alt text is using a file name and putting a file name, like read check or rain check. But I don't know what they're for. Are they decorative? I don't know. 

So that's my presentation using NVDA to go through a web page. As I said, there are several different screen readers that other AT people might use such as magnification or text-to-speech. That's just one way someone's going to access your page and why it's so important to be accessible. Monica, do we have time for questions? 

MONICA OLSSON: Hey, Shaun. Thank you so much for that awesome demo. We're lucky to have you here with us today. And yes, we have time for maybe even three questions. So does anyone have a question for Shaun about using the screen reader or anything you saw today or heard today in our demo or any comments? I'm curious if anyone in the room today, if this was their first time experiencing a screen reader navigating and reading content out loud. 

PAUL KREEMER: Hey. So Shaun showed us the NVDA reader. And I went and installed it quick. And it was kind of cool. It was talking to me right from the start, telling me what it was doing on the install. So it's just like-- yeah, it's really cool to use those tools. 

SHAUN HEGNEY: Yeah, I have it muted just because it'll talk over me. And my hand is basically on the Control key. So if you guys are ever playing with NVDA and you want it to stop talking, just hold Control because if I would have not had Control down, it would have been talking over me the whole time. Yeah, it will give you navigational and landmarks throughout the operating system. So you can actually just kind of mouse over things and see what they say. 

MONICA OLSSON: Thanks, Paul, for your comment. I'm excited to hear you download NVDA today. Alissa, I see your hand is up, so feel free to take it away. 

ALISSA SELLS: Hi, Shaun. This is Alissa. I just have a quick question for you. Did you slow the audio down for us so that we could understand it more or do you usually listen to it a little faster? Because I've seen screen reader demos before where it was going so fast I couldn't even understand what it was saying. And this time it was a lot easier to understand. So I was just curious what speed you typically listen to yours at. 

SHAUN HEGNEY: So yeah, as you know-- being upfront about it, I tend to prefer magnification with some text-to-speech for my preferred method. So I use ZoomText magnification with a little bit of speech here and there, especially for long documents. But as a screen reader user, I'm not as-- like I mentioned, the user that gets really proficient tends to need less speech. And they tend to make it faster and faster and faster and faster. 

So I definitely had to slow it down for me because I'm trying to hear feedback too. And I knew that-- I'm going to be honest. The different voices from most screen readers are pretty bad. NVDA has this weird-- I mean, not weird. I should be nice about it. It's a very specific English-speaking man. And he's kind of robotic and English accent at the same time. And I can't understand him. 

If you guys are looking for better voices in NVDA, if you go in and switch the voice to Microsoft, I think it's sound API 5. I use David. And I slow him down to about a rate of 50. So yes, I did slow him down quite a bit because they really default to a high speed. And if you're that's what you learn on, that's what you work on every day, it's fine. But as a user who is just occasionally working in that area, I can't keep up. 

MONICA OLSSON: Thanks, Shaun. Nanette, I see that you've got your hand raised. So feel free to unmute yourself and ask your question. 

NANETTE ANGEL: OK. Yeah, the screen reader demo was really interesting. I could feel myself getting overwhelmed just trying to listen to the normal page let alone the bad page. But I decided to go to a couple of our pages on the website and tab through. 

And I was wondering, like on the Becoming a Student page and several of our other pages, there's the little image squares. And they have an ellipsis on the side. And ellipsis, when you're tabbing through says more. Does the screen reader pick up more or wouldn't that be like click here or does it say it's an ellipses? 

SHAUN HEGNEY: Still on the screen reader, if I was to slow down and go through the actual, like the collapsed lists on top, the navigation list, it will say like , more or next or it'll give you some indication. If I was being a little more technical, you can navigate through those. It just takes a little more work. 

You'll also get that when you go through the footer. When you go through the graphic links, it'll tell you what the graphic is and where it's going to go. That tends to be how someone would navigate through. They would get through the menu, find out where it's going. And then they either hit Return or click to go through to the next page. 

Generally, pick more set up. Like I said, I have to say generally because every screen reader is a little different. And some screen readers do some things better than others. NVDA is pretty good as long as you're compliant. But sometimes it just misses some things. That's why I like to test with both JAWS and NVDA when I have a chance. 

For an example, I was proofing a PowerPoint for a colleague of mine. And JAWS said it was fine and NVDA said it wasn't. So that just gives you some perspective on different screen readers have different abilities. 

MONICA OLSSON: Thanks, Shaun. Thanks, Nanette. I'm glad to hear that you went on a page and started tabbing through to look at the tab order of some of our web pages. We have time for just one more question or comments. So if there's anyone out there in the audience who has a question or comment, feel free to raise your hand or unmute your mic. 

Alrighty. Well, thanks again so much, Shaun, for your demo and for sharing some time with us today. We're lucky to have you. So I'm going to pull up my share screen and PowerPoint slide here again and get us moving into part or section 4 with Greg. So just give me a moment. 

OK, everyone. Thanks for hanging in there with us. I hope you're having some fun. And there's a little bit of information here for everyone no matter what skill level or exposure to accessibility you came here with today. We've made it to our last and final section of our training today, section 4 with Greg Gamble, Web Development Basics. 

Just a note for everyone in the room today, this section is perhaps our most technical section. And it really is geared to the developers in the room. So if you're not a developer and you're a page content editor, you're more than welcome to stay and hang on and listen. And hopefully you're going to learn some interesting things. But if you feel like this section might not be your speed, you are welcome to leave now as well. It's totally up to you. Just wanted to put that out there. 

In the Google Doc link that I put in the chat and our materials and resources, there are links to the site that Greg created for his demo today. And then he's going to be touching on ARIA and alerts a little bit. If you want to read and learn more about ARIA, alert role or aria-atomic, we've provided some links in our presentation and our resource, Google Doc as well that you can access on your own after today. 

So these are the topics that Greg is going to discuss with us today. He's going to talk a little bit about the Bootstrap framework and the use of proper and semantic HTML. He's going to talk a little bit about alerts and ARIA. He's going to show you basic form layout and input labels to make sure that screen reader technology or other assistive technology can navigate and input information into a form accessibly. And also he's going to talk a little bit about modals. 

So without further ado, I'm going to hand it over to Greg. Let me check real quick and see if there's anything in the chat. Nope, Nanette just saying thank you. OK, Greg. I'm going to mute myself and hand it over to you. 

Greg, if you're talking, you are still on mute, my friend. 

GREG GAMBLE: OK, it won't let me share because somebody else is sharing. 

MONICA OLSSON: I do see your screen share. 

GREG GAMBLE: OK, let me try one more time. 

MONICA OLSSON: OK. 

GREG GAMBLE: Can you see the site. 

MONICA OLSSON: Yeah, we see your site. 

GREG GAMBLE: Oh, OK. I was expecting it to come up on the other side. So what I'm going to do is talk a little about frameworks, semantics, basic HTML. We're going to show you some alerts, some modals, and some basic forms. 

All of the sites that I do, I use a framework that's called the Bootstrap framework. It's probably one of the most popular ones out there. There are several. Besides Bootstrap, there is Foundation, Skeleton, Materialize, which is the one that Google use, which is just kind of a flat look. 

There's like three or four, maybe five other frameworks out there. And a framework is pretty much the way to go. If you're doing a lot of sites and you're not using a framework, you're probably reinventing the wheel each time you create a site because the framework will give you something that it's a nice standardized look, feel. 

You can have different colors and different themes in the framework. But the way the site works and the way that you create it, it's pretty much going to be standardized. So you get your work done a lot faster. 

They're easy to use. There's a lot of how-tos for the Bootstrap. It uses the grid framework for positioning. And the grid framework, if you're not familiar with it, is what newspapers used when they originally started doing typeface, setting up content in a logical order. So that's what Bootstrap use. Most of the big bigger frameworks use a grid format. And Bootstraps uses 12 separate columns. 

Semantic HTML. Basically, HTML5-- oops, sorry about that. HTML5 on its own is accessible It's one we get into doing special things like pop-ups, tool tips, special like dropdowns, big forms. When we start using that, that's when we started having problems with accessibility. But the screen readers or any of the accessible technology that someone may use understands HTML. 

So, for instance, if you have a paragraph, put it in a p tag because it understands that that's a group of texts that's all together. If you have a list, put it in a list tag, a ul, which is an unordered, or an ol, which is an ordered list. So it'll add 1, 2, 3, 4. 

There's another one. And this is what I have in this one. It's called a definition list. It's a dl tag. And it has a dt tag to start out, which is like the header. And then there's the body part. So it automatically does this bolding right here. 

So these are tied together. So it knows like here's the definition-- or, excuse me, here's the title. And then this is the definition for that title. And when a screen reader goes to read this, it understands, OK, blockquote. And it's going to automatically go down to this because it knows that these two are tied. And that's semantic HTML. 

There's another one that we use. And it's called a div. That's a definition tag. And this is how we use to create sections of a page. And Bootstrap uses this quite a bit. And that's how it defines its columns. If you really want to get into it later on, we can have another show and tell on this on how to use Bootstrap. 

So if you have a basic site, use the HTML as it's supposed to be used. Don't use things like-- like on this example, a blockquote when you use as a tag. And what it does is it's automatically styled so that it indents all the text. So if you want to indent text, don't use a blockquote, unless it's actually a quote. If you need to indent stuff, that's what's CSS is for. 

OK. So next, alerts. When I originally started creating websites, alerts were one of the big problems with accessibility. Showing an alert is no problem. But getting a screen reader, especially a screen reader to notice it was a problem. 

So I started getting into the ARIA keywords and search. And I found something that worked. And what I'm using, well, let me show you what it looks like. This is going to be-- I'm going to call the OK Alert. And it pops up right here. This is a standard that I do on all of my sites. So if I have an error, some kind of error message, it shows up here. 

And all this is, it's a div tag. And I have a role of alert. Now, I could have used something called aria-live="assertive" because they're basically both the same. What it does is that when there is text-- let me see. Let me explain this a little better. 

There's a div tag in here. And then I have a literal. And this literal is basically a placeholder. So when I have text I can put into this placeholder programmatically, it will show up. And so this has changed. And the role alert notices that. And you have this, what they call aria-atomic. aria-atomic makes sure that the screen reader stops what-- or the browser stops what it's doing and announces to the screen reader that, hey, something has changed here. 

So what happens with role alert, like I said, it's like an aria assertive, which basically shows the text or the content. Role alert also when it makes attention to the screen reader, it says alert. aria-live just won't say anything. It'll just say, there's a new text like that. And I'll have an example of this with the modals. 

So when I click on this, it shows this has changed to this. So there's a change. And what happens, it'll say role alert-- or, excuse me, it'll just say alert, then a new alert shown. OK. And that's the text that is shown inside there. 

If you notice that there's an icon on here. And that's just for people that are visual users because I use what we call aria-hidden="true". And what that does is that it tells the screen reader to just skip it over. Don't worry about it. Just ignore it. 

If you've noticed also-- yeah, OK. Different colors. The screens don't show up or the colors don't show up when the alert is noticed or notified. But that's why I have the icons. It's just a look thing. So you notice that one is a check box. And there's like an alert sign. 

Then when I do clear alert, it clears. And it says alert. And there's nothing there. So it ends up looking like this down here. So there's no more text in there. What if I do this, it populates that inside there. And then the screen reader will announce alert, new alert shown. OK. And you have the link to this site, so you can see how I am doing that. 

One other thing I want to show, you notice how this is jumping up and down? It goes up to the top and this one drops all the way down. I have this. It's some JavaScript that I use because some of the pages that I use are fairly long. You've got to scroll through them. 

And since this is at the top, an alert or a screen reader will announce it whether you see it or not. But for the visual people, I want to be able to say, go back up. It sends it right up to the top of that page so they can see what's going on. And this right here just shows you the positioning that I can do. 

And there is a couple accordions up here. You can look here. And you can see this is how I call it. And these are the JavaScript functions that I used are examples. And for those really into the code, this is the class that I'm using. When I do a button click, I call this class. And it's pretty well commented, so you can figure it out. It's not that big of a-- not very hard to figure out. 

Next, modals. Modals and popups are pretty close to the same. A modal is basically going to be more of a form that you fill out or that you want to make sure is read. A popup is more a notification. I don't use popups because they're not-- you can't really style them. With a modal, I can do-- it's basically like a page that is thrown up into a window. 

And we have two different kinds of modals. We have the standard modal. It'll pop up. It puts an overlay the way I have it set up anyways. I can make this totally black if I wanted to or make it no overlay at all. It's the way it's styled. 

But when you hit-- when you call the modal, it shows up here. And the standard modal, if you click outside of it, it will go away. There's another one called a static modal. It looks the same, except when you click on the outside of it, it does not go away. 

So I use this type if I have, for instance, a form that I want somebody to fill out or they're working on a form and they need to add figure out some information or fill out some information prior to it. Then I'll have a form here. And then once they get that filled out, they'll submit it. And then I'll close it. 

The code in the back end on-- the code behind, it's basically a giant div. And it uses the aria-live="assertive". And so unlike the role, it's not going to say anything. So when I call this, the first thing is it gets focused on this. And it'll read the heading that's on there. 

And then if you tab through it, it'll read like there's a close button here. Then it'll read the content or the form that you have in there. Then it'll read like there's a Close button. And then it'll just keep looping around in here because this is the focus of the screen reader at the time. 

The actual modal itself is right here. I have that wrapped up in the div because that's the only way that you can make sure that it is announced when it pops up. And this is a basic Bootstrap modal. This is part of the whole framework. So that's another reason for using a framework, is you have all these components that you can use that have already been proven. People know they work. 

Bootstrap, one of the deals about it is that they make sure that everything is accessible and it's responsive. And I'll show you that later on about how they're responsive. So that's pretty much it with modals. Very easy to hook up. I thought I had it on here but I don't. I can show you. 

On this paging right here, this is the button handler that I would use. I would register this. And I would have a function down here that calls out to open up a modal. Bootstrap has a JavaScript file. And in that, you can define-- jumping all over the place here. 

I would use this ID. And so it knows that you'd attach modal to that. And when you use the JavaScript function, you just say show. And the JavaScript automatically knows how to pull that up, apply the styles. And you have a nice little modal. So it works pretty good. And again, it's accessible. 

Basic forms. Like I said, Bootstrap has the grid system. And that's how these are determined. I didn't do it here. I did it over here. You can see this form right here. This is probably about two columns wide. And this is probably about 10 columns wide. And that makes a difference because-- I'm jumping ahead. 

Sorry. Let me get back to where I was. Basic form. This is the basic Bootstrap form layout. You have basic labels and a basic input field. Any time you have an input field, you need to have a label. That label will have an attribute called for. 

And inside that attribute, you put the ID of your input. And what that does is it ties this label to this form. So when a screen reader comes back or comes on to this page, it'll read this. And it'll automatically know that this is attached to that. 

When you jump into it-- when you tab into it, it'll come to here. But it will read email address. If you notice down here, there's something down here too. And so when you tab into this one, it'll read email address. We'll never share your email with anyone else. And the reason it knows that is because I use another ARIA tag. It's called aria-describedby. 

So I have a little tag in here called small. And again, here's that semantic HTML. It's styled basically like a div that's been styled or span tag that's been styled. It has an ID of emailHelp. The class in here, it's the way that the text will look. And then it has the text. And you notice that it's smaller because that's what small does. 

But this aria-describedby is telling the screen reader that this is describing this. So when you tab into here, it'll read email address. We'll never share your email address with anyone else. So that's kind of nice. Same thing with password. It'll jump into here. It'll say password. Same with the checkbox. 

It's kind of nice for people that have some visual issues, especially if they're on like a tablet or a phone that they-- some of the checkboxes are really small. But they don't have to check the checkbox. All they have to do is check the wording for the checkbox. And it'll check and uncheck it because as you can see down here, we have a label. 

It's called exampleCheck1 in the for. Where's that? Yeah, right here. exampleCheck1. And here's the for on the label. So this label is now tied to this input field. 

What else? OK, buttons. Bootstrap has a button class. It's called btn. And you can give it different colors and such. Like for instance, these have like a btn button success. This is a button dash error. And this is a button dash warning. So there's different colors that you can use. 

Back to the form. Don't style links or span tags as buttons, unless you really have no choice on it. I understand that sometimes, especially on like-- I heard ctcLink they're using JavaScript links. And they're styling them as buttons. So that can cause problems. 

A lot of times you can take a button. And you can call a JavaScript method. So then you're using an actual button. And then you're calling the script instead of having a link styled as a button because the screen readers, well, they don't always read a link as a button properly. So when you're tabbing into it, sometimes your Enter button will not submit the button. 

So another one here is another part of the form. As you notice, you have different types of forms you can do. This one has the labels up on top. This one has the labels on the side. One of the things about Bootstrap and a lot of the frameworks is that they are what they call mobile first. 

And basically, mobile first means that anything that you have-- like we have a big screen here. So if I go ahead and drop this down into a mobile size, you see how this is that same one that was on the side? See, now it's stacked. And that happens because they're using-- this area right here is maybe two columns high or two columns wide. And this one's 10. 

So what happens, you have an ability in the Bootstrap framework to say, OK. First, I have to tell you about media queries. Media queries are basically as the screen is a certain size. As it gets smaller and bigger, those are called media queries. 

So you can have-- an extra small would be like a very narrow mobile. Small would be like some of the newer bigger mobiles. A medium would be maybe like a small tablet. A large could be an older screen, older or a flat screen or a laptop. And there's also extra large. And that could be some of the new wide screen monitors that we have. 

Inside there's these prebuilt media queries. So you can have-- for instance, when you're calling on Bootstrap, you call it out like column dash sm, which is small, dash, and how many columns you want to use. So for instance, on this one, it would probably be column dash probably large dash two. But you can also add column dash extra small, which is the excess, dash 12. 

So when the screen gets down to that media query of extra small, it'll suddenly take up 12 columns. So what happens if this takes 12 columns, these will start stacking up. So this will stack on top of that. That will stack on top of that. So you still have your nice form. But everything is starting to stack up when you get these smaller and smaller sites. 

And this is really helpful because a lot of the sites that we create, we look and note them on the screen. But a lot of people are using laptops. They're using tablets. And believe it or not, a lot of people are using some of our bigger sites with their phone. And because of that, because we're using a Bootstrap, these sites are actually usable still on a phone. 

And I think that's it. My email address is at the bottom of this, if you have any questions. And I'm going to stop sharing now, stop talking because I need something in my mouth.