We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Accessibility Matters: Creating a Better Web

00:00

Formal Metadata

Title
Accessibility Matters: Creating a Better Web
Title of Series
Part Number
10
Number of Parts
48
Author
Contributors
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Overview This talk will go through accessibility concerns on the web through example sites and code with both good and bad accessibility to experience what some users have to struggle with daily. We will cover well-known concerns such as low vision/color blindness and deafness, as well as attention issues and autism, and discuss the limitations and abilities of various alternative input devices that people with motor control issues rely on. Short and long-term fixes will be demonstrated and taught, with the overall goal being that the participants leave knowing how to find and solve accessibility problems. Why Bother With Accessibility Not only should you want everyone to be able to easily use your site, but having an accessible website comes with a variety of benefits. According to the U.S. Census Bureau, around 19% of Americans have a disability, which is a large potential audience for any site. Many companies also fall under accessibility laws they might not even be aware cover their products, with lawsuits becoming more prevalent in recent years, and showing a good faith effort to improve your products’ accessibility can help keep your company out of hot water. Accessible web development also tends to lead to better UX and a happier user base. And, another plus: It will save devs time and frustration when they’re working with the code, since good HTML is enforced. Who This Talk Is For Anyone who wishes to learn more about accessibility. While we won’t be going over the absolute basics of accessibility in detail, the examples and resources will be easy to understand for people with very basic knowledge of web development.
Drag (physics)Level (video gaming)Presentation of a groupMedical imagingBitPower (physics)Type theorySoftware developerExpected valueCodeTouchscreenSpherical capComputer animation
File formatCodeComputer-generated imageryTouchscreenSlide ruleComputer-assisted translationAddress spaceCoefficient of determinationComputer animation
Slide ruleGoogolSoftware developerRevision controlCodeVideoconferencingGame theoryBootingImage resolutionGroup actionProjective plane1 (number)BitAddress spaceCausalityStandard deviationData managementArithmetic meanRevision controlImage resolutionProduct (business)Web 2.0Web-DesignerWorld Wide Web ConsortiumComputer animation
Content (media)Web 2.0Standard deviationSheaf (mathematics)Condition number1 (number)WebsiteCategory of beingGraph coloringInclusion mapQuicksortComputer animation
Category of beingFormal languageSpeech synthesisProcess (computing)Entropie <Informationstheorie>PermanentFunction (mathematics)Touch typingElectronic visual displayPattern recognitionWeb pageContent (media)outputAbelian categoryMoment (mathematics)Axiom of choicePersonal digital assistantStress (mechanics)WebsiteInclusion mapProcess (computing)Entropie <Informationstheorie>Category of beingWeb pageoutputSpeech synthesisCartesian coordinate systemExterior algebraCognitionWeb 2.0CASE <Informatik>Key (cryptography)Stress (mechanics)Content (media)Moment (mathematics)Form (programming)CodeExpert systemSelectivity (electronic)Axiom of choiceVisualization (computer graphics)EstimatorStandard deviationSoftware developerType theoryReal numberSoftware testingElectronic mailing listTouch typingComputer configurationFormal languageVideo gameTouchscreenPerspective (visual)TrailComputer hardwareUniverse (mathematics)Electronic visual displayStrategy gameKeyboard shortcutSurgeryStaff (military)Instance (computer science)AverageClosed setComputer animation
Personal digital assistantStress (mechanics)Source codeStandard deviationLogicRight angleVariety (linguistics)Term (mathematics)DataflowMathematicsSimilarity (geometry)Level (video gaming)Compass (drafting)BuildingExterior algebraCASE <Informatik>Goodness of fitCodeWebsiteWeb 2.0Computer animation
Closed setBuildingWebsiteCurveComputer animation
Software testingGeneric programmingProduct (business)Mathematical optimizationWebsiteCodeInternetworkingElement (mathematics)Keyboard shortcutWebsiteQuicksortProcess (computing)Product (business)Content (media)Multiplication signView (database)VideoconferencingEscape characterTelecommunicationWeb pageTask (computing)Key (cryptography)CuboidHypermediaError messagePoint (geometry)CodeService (economics)Keyboard shortcutTerm (mathematics)Electronic mailing listFocus (optics)YouTubeTouchscreenDemo (music)Latent heatSoftware testingVideo cardXMLComputer animation
VideoconferencingTerm (mathematics)Error messageService (economics)AreaRight angleGoodness of fitMachine codeWeb crawlerArchaeological field surveyMarkup languageCodeComputer animation
CodeSubject indexingWeb pageSoftware protection dongleWebsiteInformationContent (media)Computer programmingObject (grammar)Group actionExecution unitWeb crawlerSoftware developerState of matterLink (knot theory)EmailInteractive televisionCASE <Informatik>CodeRandom matrixNavigationVideoconferencingComputer animation
Sheaf (mathematics)Standard deviationWeb crawlerGraph (mathematics)Figurate numberCASE <Informatik>VideoconferencingProcess (computing)Closed setException handlingSoftware developerCartesian coordinate systemSheaf (mathematics)Contrast (vision)Web crawlerGraph coloringWebsitePoint (geometry)Source codeStandard deviationWeb 2.0Medical imagingWeightNuclear spaceSource codeComputer animation
WeightContrast (vision)PasswordAttribute grammarMereologyOnline helpField (computer science)WritingElement (mathematics)FeedbackSpacetimeMedical imagingExterior algebraMarkup languageTouchscreenWordMultiplicationDifferent (Kate Ryan album)Form (programming)Musical ensembleSet (mathematics)Mixed realityPoint (geometry)NeuroinformatikInformationAreaVapor barrierSymbol tableGraph coloringError messageMatching (graph theory)Goodness of fitWebsiteKeyboard shortcutKey (cryptography)Field (computer science)Descriptive statisticsStress (mechanics)Web browserFeedback1 (number)Rule of inferenceAttribute grammarComputer animation
TouchscreenWeb browserWeb browserFlagEquivalence relationTouchscreenGoodness of fitInfinityComputer animation
Axiom of choiceSheaf (mathematics)Exterior algebraKeyboard shortcutInfinityoutputMarkup languageTouchscreenMultiplication signBitWebsiteContent (media)Line (geometry)WebdesignComputer animation
Interrupt <Informatik>TouchscreenLine (geometry)ConcentricInsertion lossCASE <Informatik>Visualization (computer graphics)WebsiteCausalityOrder (biology)Entropie <Informationstheorie>Volume (thermodynamics)Interrupt <Informatik>TouchscreenVideoconferencingModal logicAutomatic differentiationBlogEndliche ModelltheorieInformationComputer animation
Dean numberWebsiteEndliche ModelltheorieArithmetic meanWebsiteModal logicWeb pageMedical imagingLink (knot theory)Latent heatObject (grammar)Structural loadLoginComputer animation
Different (Kate Ryan album)TouchscreenWordMultiplication signLoginInformationComputer animation
Term (mathematics)Integrated development environmentUsabilityTouchscreenComputer animation
Standard deviationWebsiteCausalityMereologyWeb 2.0Information technology consultingPoint (geometry)Expert systemComputer animation
Equivalence relationInformation technology consultingExpert systemSensitivity analysisPlastikkarteWebsiteSoftware testingFrame problemWeb 2.0Computer animation
Local GroupExpert systemType theorySymbol tableAxiom of choiceLine (geometry)Information technology consultingRight angleGroup actionContent (media)UsabilityCartesian coordinate systemMedical imagingWebsitePoint (geometry)Markup languageComputer animation
Content (media)Cartesian coordinate systemArithmetic meanReading (process)Computer animation
Dean numberGroup actionGraph coloringWordMachine visionContrast (vision)Computer animation
Axiom of choiceWordFreewareWebsiteMachine visionGame controllerContent (media)Web pageFitness functionComputer animation
Arithmetic meanMachine visionCodeSoftware developerSoftware developerWeb pageWebsiteFocus (optics)Element (mathematics)Keyboard shortcutLine (geometry)Equivalence relationComputer fontState of matterComputer animation
Perfect groupDefault (computer science)Web browserFocus (optics)Computer fontPointer (computer programming)Computer fontWeb browserDegree (graph theory)Equivalence relationLine (geometry)Default (computer science)Graph coloringEvent horizonVotingComputer animation
Computer iconDescriptive statisticsInformationCodeRight angleContent (media)Computer fontVideo gameMereologyBit rateMedical imagingACIDKeyboard shortcut
CodeComputer-generated imageryRight angleDirectory serviceTemplate (C++)Fluid staticsFile formatComputer iconException handlingOpen setReading (process)Directory serviceTemplate (C++)Medical imagingInclusion mapCodeWeb pageFunctional (mathematics)Schweizerische Physikalische GesellschaftTouchscreenGraph coloringMultiplication signInsertion lossComputer iconCategory of beingBitComputer fileCASE <Informatik>FamilyWeb browserMarkup languageComputer animation
Slide ruleSoftware testingSoftware developerGraphical user interfaceError messageWeb browserBit rateContrast (vision)Extension (kinesiology)Computer animation
Software developerGraphical user interfaceExtension (kinesiology)WebsitePerformance appraisalWaveTouchscreenSource codeComa BerenicesWebsiteTouchscreenRight angleExtension (kinesiology)Revision controlWindowView (database)Web pageInformationGraphical user interfaceVisualization (computer graphics)Medical imagingGraph coloringDifferent (Kate Ryan album)Machine visionQuery languageVirtual realityPerformance appraisalSlide ruleLink (knot theory)Uniform resource locatorControl flowCodeMultiplication signWeb browserSoftware testingComputer animation
Coma BerenicesXML
Transcript: English(auto-generated)
I just want to let people know right off the bat this isn't 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. 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 dragon.tech.jangocon.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 interests 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 World Wide Web Consortium also known as W3C is a community that develops web standards according to their Web Accessibility Initiative aka the people
behind the Web Content Accessibility Guidelines aka WCAG. 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
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, 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 color blindness are very common considerations for web accessibility but it can also 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 nudism or stuttering and this is especially bad in recent years because of all of their
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 Burnham, 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 a 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 audits on their code, get 100% WCAG, AAA, score
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 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 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.
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 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 webpage 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 modals 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 coding 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's something that's a button performed in action 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 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 Winn-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 Winn-Dixie 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 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 the better, the bolder the better. Having
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 in 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 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 very nice magic. 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 it. Something is not good design if it's causing issues for your user. Infinite scrolling to love. But putting content somewhere might need to, 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 completely miss some of your content. So try to push back a little bit on those. And in the last year or so I've noticed
a lot of squiggly lines being favored in web design and sometimes they'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. On a few blog sites and others I've seen zigzag line animation all over. I don't have attention issues and I find constantly moving lines
to be 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's 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 GIFs 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 GIFs were fast moving and brightly colored and you would keep going and going until you hardly 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 GIFs and are still badly chosen GIFs 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 a guarantee 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 GIF cards, just have people go through a few wire frames. You could do similar for usability for disabled people too because sometimes the experts actually get things wrong, right? Like with
the new handicapped symbol, they take a symbol that represents many and they update it with the best of intentions but end up causing controversy because many see it as an ableist choice. The original handicapped 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
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 sane 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 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 say 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 to remove. It's just one line of CSS and some designers really like removing it but 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 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 as 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 of 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 around the comps. 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. NoCoffee is another great extension for Chrome. It allows you to experience the way people with different visual impairments see a webpage which can be anything from cloudy vision to color blindness 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 still the most popular screen reader in use. It's for Windows and it's a great tool 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 a link to resources and slides from my website which is dragonwithau.tech and 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.