Accessibility Matters: Creating a Better Web by Lindsey Dragun

Hi, thank you for coming. Uh I just want to let people know right off the bat this is an all-levels talk, so I'll be trying to cover Things that are good for people who may not have design or developer experience, and also cover a few things that are a bit higher level. Just a quick overview of what we'll be going through. I'll give my intro, I'll introduce the topic, and we'll talk about some broad ideas and Also, I'll be giving some specific examples that I find helpful. There will be a bit of code at the end to show how to identify an accessibility problem and solve it. And

expect lots of weird stock images and screen caps because I don't get a chance to use them much. This particular presentation will not include any animation. There will it should not rely on any slides and they're not really pretty, so you're not missing much. And there will be no cat pictures. Sorry I'm a dog person. And if you wish to follow along, you can find these slides at dragonwithu. tech slash DjangoCon dot html. And that address will also be at the end, so don't worry if you want to see them later.

A little bit about me. I'm a full-stack web developer at PBS where I often deal with accessibility issues on our projects and work closely with our product managers and design team to find solutions. I've also got your standard geek interest, like comic books and horror movies and whatnot. And I also happen to have made a career transition into tech. I have a very expensive MA in international peace and conflict resolution. And one of the main focuses of that is understanding what causes distress to people, even in cultures that don't resemble ones I'm familiar with, because resolving conflict often means finding what someone needs under what they say they want.

Which happens to be quite useful when applied to things like accessibility and user experience. So let's get into the basics. What is web accessibility? The Worldwide Web Consortium, also known as the W3C, is a community that develops web standards uh according to their web accessibility initiative, aka the people behind the Web Content Accessibility Guidelines, aka WICAG, it means that people with disabilities can perceive understand navigate and interact with the web as well as contribute to it. These can often be remembered through poor WCAG's acronym for guiding principles of their 2.

0 standards. What you put on your website must be perceivable, operable, understandable, and robust. WCAG is adopted by multiple countries as their standard for accessibility, including Australia, Japan. Japan, Germany, Canada, and is slowly being integrated into the United States government's accessibility standards under Section 508, or at least it was. What sort of disabilities do we generally mean when we talk about web accessibility? There are four main categories. Where some of the disabilities you're used to considering for web accessibility can fall, and there's also ones that aren't generally considered.

There's visual. So for example, blindness and colorblindness are very common considerations for web accessibility. But it can also include include conditions like glaucoma or cataracts, which also make it hard to view websites. There's auditory, and that can include Issues like deafness and auditory processing disorder, but it can also include issues like tinnitus, where if you require someone to listen closely to something on your website, that might interrupt it. Motor includes issues like cerebral palsy, Parkinson's, obviously even things like arthritis can affect how people can manipulate inputs.

Cognitive includes issues like autism or dyslexia , and a whole slew of other issues. And the language speech category is the last one. And that can include things like selective mutism or stuttering. And this is especially bad in recent years because of all of the reliance on tech that requires audio input from users. But beyond that, people also like to separate who we need to consider for web accessibility into other categories. To better understand these users. David Bernan, a Canadian accessibility expert, has taken those other categories

people use and created this particular list, which I think works well. There's permanent. Such as being born blind, episodic, which can be PTSD or something like a temporary illness like the flu. There's acquired, which could be aging-related And societal. For example, left-handedness, because there's a lot of assumptions in hardware in our user flows that users are right-handed. People who need web accessibility might also be using other alternative inputs and outputs, such as touch screens, eye tracking, and braille displays, and they may also be using screen readers. These are applications that read off the content of the page as they navigate through it, often

with the keys of their keyboard instead of a mouse or some other form of input. Screen readers may be used by the blind or visually impaired, which the National Federation for the Blind estimates is up to 10 million people just in the US But can also be used by others who have trouble reading or navigating pages. But defining people by categories or devices can Be deceptively simple, categories often give the impression that people can easily be placed in just one of them. In reality, people often fit in many of these categories. After all, someone who's deaf can become ill and certainly they still age. They could have cognitive or speech

or visual disabilities as well. And they could be using both alternative inputs and outputs and various types of each. While some people may define those as edge cases. That's dismissive of a very real problem that could come up with your design and development. As Eric Mayer and Sarah Wachterbetcher say in their book Design for Real Life, It's better to think of these situations as stress cases, the moments that put our design and content choices to the test in real life. So, what are some of the ways you can plan for these stress cases? Your code can follow standards, like WCAG, but realize that standards are generalized.

They're meant to give the best experience on average, not necessarily for your users, so you may have to consider options they don't discuss. From a design perspective, you can consider inclusive design, which is sometimes known as universal design or design for all. These are strategies that consider accessibility issues to ensure that designs work for people with a variety of needs and that everyone can get a similar amount of usage and enjoyment from what they're experiencing. You should of course consider user experience, whether you're a designer or not, because most actually good user experience also helps people with accessibility needs. You

should logically think through your cases. How would users approach what they need to do on your site in a variety of ways? What is your typical user flow, for example, and when might it fail? How can you make alternatives work? And just have compassion for your users. Understand that they might not be able to use the web the way you do, and accept that changes need to be made to assist them. Think about how you can assist people who aren't just like you. A little compassion. A little kindness can go a long way. But even with these basic steps, accessibility can still be hard to get right because it's not easy or simple. A lot of people, when they hear the term accessibility, think of accessibility in the physical world, like of a building.

And in many ways, there are similarities. Let's imagine some new modern building. It's done everything right. It's up to code and then some. They have wide, easy to navigate hallways. They've got automatic doors everywhere. There are ramps instead of stairs throughout the lobby. They've got wide, easy-to-find elevators, just about everything you could want. But when you approach this awesome building, parking in the large, very close handicap spot You realize there's no ramp. They have a high curb and no ramp in sight. They've done everything right.

inside, but have overlooked a detail that makes the entire building inaccessible from the very beginning. Someone say in a wheelchair would get along fine inside, but they'd have no way to get there Websites can be the same way. People will run all sorts of tests, do all sorts of sorts of audits on their code. Get 100% WCAG AAA scores, but they won't actually go through the entire process of using their product from the point of view of a user with accessibility needs Tools are not everything. Tests can miss issues. And they're often also generic.

That means they don't know how your particular user is using your particular site. Because the tools you use are not the same as a human being using them. And many of the other tools we use that aren't accessibility specific. aren't just not checking for accessibility, but they're actively optimizing accessibility away. The people working on them can decide that something like an ARIA tag that can communicates with screen readers is just excess code. And then you have to dig through their docs to find a roundabout way just to keep it included. So even if your code was accessible, maybe it's not after using certain products.

At my job, we spend a decent amount of time working with video. People come to our website looking for video. And making sure our users can actually get to and watch our content is very important to us. So every once in a while we'll do an audit of other sites with video. Not really our competitors because no one else is really vying for our Sweet 50 plus demo, but uh whatever major sites we can think of. And some of them are awesome YouTube, for example, is just a great experience. If you want to experience video while keyboard navigating, I'd suggest going there. But some are coded by people who are probably just checking boxes on a list on what makes a site accessible, or who didn't check to make sure the code stayed accessible in production.

When we went over to Amazon's site last year, for example, it would allow users to keyboard navigate to a video, although that was pretty difficult. And when you press play on that video, it would pop up as a modal. Those boxes that appear on a web page and block the content behind them. And they didn't pass focus to that modal. That means the user is still on the page behind the video going through the content there about purchasing it or terms and service and not actually getting to the video controls. The only way to stop it was either refreshing the page or navigating away. In fact, even today, and

well this is actually just yesterday, they've avoided implementing common and easy accessibility wins. You can't close their video-related models, such as an error message, easily with the keyboard, and such as with an escape key, which is a common feature. And it's like someone had gotten a ticket telling them to make it possible to play a video by keyboard navigation, and no one had actually considered anything beyond that. And the thing is, if helping your users isn't enough, good accessibility isn't even just for them. Though according to most surveys, 15 to 20% of many countries are disabled, so that's a ton of users.

But good code and is good code and accessibility makes you write markup that is good. Web crawlers, for example, such as the Google Search, benefit not only from all those SEO tags that you're shoving into your website. but also from well-structured content. And as devices such as Alexa and Echo become more popular, having websites that can work for programs that can't access information the way your average user would Is going to be very important. After all, they're not going to play your video or listen to your audio. They aren't going to notice objects that are hidden or require interaction. And you'll even notice that a lot of accessibility checkers are web crawlers.

So that can give you an idea of what they use. It also makes it easier for new developers to work with the code. Your headers make sense. Your nav and sidebars and main content are clearly labeled. You know that something that's a button performs an ad. And where a link goes, you're making less work for others. There are also legal repercussions for bad accessibility. In the last few years, there's been well-publicized cases of sites being sued for a lack of accessibility. For example The University of Berkeley got in trouble for edX videos that were notoriously inaccessible, lacking closed captioning and transcripts, having nothing to describe any of the figures or graphs.

And You may have heard recently of the Win Dixie case in June, when someone using JAWS found their site inaccessible and kicked off the first full trial by a federal court in the US on issues of web accessibility. In the US, government entities and those receiving money from them, as well as sources of education Must follow certain guidelines from the Americans with Disability Act or Section 508 or 504, with only a few exceptions for Things like nuclear warheads. Businesses like Wendixie fall under the ADA because of the public accommodation section, even in cases of third-party applications on their site.

So if you have to ask who is the accessibility for, know that it's for basically everyone. Users, web crawlers, developers, your company's lawyers, everyone. But what is good accessibility? And what are some easy wins that you can pull off on your site? Color and size are a great starting point. There are many tools to check contrast between a foreground and background color on your website, and many will tell you whether they meet certain standards for accessibility. The size and weight of your text also matters. The bigger of the better. The bolder of the better Having alternative text

on your images is very important. Putting alt tags into the image markup or other alternatives help people know what's in that space even if they can't see it. Also Don't include the word image in that alt text. Screen readers know it's an image. We'll inform users that it's an image and hearing image. Image of blah blah over and over again is not a good user experience. Never rely on just one way to inform someone of an error or alert. If you just use changing colors, people who can't tell the difference will miss it. So colors and symbols work well. A mix of words and symbols for an error is even better

because symbols don't always mean what you think they mean to all of your users. But also know that you'll have to update the ARIA attributes for that. ARIA are attributes you can add into the markup for screen readers to communicate with it. Putting an ARIA rule of alert Will let screen readers know that something there might change and would need to actually interrupt the browsing of the user. There are other similar areas where ARIA tags are very important and familiarizing with your them. Familiarizing yourself with them is a good way to find some easy wins for your website if you're not already using them. Especially when you're working with forms, where you can match labels with form fields, give longer descriptions.

and a whole lot of other uh very nice magic. Have in and with that also Make sure to have feedback on other things in many ways as possible. Don't just have visual or audio or haptic cues that convey information if that's what you're using. Try to have all three, for example. And try navigating your site with a keyboard. Not many people I know actually end up doing this and it can be very revealing. You may have to change some settings on your computer and you may have to learn a few keyboard commands, but it can be very helpful for learning the stress points for users. And

while you're doing that, remember that screen readers vary. They have different ways of conveying information. And you have to try a few different ones and check on multiple browsers while doing that. And realize that people that regularly use screen readers are not the same as someone that's just using them to test them every so often. It's like the equivalent of you playing flag football while they're in the NFL. But for some people, it's easier to consider what could go wrong and take it from there. So styling, very important. Don't just do something because it looks cool without considering how different users would perceive

Something is not good design if it's causing issues for your user. Infinite Scroll is something that designers seem to love. But putting content somewhere might need to access someone might need to access in the markup after the section with infinite scroll, such as a right-handed sidebar or a footer. can make it impossible for someone using a keyboard or other alternative input devices to access it. Lazy loading too can be bad for accessibility. A screen reader user could be interrupted every time something new appears. Or they could be alerted at or they could not be alerted at all and complete completely miss some of your content.

So try to push back a little bit on those. In and in the last year or so, I've noticed a lot of squiggly lines being favored in web design. And sometimes I'll run across websites where their underlines are uneven wavy lines. Those can make people lose concentration and cause certain visual issues. such as their brain making them think the line is moving and causing headaches or nausea, in my case particularly. And worse, I've seen lines like that that do move W on a few blog sites and others, I've seen zigzag line animation all over. I don't have attention to sh

attention issues and I find constantly moving lines to be huge hugely distracting. Imagine what that would be like for someone with issues. Autoplay, also very popular. Which is a bad idea for lots of reasons, of course, but also because it is rarely accessible. It can interrupt screen readers, making it harder for people dependent on them to use them It's also often an unwelcome surprise, which is bad for people with anxiety disorders, and a distraction, which is bad for people with attention disorders. If a person's audio is set to a high volume or the video has flashing or fast movements, it could also cause migraines, panic attacks, and possibly even seizures.

That's one of the reasons that people use ad blockers, they'll often prevent video and audio from autoplaying. But because so many sites get revenue from ads, people are pushing for blocking them. Oftentimes this involves a modal that pops up and tells the person to whitelist the site. And sometimes the modal is not accessible, making it even more of an annoyance for people with accessibility needs. So while ad blockers may be bad for business, trying to block those means you're actively losing business anyway. And I get it with the modals, right? I did the modals for our website

and they can be hard, but making them accessible is not impossible. Just spend a little more time. Along with that, animated images are also popular and also come with a load of issues. For example, making people click on animated objects to get further into the page or go to a specific. link because it's fun or having text move around can be bad for people with various disabilities. There's even a few major websites that like to use random gifts as the entire background for a page. I still have flashbacks to the horror that was Tumblr's login screen.

If you messed up the first time. The gifts were fast moving and brightly colored and you would keep going and going until you hurriedly typed in your login, which you had a higher chance of messing up because you're in a rush and the screen would come back with the same information and a different horrible gif each time They've toned that down a little, but some of their backgrounds are still gifts and are still badly chosen gifts at that. One recently is just like multicolored balls bouncing in pipes and moving way too fast and too distractingly for the screen. You may have heard the term user hostile before, the opposite of user-friendly

And that's what this has created: a user-hostile environment. Which brings us to a very serious question. Is your styling causing harm? If you're able-bodied and there are parts of your website that give you issues, you can be guaranteed they're worse for disabled users. Beyond that, consider the web standards. Consider what you see users complain about and what might cause difficulties for people who aren't using the site the way you are. And if you're not capable of that, that's the point where you have to bring in some experts. You can hire consultants to audit your site. There are plenty of those these days

But even if you're not hiring accessibility consultants, you could offer to hire users with disabilities as the web equivalent of sensitivity readers. Just to go through your site and tell you where they run into problems. After all, if you have a UX team, you're probably paying for basic testing anyway. People are willing to sit in cafes, handing out gift cards, just have people go through a few wireframes. You could do similar for usability for disabled people too. Because sometimes the experts actually get things wrong, right? Like with the new handicap symbol, they take a symbol that represents many and they update it with the best of intention.

But end up causing controversy because many see it as an ablist choice. The original handicap symbol could be many types of wheelchairs. The new one can only be a manual one Which serves to further isolate many of the people who can't perform such actions. And this could have been avoided if they just consulted some of the disabled people who focus on disability issues in their community. And while you're at it, remember that all of your content is important. It's not just about images and markup. Your written content can harm your users as well. I went to a site recently looking for ergonomic keyboards.

I'm reading the content, it's looking fine. And then I get to a point where it's talking about usage and it says, no sane application. No scene application. We all know what they mean. What they probably just held off from saying. And everyone reading that with a mental health issue or who cares about them knows the person writing it didn't care if they were being insulting. No well-made application, no logical application, no good application. On a professional site You should not be insulting your users.

You should not be hurting your users in any way because you're going to lose some of those users. The people who don't care won't even notice if the words are there or not. But the people who do care will. Because what is accessible for some does not equal accessibility for all. Some people don't care what you call another group, some people do. If you do have an accessibility need and go, well, I'm not upset by X, that doesn't mean other people aren't. And it's the same for anything. For your styling, bold colors with high contrast are great for users with vision issues.

But if they're bright or if there are too many, they could be bad for users with attention issues. Infographics are great for people with attention issues or reading issues, but are very hard on someone with vision issues. We have so much control over how our websites look and feel and their content these days. And there's no reason to leave anyone behind with it. And if you're advocating for accessibility, But no one at work cares, sometimes that means you do have to find a middle ground. You might have people saying that styling doesn't fit For example, you might have stakeholders

insist that a page has something or doesn't have something, or designers who have very inaccessible designs they don't want to change. Or developers who say that making something accessible will take too long or is too hard. So you might not have be able to have perfect accessibility. But you can push for more. You can make things as accessible as possible. Because that's better than nothing, which is sadly what a lot of sites have. Here's one really easy one. Focus state is an outline that appears around an element on the page indicating that's where someone's navigation is placed. It allows someone who is

sighted but relying on their keyboard for navigation instead of a mouse to know where the equivalent of their mouse pointer is It normally appears as a gray or blue outline, depending on the browser and styling. It is also very easy. Easy to remove. It's just one line of CSS. And some designers really like removing it. But brow while browsers have defaults for a reason because people are used to them and they generally work. If you need to change the colors or the look slightly just to keep it. That's still better than not having it.

So in the end, while your accessibility will probably not be perfect. And even if you try very, very hard, you'll probably miss something. At least you will have something. Be ready for mistakes and missteps. Be gracious if it's pointed out. And don't be discouraged. Everyone goes through this. And don't and definitely don't think that just because it won't be great accessibility, you shouldn't bother. And now the weather, or a real life related example. At work, we switched from an icon font to SVGs for icons. As you may or may not know, SVGs are considered very accessible.

This we thought was an easy win. But one of the reasons they're accessible is that you can put accessibility information inside the actual SVG. And work on the image's code. They can have titles, description, and other content right there. And you can also put the ARIA labels that point to them in case the browser doesn't support that. But that's if you include the SVG in your markup. And in many cases, you want both reusable SVGs meaning separate files that you can include in various pages and SVGs that are placed in an image directory to keep things organized. This makes inlining SVGs, including their code as is in the code of the document, a little more difficult.

And if you put an SVG into HTML image tags, the way you would any other image. It loses a lot of its accessibility. We decided to go about solving this by making a function that takes the path of our SVG icons and inserts them into a template from our static directory. where we kept images. In our templates, all we need to do is use that function to call a particular SVG. And now it's in the HTML, the page, as an actual SVG. So we have the SVG with its ARIA labeled by property. Pointing to the title, which also still exists, so screen readers can access it. Instead of compromising on what we wanted

or on what we could do We took a little extra time to think about the problem and the steps necessary to resolve it. I said we'd only do a little bit of code, and there it is. But if anyone wants to discuss details about accessibility, feel free to catch me hanging out out around the conf. I'll be practically anywhere. Before we wrap up, I also want to go through a few great tools for testing accessibility quickly on your own. You can find these and others linked in my website. The URL will be on the next slide. The Chrome Accessibility Developer Tool. Is a browser extension that you can use with Chrome DevTools.

And it gives you accessibility errors and warnings, as well as tells you stuff like the color contrast rates under WCAG 2. 0. No coffee is another great extension for Chrome. It allows you to experience the way people with different visual impairments see a web page, which can be anything from cloudy vision to colorblindness to Things like floaters that can interrupt their view. Achecker is a website you can give a URL or copy and paste code into to have it check your accessibility. The Wave Evaluation tool is an extension for Chrome and I think other browsers that will do that in browser.

And finally, JAWS screen reader is the still the most popular screen reader in use. It's for Windows. And you can download a free version of it for testing. It only runs for a certain amount of time before you technically have to restart your computer. So if you can get a Windows virtual environment running, all you have to do is just restart that over and over again. It's a pro tip. And finally, here's my contact information. You can find the link to resources and slides from my website, which is Dragon with a U. Dot tech and uh the non-stock image sources are after this in the slide deck

for anyone who for some reason wanted those. And if you have any questions for me, I'll be in the hallway after this, or you can email me at lmdragon at gmail. com. That's Ella's and Lindsay, Emma's and Michelle, and then my last name. And just want to say thank you all for coming, and I hope you have a great conference. And yeah, I finished early. Have fun with your break.