Demystifying Web Accessibility for Developers

00:06 Have you ever tried to navigate a website one handed while holding a cup of coffee? Or squinted at your phone screen in the bright sunlight? Or attempted to tap a tiny button while on a bumpy bus ride?

00:18 These everyday struggles mirror challenges that millions of people with disabilities face constantly, except they can't simply put down the coffee, step into the shade, or wait until the bus stops. What's occasionally frustrating for some people can be a complete barrier for others, and that's why web accessibility matters for everyone.

00:37 Web accessibility isn't just a checkbox for compliance or a nice to have feature. It's about ensuring that everyone, regardless of ability, can navigate, understand, and interact with the digital world wield. And yet, despite its importance, accessibility remains one of the most overlooked aspects of web development. Today, we're gonna change that and talk about web accessibility.

01:00 We're gonna demystify it, from the perspective of developers. One thing that I think we've done really, really well in the past few years is letting folks know that images need alt text. There's a little bit more to accessibility than that, though.

01:14 That's something that a lot of people think about because there are linters that are set up now by default and reminders on web pages. It's a great starting point, but there are a few other things that if you just add those, you can make the web just a little more accessible. So that's what we're gonna talk about.

01:30 But first hi. I'm Britney Elek. I am a senior all end engineer at GitHub. I've previously worked on the GitHub actions team, and now I'm on the billing team. I've also worked at a few other places like at Hippo Education, Nike, and Aleida. And I would love Internet friends.

01:50 I am a remote employee, and so all of the people that I meet are on the Internet. So if you would like to connect on any of these sites, I would love to connect with you. So why am I excited about accessibility? I personally think that it's easy to get behind.

02:06 I think that I, as a software engineer, I am a steward of the Internet, and that means that if I want to make sure that everybody can access information equally, then that means that the Internet has to be accessible. Little disclaimer here, though. I am not an expert. I'm not an accessibility specific focused engineer.

02:27 These are my own thoughts and opinions and things that I've learned over several years and do not necessarily reflect the opinions of my employer. GitHub does care a lot about accessibility, though, and I included a link to our own accessibility policy here if you're interested. I will share these slides with the video.

02:45 An outline of what we're gonna go over today. So first, we'll go through our objectives. We'll talk about understanding what web accessibility is to. We'll review a few common barriers and how different users might experience the web in different ways.

02:58 We will talk about techniques developers to improve accessibility to get started, and we'll talk about testing for accessibility. And then I'll provide a a quick resource for all of the links in this presentation at the end. So objectives. First, I want to provide just a high level overview of what web accessibility is.

03:17 There are a lot of people out there that are probably more qualified and more detailed than I am, but I wanna give you the basics so that you know what we're about. And second, I'm gonna give you the tools to start at making the web a more accessible place.

03:27 It's not going to be 100% comprehensive because that would be a very tall ask in a twenty five minute video. But if you follow some of these recommendations, I guarantee your website will be a little bit more accessible than it is now. So first, let's talk about web accessibility and what it is. What is it?

03:46 There's a lot of different definitions out there, and I picked several of them that I think are all important to know. So the first one, just high level definition.

03:53 It's inclusive practice of ensuring that there are no barriers that prevent interaction with or access to websites online by people with physical disabilities, situational disabilities, and socioeconomic restrictions on bandwidth and speed. Think when it comes to accessibility, a lot of folks just immediately think about disabilities, physical disabilities, but thinking about things like situational disabilities is also important.

04:14 For example, what if you broke your arm and could only use one arm? Or if you're holding a baby and could only arm, or if you're distracted and driving and can't read at the same time, but you need to get some information.

04:27 These are all considered situational disabilities and are all still important times when folks might need to access the web. So socioeconomic restrictions on bandwidth and speed. This is highly relevant for anybody who is in a in a very JavaScript heavy ecosystem. JavaScript bundles are hard to load, when you have restrictions on your bandwidth and speed.

04:48 So making sure that your website still works even when you don't have great connection is considered accessibility.

04:56 There is a fantastic essay by Anne Gibson that I am linking just the top level of here, called the alphabet of accessibility issues, and it provides a lot of really great examples that I think a lot of folks don't necessarily think about when they think about traditional accessibility needs.

05:11 For example, having a somebody who is blind or somebody who fell down a hill while running to close their car windows and fractured some fingers, somebody who is on chemo, somebody who is colorblind.

05:24 There's a lot of different ways that we need to build for accessibility and a lot of different things to think about at the end, just the ones that most people do think about. Another one that you might commonly see is this a 11 y acronym.

05:38 This is the 11 stands for the 11 letters in between the a and the y. It is pronounced a 11 y, not ally. That is a different thing.

05:49 Another example of accessibility, just the absence of barriers to information. I like this one. It's short and sweet. Accessibility is also just good design. When you make your website more accessible, you're making it more usable for every user, not just folks with disabilities.

06:05 So why is learning about accessibility important? Lots of different reasons. For the first one, like I said, making your website available to everyone. That's enough for me to learn about accessibility, but you may have some other reasons too, like expanding your app's potential audience.

06:19 I guarantee if you go tell your project product manager that you can increase your traffic by 25% just by this one easy trick, they will be bought in. Easy. It's can also begin to learn to be more competitive in the job market if you do a lot of front end work and can say, hey.

06:35 I also know about accessibility. That is a great tool in your toolbox to try to sell yourself in this crazy job market. You might have some legal obligations. I'm not a lawyer, so I'm not gonna talk about those, but they might exist. And there's also just the moral and ethical reasons to do so.

06:52 Access to information is required for equal access to society. A lot of information is only on the Internet, and if you are a steward of a website on the Internet, then you should make sure that that website is accessible to everybody. So let's talk about the impact.

07:08 There's an estimated one point three billion people globally that have disabilities, fifteen to twenty five percent of people. Seventy five percent of Americans with disabilities use the Internet daily. Over ninety six percent of the top million web pages in 2023 had accessibility issues. That's like most of them. The it is very common to have inaccessible websites.

07:31 Not that there's a good excuse for that, but it's very common. And if you learn just a little bit about it, I guarantee you'll be making the world a more accessible place. There's also over 4,060 web accessibility cases in US courts just in 2022. So this is something that people are suing over.

07:51 And so if you have legal obligations, then you probably wanna think about those. The key principles. So a lot of the guidelines recommend following content accessibility guidelines 2.2 is the most recent version. These are the recommendations for making the web a more accessible place. They are divided into four different sections.

08:13 So there's the perceivable, making content accessible to all senses, operable, making sure it's navigable and usable, understandable, so having a clear and intuitive design, and robust, making sure it's compatible and future proofed from future changes. Accessibility standards are always evolving. No one really has this all figured out.

08:34 It's a thing that you we have to learn about like any other skill as a software engineer. Once you're accessible, it doesn't necessarily mean that your website's gonna be accessible forever. There might be something that comes up that people learn that we also need to include, and that is part of the fun of being a software engineer.

08:51 So let's talk about a few barriers that are really common, and different ways that different users might experience the web. So I think one of the ones that a lot of people think about when it comes to accessibility is low vision users. They might be using a screen reader or a braille reader.

09:05 Some folks might also be using a high contrast mode to, better differentiate between different colors. Zoom and screen magnification. So, you know, making sure that you can zoom in and make your text really big and it's still readable is important.

09:20 There are a variety of different motor and mobility impairments that might result in different ways of using the web. For example, using only a keyboard for navigation, using only a mouse for navigation. There's different switches, mouth sticks, eye tracking software, and voice dictation software, which are all used throughout the web to access websites.

09:40 There's also a few different common things for cognitive and neurological disabilities.

09:44 For example, making sure you are using a predictable page structure and design, making sure that your website is consistent and it's consistent with other websites that folks would think to use, Thinking about the reading level of the content on your website is important to make sure that it is understandable to your target audience, including supplemental diagrams and images where they make sense, and reducing animation motion.

10:10 This is one that I personally really like. I love a GIF, and I also love pausing that GIF and not being distracted by it when I'm on a website. Hearing impairments, some things to think about, captions, using sign language, if you have the resources to do that, and transcripts for audio and video. Alright.

10:33 High level techniques first to improve accessibility. So how do you do it? One great starting place is to have an internal and external policy on accessibility. This is a guiding North Star for your organization that says, this is what we're working towards. And that's a great way to get everybody on the same page.

10:49 If If you're doing a redesign, make sure you involve accessibility early in the design process so it's not something you have to fit in and make a bunch of changes changes for in the end. If you're doing ongoing work, I like to fit this along existing bug fixes and updates that I'm making.

11:02 There's some really great accessibility linting and testing tools that I'll talk about a little bit later. Design systems are a great way to do it. For example, if you use a design system and there is a label on every input element, you don't have to think about adding a label to every input element in the future.

11:19 You can just use the design system. Design systems are awesome. Design for all devices, so make sure that you test your website on multiple different devices, and it looks good on all of them. I'm also including a link here to the accessibility champions blog at GitHub.

11:34 I highly recommend checking it out if you're interested in how to do accessibility at a larger company. This is how we did it, and I'm part of the accessibility champions program at GitHub, and it is awesome. A good place another good point is using semantic HTML.

11:47 This basically just means using HTML tags like they're meant to be used. I think a lot of folks, when they think about accessibility, think about using ARIA tags. And one of the good things to keep in mind about ARIA is it's sort of like the web development fight club.

12:03 The first rule about ARIA is to not use ARIA. They, it's really made to handle things that are not accessible from the beginning and to make them accessible. And it requires thinking about a lot of different things that you don't necessarily have to think about if you just use semantic HTML from the beginning.

12:21 For example, roles and focus, themes, and the different levels of interactivity, these are all things that can be avoided by using semantic HTML. When you load a web page, an accessibility tree is built that can be used by assistive technologies, state information to the user, and that these all work with semantic HTML from the beginning.

12:40 So here's an example of using semantic HTML versus some combination of divs and event listeners to achieve the same exact thing. So if you use a button, a semantic HTML button, everything is built in from the beginning.

12:55 You don't have to think about things like focus and roles and making sure it's accessible to a keyboard and all of that. But you do if you have to if you're taking a div and styling it like a button. It's a lot more to think about here than there is here.

13:09 This is also more readable, better for everybody. High level overview of what, is included from semantic HTML. So just high level. There's a doc type on each page. HTML tag there should be an HTML tag with the language for the page set, so e n for English.

13:27 Making sure that the head has a meta char set that that is used throughout the page is important.

13:33 There should also be a page title, and it should be unique to other pages on the website, and it should be descriptive of what's on the page contents because a lot of screen readers will use the page title to let folks know what the page is about. Landmarks.

13:47 These are, HTML landmarks that are important to keep in mind. So the headers, navs, main, footer, and aside are the main ones. These are used by screen readers and by keyboard navigation to jump around on pages, so it's important to use them the way that they are made to be used.

14:02 So, for example, there should always be a main landmark on the page so that folks know where the main content is. Speaking of navs, navigation is super boring to listen to. It's usually at the top of every single page.

14:14 And if you read a pay top to bottom, you almost always have to go through all of the navigation links, every single time you load a page. So, let users skip it. Once they go through it once, they probably don't need it again until they actually need it. Headings. This is a big one.

14:29 I feel like, a a lot of, like, intro HTML use headings to style different elements on the page, and that is not what they are for, actually. These are there is a semantic HTML use for headings. So there's an h one through h six.

14:44 There should only be one h one on the page, which should match the page title. The headings are a way that screen reader users can skim across a page, so the order actually does matter. They should be in descending order.

14:55 So one, two, three, shouldn't skip around, and you should not be using specific heading levels for different styling. That is what CSS is for. So make sure that everything is in a logical order when you're just looking at headings on the page because a lot of folks will be navigating your page just from the headings.

15:11 Buttons and links. So there is a difference. Buttons are for actions on that you're set you're staying on the page, whereas a link is for navigation or changing the context of the page. There's a few other things to keep in mind when there's a link that goes to another page.

15:24 So making sure that it has enough text to understand what it's for. The text in the link is very important. So if you just have something that says read more, that doesn't really convey what it's about. You could say read more about accessibility, then folks know what that link is about.

15:40 You can use the accessibility properties in Chrome dev tools or whatever your favorite dev tools are, which will show the accessible name for each link, and show what we read out on a screen reader, which is awesome. Navigation links should always be in the same order on a page so that it is, understandable to all users.

16:00 And then any link without text should have an accessible name associated with it. Like, for example, if you have a search icon, it should have a name associated with it for folks that don't know that it is a search icon. This is also important for SEO purposes.

16:16 Images, like I said, this is the big one that I think a lot of folks are aware of because there has been a lot of evangelizing all seeing alt text, which is awesome. In general, you should avoid using text and images and use an alt tag if it's needed. It probably is.

16:31 The alt attribute should be descriptive of what the image is trying to describe. You don't necessarily need to say this is an image of because that gets pretty redundant with the fact that it is an image and folks expect that to be an image of something.

16:45 There is another dev tool that is useful to see what the alt text is read out as, which is awesome. If you have a caption and alt text, you don't need to duplicate these. And, in fact, you probably shouldn't because they will both be read by a screen reader.

16:58 And then one recommendation that I read online and I just loved is that if the image is there just for vibes, you should describe the vibes. Even if it's there just to, like, set the mood, like, you know, cozy fireplace, just describe, hey.

17:15 I wanna make this a little bit more cozy, and this is an image of a cozy fireplace without saying an image of. Oh. Graphs and diagrams should have a description of the content and what they are trying to convey.

17:27 So if you just read out all of the data points on a graph, that is going to be very hard to understand. If you have a graph that or a diagram that you're trying to describe something as, put in the alt text what you're trying to describe.

17:43 Lists. So if there's an ordered list or an unordered list, you should use the one as appropriate. And another recommendation I've seen is if there's any more than three items grouped together, then it should probably be a list.

17:58 Tables are used for tabular data, and this is another one that can get wrong very easily because of all of the different things that are included. So there are heading tags and then scopes to indicate whether, the heading is associated with a column or with a row.

18:11 The also always be a summary that describes what data is included in the table so that folks don't have to navigate through the table and try to figure out what it is before they're able to figure out what is in the table. Forms are another thing that has a lot of pitfalls.

18:28 Using types on the inputs, for example, like an email type or a password type is one of those things that, like I said, is good for all users, not just users that, might abilities. Every single input and field should have a label on it to indicate what it's for.

18:44 You should always let folks know which elements are required or, which ones are disabled. And then also another really big helping helpful tip is to be as explicit as possible about errors.

18:58 I've seen a pattern recently where websites will have, like, a create password field, but they won't necessarily say that there are requirements to that create password field. And it's not fun to guess what the error is when especially when you can't even see the text that is being, created. So, make sure that errors are explicit as possible.

19:19 That's going to be useful for basically anybody that uses your website. Text using REMS or some other responsive way to style your text allows for better changes in text size if folks need to zoom in or zoom out, which is great. Text copy, trying to keep it understandable.

19:37 If you think about the reading level that it's at, this website is really great, hemingwayapp.com. You can copy in your page text, and it will tell you what the reading level is, which is really helpful for trying to understand who whether or not you are targeting the right late reading level for your audience.

19:54 Avoiding technical jargon and acronyms, especially if most people might not be able to understand what those are referring to, is great. Alright. Let's talk about accessibility testing. So high level, there's automated testing that does exist that I think a lot of folks might be familiar with, and it's a great first step.

20:12 But it's only gonna catch about thirty percent of accessibility issues. We'll go into a couple of different ways that you can use automated testing, and I think it's fantastic. If you're doing nothing else, this is a great starting point. But a little bit later from now, we'll go into manual testing, which I think is also important.

20:28 So HTML validation, this is a really great way to catch some low hanging fruit about the semantic HTML that you're using on your website. This validatorw3.org, I've used in the past, and it's fantastic. You just copy in a link, and it'll tell you, you know, high level issues that you might have with a website.

20:48 Web accessibility evaluation tool by WebAIM is another one. This is a Chrome extension. It has some really great tools that I commonly use, like the contrast checker and some other WCAG tools that are built in. Axe by DQ is another Chrome extension that I've used in the past.

21:03 Adds an Axe tab to your dev tools, and there's just a lot of really fantastic tools built in. Another one that I really like, so this ES Lint plugin, is fantastic just to catch things as you're building. If you can fix something before you even push it to production, even better.

21:19 There's also a an axe core library to write accessibility specific tests against, which is pretty cool and very helpful. The real though is in the manual testing.

21:30 I think that the manual testing can be a little bit intimidating at first, but I highly recommend everybody dives in and tries to use a screen reader or try to only navigate with a keyboard to really find whether your website is accessible.

21:41 So to start with, pretty much every operating system has a different screen reader that is built in by default. So Mac is what I use, and it has voice over built in, and I've used it quite a bit. It's great. These are designed to read all the text that's visible on a page.

21:56 Some tags that a sighted user might not be able to see, like ARIA tags, lists all the headers and all the different links.

22:02 This link to the DQ screen reader shortcuts is fantastic to bookmark because it has a lot of different test a lot of different information on how to use a screen reader if it's not something that you're familiar with. So what are you gonna test?

22:18 You wanna make sure that everything is read, that every visual element on the page, all of the images are read out. If the state or the content changes at any point when you're on the page, without the user doing anything, you wanna communicate that to the user.

22:32 You wanna make sure that everything on the page can be navigated to and that your page has a logical flow from top to bottom. When you get there and navigate it just with a screen reader, it doesn't actually make sense to somebody. Keyboard navigation, what to test?

22:45 The tab key here is your best friend, like all the Vibe coders out there. Make sure that you can navigate to each feature usually with the tab key. Make sure you know where the focus is at any given point. If you ever lose it, this is a great tip.

22:58 If you type in the JavaScript console document dot active element, that will show you where the current focus is if you cannot find it. Make sure you don't get trapped anywhere, like, if you're in a radio button or checkbox.

23:08 Usually, you tab into those and hit enter and then navigate up and down, but you should be able to shift tab back out to get out of them. So make sure that the keyboard interaction makes sense.

23:18 There's some standard interaction that you should be aware of for different elements, and you wanna make sure that you follow that as possible because that's what users are going to expect to use. Using a mouse, or a touchpad, things to consider.

23:31 On a mouse, I don't know if this is something that I ever noticed before until I start seeing accessibility, but it's something that I know that I've used a lot. When you click on something, the action is only on release of the mouse button, not on the down event of clicking down.

23:46 And then navigating off of that when you're still clicked down, should abort that action. So you wanna make sure that everything on your page responds in that same way.

23:59 If there is some sort of timing element, like, if something is gonna time out after a certain amount of time, you wanna make sure that users have plenty of time.

24:05 Maybe time the average user to see how long they take, and then give people, like, two or three or four times that amount of time before something times out. If there is a time limit, it should be able to be turned off or adjusted or extended. Visual elements, so things to keep in mind.

24:21 Making sure that the color contrast is acceptable, across a variety of different ways that different folks see different colors. Make sure you're never using color alone to convey information. Make sure that a feature is usable when zooming in or out, but you test all screen sizes and all screen sizes in both portrait and landscape mode.

24:47 Media, making sure that images have alt text, making sure that videos and audio have transcripts, if somebody can't actually watch the video or audio, listen to the audio, making sure that a video has captions. And then, a video and audio shouldn't automatically start playing when you navigate to your site.

25:04 This is another example, where this accessibility tip is good for every user. Please don't do this. Alright. That is it. That was a lot of information. If you stuck through it, then thank you so much. So just a review of our objectives, a high level overview of what web accessibility is.

25:25 Like I said, you could learn about this for a very long time, but hopefully you have a little bit better understanding than you did at the beginning. And then some tools to get started making the web a more accessible place. Like I said, there's so much more to learn about accessibility.

25:36 If you just start with these things, then the Internet will already be significantly better than it is right now. Here's a few resources. All of the different links throughout this presentation are all located on this one page. I included one more, here, which is Erin Francis's screencast course.

25:55 Shout outs to that because that taught me how to make videos, on the Internet. So that was helpful for making this video. And please do connect with me. I would love it if you reach out and say hello on any of these different sites. I'll also be at the conference. Please do come say hi.

26:15 I promise I am nice. Thank you so much for taking the time to watch this, and I hope that you enjoyed learning about web accessibility and demystifying it for developers. Thanks.