Real Life Accessibility: Have you HEARD your site? by Mike Herring

This video features Mike Herring at DjangoCon US 2018 in San Diego, California, USA.

Real Life Accessibility: Have you HEARD your site? by Mike Herring
0:24:33
Published November 10, 2018
269 views

DjangoCon US 2018 - Real Life Accessibility: Have you HEARD your site? by Mike Herring

In the past it was simpler and easier to think of building websites exclusively for desktop monitors capable of showing 1024x768 pixels, sitting on the desk of a non-impaired, English-speaking person. But today we need to embrace a much broader range of users. And one part of this is designing sites for the visually impaired.

There are automatic checkers that you can use to assess your site’s accessibility. It will tell you that all your images need an alt tag, and that the H2 should come after the H1. This is a good start, but even if you dot all your i’s and cross all your t’s and get 100% pass, your site may be an unnavigable mess in practice.

In this talk we will look at and listen to real world examples of websites that either pass or fail the accessibility test. We will hear anecdotes from actual visually impaired users and discover how they navigate the web. And we will see that even though frameworks like Django can set us up for success, it’s up to us as developers to follow through.

This talk was presented at: https://2018.djangocon.us/talk/real-life-accessibility-have-you-heard/

LINKS:
Follow DjangCon US 👇
https://twitter.com/djangocon

Follow DEFNA 👇
https://twitter.com/defnado
https://www.defna.org/

Summary

Mike Herring argues that accessibility should be treated as a core web-development responsibility rather than an optional extra: it is ethically important, legally required in many cases, and affects a substantial and growing part of the population. He explains the WCAG principles of making content perceivable, operable, understandable, and robust, then gives practical guidance on alt text, keyboard navigation, heading structure, semantic HTML, and ARIA roles and attributes. Automated checkers are useful but insufficient, so developers should navigate their sites with only a keyboard and a screen reader to discover problems that tools miss. Examples from older DjangoCon pages, Amazon, and Mezzanine show how markup choices change the experience for screen-reader users.

Key takeaways

  • Accessibility improvements are usually straightforward and benefit all users, not only people with disabilities.
  • WCAG asks developers to make content perceivable, operable, understandable, and robust.
  • Use meaningful alt text, logical keyboard focus order, properly nested headings, and semantic HTML instead of presentational markup.
  • ARIA roles and attributes can explain custom controls and interface states to assistive technologies, but they should support—not replace—good HTML.
  • Automated accessibility checkers cannot verify the real user experience, so test sites with a keyboard and a screen reader.
  • Well-structured Django templates and Bootstrap components can provide useful models for accessible navigation, controls, and page structure.

Summarised automatically from the transcript.

Transcript

4,521 words · auto-generated Show

Automatically transcribed, so expect mistakes in names and technical terms.

0:05

Yeah, I think that's a good thing.

0:16

Speaker 1: Yeah, thank you very much. Welcome to the last session of talks. I know everyone's tired and tired of hearing talks, so thanks for sticking it out all the way to the end with me. As we said, this is real life accessibility. Have you heard your site? And we're going to get into what exactly that means in a little bit. First, a brief introduction. My name, as you said, is Mike Herring. I'm from Boston, Massachusetts. And I work at a company called American Well. We are a telehealth provider. You might have seen our competitors out in the hall, Doctor and Demand. So uh Hey guys, how's it going? Um and you can reach me at any of these places. Uh unfortunately I I don't do Twitter. I've tried. I'm sorry I can't do it But any of those work just fine. So I consider myself somewhat of an accessibility expert, but this wasn't always the case.

1:03

Speaker 1: Uh years ago, just like most of you, I was working professionally as a web developer and knew next to nothing about accessibility. Okay, so it wasn't that long ago. And I really wouldn't call myself an expert. I'm learning just like everyone else. But the good thing is I can say it's a lot easier than you might think it is. And it doesn't take that much effort to make meaningful improvements in your web content. So what uh why does accessibility matter? And I'd like to start this off with a little quote. He stands like a statue, becomes part of the machine, feeling all the bumpers, always playing clean. How do you think he does it? I don't know what makes him so good. This of course is from Pinball Wizard by the Who. And I was listening to this in the car on Monday on the way downtown to get some beers and I was thinking, yeah, how does he do it?

1:49

Speaker 1: If you're not familiar with the story, this song is about a blind and deaf boy named Tommy, who's able to become a pinball champion. How is he able to do this? Well, if you listen to the song, it spells it out for you. He's able to use tactile response. He's able to feel the vibrations in the machine, feel the impact of the bumpers, and know where the ball is at all times. And I thought this is incredible. What an amazing accessible piece of 1960s technology. Who in here, and I'm assuming most people, has built a website or manages a website? Okay, most people, because we're Django developers, right? Okay. Now wait, keep your hands up. Now keep your hands up if you think Tommy, the blind deaf boy from the song, would be able to use your website, navigate it, find information as easily as someone who's fully sighted and yeah, that's what I thought.

2:37

Speaker 1: That is the issue that we have to resolve. So of course, Tommy is not a real person, but there are a lot of real people out there, real customers, real users, who we do need to consider when it comes to accessibility. As alluded to in the previous talk, I think I got slightly different statistics from a different website, but about 12. 8% of Americans have some sort of severe disability, and that is a huge number. Not only that, but according to CDC, these numbers are increasing. Actually I should say, I should edit this to say these percentages are increasing. It's not just numbers increasing because population is increasing. Percentages are increasing as our population ages. As our life expectancy grows, we have a higher percentage of senior citizens, and right along with that, we have a higher number of people who are suffering from some sort of disability.

3:25

Speaker 1: The CDC estimates around 3% of Americans are legally blind, and that number could double to almost 6% in the next three decades. That is a huge number of people that we might be missing out on. All right, gonna do another pop quiz. Who here uh in the past year or so has dealt with uh an IE bug? Internet Explorer, right? Something doesn't work right in IE11 or something. something lower than that. Right. Most people have, I deal with it. It's an issue. How many people have dealt uh dealt with an issue dealing with visual impairedness? Right? Someone can't use the site because they can't Can't see, they can't operate it. A couple, awesome, great. Not as many as IE 11, which is interesting because IE 11 usage is at 3%, same number as the number of blind people in the United States.

4:11

Speaker 1: I see this as a problem. I don't see why we are not spending as much time and energy on accessibility problems as we are on IE-11. I-11 people have a choice. They were not born using Internet Explorer. They don't have a medical condition preventing them from switching browsers. I think we need to shift our priorities. Of those people who are disabled, Pew research indicates that 23% say they never even go online And only 39% say that they feel confident in their ability to navigate and find information online. We as web developers should be ashamed of those numbers. And we should be doing everything we can to make the web a more accessible place for everyone, not just people who can see and hear. here. Additionally, a survey done by web

4:56

Speaker 1: accessibilityinmind. org of people who actually use assistive technology to browse the web. 43% said the the biggest issue they face, or the biggest blocker in their opinion, to having more accessible content on the web is simply lack of awareness by content providers and by web developers. That's us. Additionally, 85% said given the choice between getting more accessible content and getting more sophisticated assistive technology that could read and understand websites, they said it would be more helpful if we just made more accessible content content. The tools they're using are fine. It's us that is the problem. So we need to take this as a personal challenge. Do I really have to? When I talk to people about accessibility, often I get a lot of groans and And

5:42

Speaker 1: the type of voice that you hear when you tell someone they have to write more unit tests or documentation or they have to support IE11. So if you're one of those people, I have two things to tell you. First of all, it is the right thing to do. If you don't believe me, please refer to yesterday's talk on ethics and engineering. But also, it is the law. That's right, you have to do this in most cases. And I'm going to talk about US laws specifically, but I know there are analogous laws in the UK and other places in the world. If you're familiar with accessibility, you've probably heard the phrase Section 508. That refers to an amendment of the Rehabilitation Act. of 1973, which uh applies to all web content produced by federal agencies. There's also the Americans with Disabilities Act of 1990. This is why we have wheelchair accessible ramps in public buildings.

6:28

Speaker 1: This also applies to websites run by businesses. And uh according to all these regulations, you have to make your web content accessible to disabled users. And you're probably thinking, oh, but do they really check how serious Is this yes they do? Hotels. com, expedia. com, target. com have all been the target of lawsuits related to either Section 508 or the ADA. And your small business could be next. It's not just the big players in this field. I was just talking to someone on Monday who had a client, small business, they were building a website for them. They got hit by a lawsuit related to ADA. There are law firms out there that are actively searching for small businesses with non-compliant So the moral of the story is, yes, be afraid, they are coming for you.

7:15

Speaker 1: Alright, so now if you're convinced that you need to do something about your site, how do you do this? Well, the W3C is here to save the day. This is the World Wide Web Consortium. These are the friendly people who publish the HTML specifications, they have a subgroup called the Web Accessibility Initiative or WAI, who have created even more acronyms They have the WCAG or Web Content Accessibility Guidelines and WAI ARIA or Accessible Rich Internet Applications I'm going to go briefly over both of these. I don't have time to get really deep into it by, but I implore you to go online and try reading them. Let's talk about WCAG. This is organized in four main points about web content accessibility. Your content should be perceivable.

8:02

Speaker 1: And this means perceivable by anyone or anything. This could mean providing alternatives to text, sorry , providing text alternatives to images, to videos, to audio. It could also mean choosing a color scheme so that people with low vision or people with colorblindness can read your text. Uh did you know that six percent of males in the United States have some sort of green weak color blindness? So maybe consider that next time you validate a form and you switch the continue button from gray to green. That might mean nothing. Not only does it need to be perceivable, but it needs to be operable. And there's lots of points under this. Go read about it. The main one is though, can you operate this website using only a keyboard, not a mouse? It's more difficult than you might think.

8:48

Speaker 1: Your content needs to be understandable. This seems obvious, but if it's really complicated, you should explain any acronyms. You should explain complicated jargon. Your website should behave in a predictable manner. You should tell your users what language it's in. And finally, it needs to be robust. In this case, meaning using well-formed HTML and markup, using tags efficiently so that assistive technology can interface with it. That slide was kind of dry, so here are my pats. I would like you to imagine though that their adorable faces are imploring you to go read the WCAG. It's long, it's riveting, and take those guidelines to heart. Something buried in the guidelines is this phrase, following the guidelines will often make your web content more usable to users in general.

9:34

Speaker 1: I thought this was kind of snarky on behalf of the WCAG authors, but it's true. Think about it. making your content easier to navigate, easier to read, easier to understand is going to help everyone, not just people with disabilities. Alright, so we want to follow these guidelines. How do we do it? Let's get down to the nitty-gritty. Let's talk about HTML 2. 0. This came out in 1995. It is 23 years old, and we are still doing it wrong. So let's talk about some things. Let's talk about alt tags. If you've ever dealt with any accessibility issues, you've probably gotten missing alt tag warning a thousand times Please provide alt tags for your images. This is a short piece of text that can stand in for your image. Uh and if you ask someone

10:20

Speaker 1: Traditionally, what's the point of this? They might say, oh, it's in case your image can't load. Well, nowadays you say, oh, that's not an issue. I use S3. S3 will never be loaded. go down. But it's not just about not being able to load the image. Maybe you're just not going to load the image. Maybe you're using a braille interpreter for the site. That's not going to show an image. You need to have something in its place. And please tell your marketing representatives to avoid stuffing this full of SEO and marketing gibberish. This is not the place for it. Tab index. And again, these are things that have been around for a long time and are still not being used correctly. Tab index, when you reach a website, you hit tab, you can cycle through all the links and buttons on the page. Tab index tells you what order to do it. Normally nowadays

11:06

Speaker 1: just set it to zero. That tells the browser go through it in order that it appears in the DOM Now this is important. If you're doing tricky CSS, you're floating it over here, you're positioning it down there, tab doesn't care. It's going to go in the order it appears in the DOM. So keep that in mind. But this is necessary for people who are using a keyboard for navigation rather than a mouse You can also send it to negative one to skip the element. Why would you do that? A common example is the file upload element. Most people are familiar with that. It's ugly, you can't style it, so you move that ugly duckling off the side of the margin. And you put a nice shiny image in the middle that has an on-click event that fires that. Great. But if you don't set the tab indexes correctly, your browser might try to focus that ugly duckling that's off the screen and not the image that you really want.

11:52

Speaker 1: So make sure you set those correctly. H1 to H6. This is really important. If you don't remember anything else about this talk, remember headings. Alright? Organize your document like a tree using headings and subheadings. Usually it's recommended to have one H1 that has the title of your page and don't skip levels. You don't put an H3 under an H1. You don't start your page with an H2. It doesn't make any sense. That same survey that I talked about before from WebAAM users who use assistive technology said the number one thing they use for navigating content is headers or headings. And if they're well structured, it makes it really easy to navigate. So do it right. Before I go to the next slide, uh, so when this slide comes up, I want everyone to look at it. Don't blink, stare at it for two seconds, and then we're gonna read it slowly together.

12:41

Speaker 1: Ready? I need a yes. Yes, okay, here we go. H1 doesn't mean big text. Please stop doing this. And H6 doesn't mean small text. They have semantic meanings. H1 means a level one heading. H6 means a level six heading. You probably won't have a lot of those on your page. Please don't confuse these with formatting tags like bold or center. We should be avoiding using those anyways. This brings me to my next topic, semantic HTML. This is just a fancy word for any tags in HTML that describe what an element is, not how it should be displayed. We use semantic HTML to avoid this horrible condition known as div soup, when you view the source of a page and it's just a div inside a div inside a div inside a div.

13:26

Speaker 1: inside a div, inside a div, and you don't know what any of them mean. Uh well if you have CSS , a user visually can see what all of those mean. But you as the developer and also From an accessibility standpoint, it just looks like a pile of divs. So use semantic HTML, mark things as headings, as paragraphs, use the new HTML tags for headers, articles, footers. This will help the accessibility Accessibility API know what to do with your page. Now, accessibility API, that is a layer that stands between your site and any assistive technology like a screen reader or a Braille interpreter. The accessibility API looks at your site, tries to figure out where the major sections are, where your content is, etc. And if you're using semantic tags, it makes it a lot easier.

14:12

Speaker 1: But there are ways to tweak it, which brings me back to ARIA. We talked mentioned that briefly a minute ago. Accessible rich internet applications. This is a set of attributes and tags you can use in your markup to tell the accessibility API how to interpret it. Most importantly is ARIA roles. ARIA roles are a way to basically disguise one element as another. So say that file upload button we were talking about. We hid the real button. And we had an image that was acting as a button. It was assuming the role of a button. But we hadn't told the accessibility API that it was a button. To it, it just looked like an image. So we need to set role equal to button in order for that to work. There are all kinds of different roles. I'm not going to dive deep into it.

14:58

Speaker 1: Go look it up online. But you can specify, for instance, I want to use this image as a section heading. So set it equal to heading and set the level of the heading. Alerts, dialogues, menus, etc. Besides roles, there are also a lot of ARIA attributes. Again, I'm not going to dive deep into any of these. There are a lot of them, go check them out. But these uh tell the accessibility API things about elements on your site that normally you would indicate through maybe a change of color. This is no longer disabled. Or an icon. This arrow means you can expand or collapse. this element or uh this element has a pop-up when you click on it. These things uh are not readily evident if you're just looking at the markup. All right it makes sense if you have CSS and you're looking at it visually So you can use these aria

15:44

Speaker 1: properties to get that across. Another important one is Aria Hidden. Use Aria Hidden if this is an element, maybe it's just a little graphical flourish. It's not really part of the content. It doesn't need to be represented in any text form, so just hide it. Alright. So we've uh let's say we've done all the work, we've set up our headings, we've done all our alt tags, we think we're ready to go. Time to check our site and make sure it actually works. Now there are a number of automatic checkers you can use. The W3C has a huge list of them. Many of those links are not even broken. A checker is one that I've used. It works pretty well. There are lots of browser extensions And you're going to go back and forth with these checkers many times before you get rid of all the warnings. But hopefully you end up with 100% passing. You'll get a little badge you can put on your website.

16:30

Speaker 1: 100% WCAG 2. 0 AAA compliance. You feel great about yourself, pat yourself on the back, and you're done, right? No, you're not done. Uh I know because I tried that. My boss said, we're gonna make the website accessible. I said, great, I did that much research. I did all my alt tags, it passed inspections. And then I was sitting in a meeting with my boss, his boss, and an accessibility consultant on the other end of the phone who was using just a keyboard and a screen reader to navigate our site. Gave him the URL, he dialed it up, and then there was silence. And then he said, hmm, and that was not good. And he said, is there supposed to be some sort of navigation or menu element on your site? And my heart just kind of dropped Dropped down to here, because I was the main developer for this. Uh yes, there was supposed to be a navigation and he couldn't find it.

17:17

Speaker 1: Once we got him to find it, he wasn't able to open it up. Uh once he was, the links in there didn't make any sense. So after this complete embarrassment, I decided it was time to get real. I decided it was time to unplug the mouse, put on my headphones, open up a screen reader. And you can get one of these for free. If you have a Mac , voiceover comes for free. Use Chrome, there's a Chrome plugin that comes for free. And actually sit down and try to do what this person was doing and try to actually navigate the site. So let's try it. Let me see if I can do this really quickly. Displays. Arrangement mirror. Are you looking at my screen? Yes. Okay, cool. So

18:02

Speaker 1: and this should work. Let's start. So this is gonna be a little bit unfair I wanted to look at DjangoCon 2018 , but I didn't have a lot of time for this presentation, so I decided to skip over that because actually uh congratulations to the DjangoCon web devs. It passes inspection pretty well. So I'm going to go to something a little bit more embarrassing. They still have online DjangoCon 2009, when things were all about gradients and we thought the matrix was really cool. Cool. So let's load up our voiceover application and see what it sounds like.

18:37

Speaker 2: Voiceover on Chrome. Home vertical line DjangoCon. Google Chrome. Mic window. Home vertical line DjangoCon. In home vertical line, DjangoCon, web content, slash logo. png image.

18:49

Speaker 1: Okay.

18:49

Speaker 2: September 8th to 12th, 2009. Portland, Oregon. List six items. Visit it. Link. Home.

18:55

Speaker 1: I just throw about the five.

18:56

Speaker 2: You are currently on a link. Visit it. Link. About. Link. Log. Link. Contract. Link. wiki link contact

19:04

Speaker 1: this one's fun

19:04

Speaker 2: end of list link http colon slash slash djangacon09 dot eventbrite dot com slash You are clink talk. That's not the same. You are current heading level two two items. Welcome to DjangoCon. DjangoCon is a Django conference that aims to bring together the commun voice over off.

19:22

Speaker 1: Enough of that. So let's talk about what we just experienced This is really difficult and I encourage all of you go home, don't do it right now. But try this. Load up a website, maybe one that you manage, or maybe just any old one and try to actually go through it just using your keyboard and a voiceover application. It is difficult. It is frustrating. But it will bring to light a lot of things that you can fix that you probably didn't even realize before Now uh that logo, it didn't have any alt tags, so it just said slash logo. png, not terribly helpful. Uh the navigation worked pretty well. It did there it wasn't using the nav HTML5 element So we it didn't actually say navigation, but we knew it was a list of links. This register link obviously was not helpful unless you picked up, oh, event, uh eventbrite, and you knew it was register.

20:11

Speaker 1: Link talk doesn't tell us anything. And then I get to an H2 called Welcome to DjangoCon. Sounds like the beginning of the page, but it's not an H1, so I feel like I might have missed something So overall not a great score for DjangoCon 2009. But you might say that's unfair, that's not a modern site, we didn't know about these things. Yes, we did. Remember HTML 2. 0 came out in 1995. But let's go to something more modern and see what that sounds like. Amazon. If I a if someone asked me, hey, could you please read Amazon. com to me? I would probably panic and throw up a little bit. I can barely navigate Amazon even as, you know, my only disability is a slight astigmatism, and I can't find anything on here. But let's just see what it sounds like.

20:59

Speaker 2: VoiceOver on Chrome, Amazon. com, online shopping for electronics, apparel, computers, books, DVDs and more, Google Chrome, Mic Window. Navigation. Link. Link. Open menu.

21:12

Speaker 1: That's not.

21:13

Speaker 2: You are currently on a link. Amazon. Link. Prime.

21:16

Speaker 1: Okay.

21:16

Speaker 2: Search. You are currently on a search. All You are currently on a text element.

21:21

Speaker 1: All what?

21:22

Speaker 2: All departments.

21:23

Speaker 1: Oh.

21:23

Speaker 2: Search in. Collapsed. Go.

21:25

Speaker 1: Go.

21:25

Speaker 2: You are currently Go button.

21:27

Speaker 1: So go in, go button.

21:28

Speaker 2: Search.

21:29

Speaker 1: You are currently

21:30

Speaker 2: search. Edit text. End of search.

21:32

Speaker 1: Okay.

21:32

Speaker 2: Deliver to Michael. You are currently on a text element. Weston 02122.

21:37

Speaker 1: That's where I live.

21:38

Speaker 2: You are currently on a text. Link N.

21:39

Speaker 1: Link N.

21:40

Speaker 2: You are currently Visited link. I'm gonna skip ahead to the best. Click to call our disability customer support line or reach us directly at 1-888-283-1678

21:56

Speaker 1: That is the dev saying we know it's a hot mess, just call the hotline. And honestly, I'm tempted to use the hotline too because I honestly can't figure out how to cancel showtime. All right Let's check out Mezzanine. Uh if you're not familiar with Mezzanine, it's another CMS similar to Django CMS and Wagtail. And the great thing about mezzanine is uh if you set it up with the the demo site, it uses uh they put together some default templates which are really out of the box, very accessible. And part of this is because they are using bootstrap templates and bootstrap components. If you want a crash course in how ARIA roles and ARIA attributes work, go check out the Bootstrap components. They have it set up really nice. All of their menus, their modals, their buttons, they all use these attributes. really well. So let's see what mezzanine sounds like.

22:41

Speaker 1: And this is just a basic default set of

22:43

Speaker 2: voiceover on Chrome. Blog vertical line mezzanine. Web content. Navigation.

22:47

Speaker 1: Great. Tells us there's a navigation.

22:49

Speaker 2: You are currently on a navigation. Visited. Link. Mezzanine. An open source content management platform. Search. Search. Edit text. Everything. Collapsed. Pop-up button.

23:00

Speaker 1: Tells us it's a collapse.

23:01

Speaker 2: You are currently on Go button. End of search. List five items. Visit it. Link. Home. Link. About. Visit it. Link. Blog. Link. Gallery. Link. Contact end of list end of navigation heading level 1 log

23:14

Speaker 1: starts with an A.

23:15

Speaker 2: You are currently on a heading level 1. Inside of web content. To exit this web area, press con Voice over off.

23:21

Speaker 1: I'm going to cancel it there just so that we can let our ears rest for a second. Um but the uh overall I would say mezzanine does a great job. If you're looking to try to start up a very accessible Django application, try Mezzanine. Look at what the templates are like, try to extend them or style them, or at least see what they're like. All right. I am just about out of time here. A call to action for all of you. I want you to build accessible websites. So with that in mind, can everyone please raise the right hand? Put it over your heart and repeat after me. I your name. Don't do that. Don't do that. Do that. Do solemnly swear.

24:06

Speaker 1: To make the web a more accessible place for everyone. Awesome. Thank you very much. That's the end.

Questions this talk answers

Why does web accessibility matter?

Accessibility affects a large and growing group of users, including people with visual, hearing, motor, and other disabilities. Many disabled users lack confidence online because websites are not built for them, and accessible content generally improves usability for everyone.

Discussed at 2:37

Is website accessibility required by law?

In the United States, Section 508 applies to federal web content and the Americans with Disabilities Act applies to websites run by businesses. Companies of all sizes have faced accessibility lawsuits, not just large corporations.

Discussed at 5:42

What are the four WCAG principles?

WCAG says web content should be perceivable, operable, understandable, and robust. That includes alternatives for non-text content, keyboard operation, clear and predictable content, and well-formed markup that assistive technology can interpret.

Discussed at 8:02

How should I write alt text for images?

Alt text provides a textual replacement for an image, including when someone uses a braille display or otherwise cannot see the image. It should describe the image’s useful content rather than being filled with SEO or marketing language.

Discussed at 10:20

How should headings be used for accessibility?

Use headings to organize the document as a hierarchy: normally one H1 for the page title, followed by properly nested subheadings without skipping levels. Headings are one of the main ways assistive-technology users navigate content, and they convey structure rather than text size.

Discussed at 11:52

What is semantic HTML and why does it help accessibility?

Semantic HTML uses elements that describe what content is—such as headings, paragraphs, headers, articles, and footers—instead of relying on generic divs and visual styling. This gives the accessibility API meaningful structure to pass on to screen readers and other assistive technology.

Discussed at 12:42

What are ARIA roles and attributes used for?

ARIA roles and attributes tell the accessibility API what an element is and what state or behavior it has, such as a button, heading, menu, expanded control, or popup. They are especially useful when a custom visual element is acting like a standard control or when a state is communicated visually through color or icons.

Discussed at 14:12

How can I test whether my website is accessible?

Automated checkers and browser extensions are useful for finding many issues, but passing them does not prove that the site works for real users. Unplug the mouse, navigate with only the keyboard, and use a screen reader such as macOS VoiceOver or a free Chrome option to experience the site directly.

Discussed at 16:30

What accessibility problems can a screen reader reveal?

A screen-reader test can expose missing image descriptions, unclear link labels, missing navigation landmarks, and poorly structured headings—problems an automated checker may not make obvious. The speaker demonstrates that links such as “Talk” or an image filename are not meaningful enough for someone navigating by audio.

Discussed at 19:22

Presenters

Note: We understand that names change, people change, and bodies change. We respect each individual's journey and privacy. If you have any concerns about a video or need us to remove content, please don't hesitate to contact us. We will handle your request with care and promptly address any issues.

More videos from DjangoCon US