Jay McKay: Welcome welcome to our Accessibility Office Hours! This is Jessica McKay, or Jay Mckay, the Director of Community Programs with Knowbility and we welcome you to our very special Web Accessibility: Ask Me Anything with Eric Eggert.
So we are thrilled to be here. Let's get this show on the road!
Of course you know Knowbility. You love us. We are here today to talk about something that is near and dear to our heart, which is web accessibility. Because that is our mission: To make sure that all digital spaces are accessible for people with all disabilities. We do that through several different programs: Through our community programs, such as AIR, AccessU, AccessWorks, as well as our commercial services through our Accessibility Services Team.
We are a non-profit, so we want you to help us keep the web and make it more accessible. So we invite you to check out our Donate Page at knowbility.org/donate
And don't forget, today is Giving Tuesday. What better way to celebrate Giving Tuesday than to donate to us. And when you do that, don't forget to check with your employer about those matching donations. Several different employees, employers will do a matching donation to get that little extra bump to us. And we would greatly, greatly appreciate it because we want to keep bringing these different programs to you, these different opportunities, and really, truly make the web accessible for everyone.
So just a couple of guidelines to get us started. As we process forward with our event, we always have our guidelines. The purpose, of course, is to create accessible and inclusive spaces, so we always ask people to be kind and polite and respectful. And we also ensure accessibility is as much as possible. So we have, of course, Texas Captions here today, helping us out with our live captions. Pland is with us today as well to help make sure everything's working in the background. And we will continue to do those for you throughout the day, so thank you.
Now, today's a little special because we are doing an Ask Me Anything. We already got some responses, and we're excited to dig into those, but as you you are watching this event, if there's a question that pops into your mind, or you want to participate, if you are watching on our YouTube Live channel, you can go ahead and just type that question into the chat.
You will need to be signed into your YouTube account and you probably will need to create a channel if you haven't already done so. If that sounds like too much work, don't worry about it. You can also just go to a Google form that we've created. And it is bit.ly, so it's B-I-T.ly/AskKnowbility. And that's going to be a capital A and a capital K, for Knowbility. So bit.ly/AskKnowbility.
Alright, so I'm going to step back here in just a minute or two but first, I want to introduce our host and moderator, Anthony Vasquez. He is our Communication Specialist. Anthony has been with us since 2014, starting first as an Accessibility tester and now as our Communications Specialist.
In addition to that, he's been teaching journalism, has a master's degree in Eastern Asian studies from Stanford University and has a degree in journalism and Chinese studies from Cal State at Long Beach. So thank you, Anthony, for being here. I can't wait for you and Eric to have this conversation and see what kind of wonderful things we're going to learn today.
Our guest speaker today is Eric Eggert. He is our Director of Accessibility Services. Eric started as a web developer turned accessibility expert while studying Media Informatics at the University of Vienna, Austria. That is where he discovered his passion for accessibility. Before coming to Knowbility in 2016, Eric had done quite extensive work with the W3C program as well. So thank you, Eric! And so I'm just going to step out. Eric and Anthony are going to take over. I will be here to monitor the chat in the YouTube channel, as well as any of those additional questions that pop up. So I will be here to monitor any of those. Take it away!
Anthony Vasquez: Alright well thank you, Jay, and welcome, everyone, to our third Office Hour of this Office Hours series. Again, I am Anthony Vasquez and I'm here with Eric Eggert and we did get a few questions ahead of time, which is great. And we will get to those, of course, but I'm gonna probably just start off with a quick few biographical questions for Eric myself. I've heard the story about how he's gotten into the field, but I think it'd be good if a lot of new folks, maybe to accessibility, joining us today, hear more about Eric's, like, story. How he got here. So, Eric, I know it's, you know, we do want to get to the real nitty-gritty stuff about, you know, responsive design and all that of course, but you can just give us a quick intro to yourself. How did you get into this field?
Eric Eggert: Yeah good question. I — I will say the short version today because of time. So first, I'm Eric. I live and work here in Germany.
And I wear a blue beanie today because of Blue Beanie Day, which is a Web Standards Day. And that's actually how I got into accessibility, through the web standards movement. Starting out with, like, trying to do my own websites, uploading, you know, little programs I wrote to the Internet, thinking like, I'm a big programmer. I wasn't actually that good. And then when I moved to Vienna to start studying at University, I got into a really nice accessibility community that consisted of like, many people with various disabilities with the common goal of making digital spaces more accessible. So, and that intersectionality basically made sure that I felt welcome there. And yeah, that's basically where I start getting, digging more into accessibility. And when I then, in 2010, moved back to Germany, I found another, like, small group of people and we worked together to make a nonprofit website accessible, pretty much like the AIR program that Knowbility does — donate to Knowbility! — and that was a lot of fun, being in a group of volunteers and doing that. And, with my accessibility skills, which I had been building out by then, I could help. And we actually even won a prize, which was, like, pretty overwhelming because that doesn't happen that often in the web.
Anthony: Gold prize, right?
Eric: Yeah, like the top, top prize in that category. And And yeah I mean, if you're not doing, like, flashy animations and stuff, it's really hard to win prizes. So that was my only chance. And so we got that as a group. And from there, got the connected to W3C and then, you know, from W3C, into Knowbility via Sharron Rush, our CEO.
Anthony: And here you are. You know, one of the things that jumped out at me when you mentioned this — you, you mentioned an accessibility community while you were at University. And, you know, I'm blind, so I've been using screen readers for 20 years. You know, of course, accessible information and technology is — it's, like, crucial to getting me where I, where I am.
But you know, I've always thought about this stuff as like, in the word of like, "accommodations." That's kind of the American model of, like, you know, "You have to accommodate this student for this disability." It was really until I got to grad school where, at Stanford, you know, they call it the Office of Accessible Education. Finally getting kind of, focusing on this more universal design approach to learning and an extension to just doing things on the web and in the world.
Do you have any feelings about why maybe, you know, in Germany and Austria and probably other parts of Europe, this — and you know, maybe I'm wrong about it, but, like, there seems to be this focus more on accessibility as a, as a goal, as a tool to incorporate disabled people in society. Whereas, at least here in America, at least until recently, it was all about accommodations. Do you have any thoughts about that?
Eric: Yeah, I think that's probably a tough — I think that's, in general, a generalization, which is in the world because, you know, we have, especially in Germany, we have a lot of like, different accommodations for different disabilities. And, and a lot of like different streams of making sure that people get the support that they need. In Austria, it seems to be a little bit different and that might be stemming from just having, like, really good advocacy. Organizations that said, "Oh, we all have to like, be together to move accessibility as a whole thing forward. And I think those are more regional things. So, you know, being in Vienna it's really uh easy to have, like, a lot of people because it's a big city for European standards at least. And you, you know you have a better, like, melting pot of these different, different people being active. And so — that helped for sure.
And yeah. But, you know, it's different in all the countries and I think the European Accessibility Act hopefully helps us a little bit to harmonize that. And also, maybe, the reason is to have like more of a social system, social safety net and trying to graduate, or helping supporting people with disabilities to graduate out of that safety net into more of a self-sufficient standard. Because that's, you know, that's better for everyone. >>Anthony: And that's an exciting development, the whole accessibility directive out of the EU, which could be it's own webinar.
Think about it. But I do want to get to some of these questions. And Jay is also monitoring any last minute comments or chats and, or current chats that's in the YouTube. Anything of note Jay?
Jay: Yeah! Sure, so this one is a quick one. What does A-11-Y stand for?
Eric: Good question. Good question. A-11-Y stands for accessibility. The so-called, so-called numeronym, which is a hard word to say, almost inaccessible as the word accessibility itself. So. And basically you take the first letter and basically you take the first letter of a word and the last letter of a word and then everything that is in between, you just count the letters and you just count the letters and that is your abbreviation. So you have 'A' and then 11 letters, which is accessibility and then the "Y" at the end.
And, for example, internationalization is using the same scheme for being able to write it really quickly. That's more like a branding thing to be honest.
Jay: Alright, we have a couple more. Some of these are — I'm gonna try and group up a little bit. This one is just, "What are some common struggles that come with internet accessibility?" And if you feel like that would be better answered as we go through the other questions, that's fine, but maybe if you have one or two quick things you want to hit right now ...
Eric: There are many struggles but I think the, the biggest the biggest challenge in web accessibility for me at this point is the gap in education. That we don't have enough people educated in terms of what accessibility means. What the general information is that, that needs to be taught to people who are staring out so they can just make accessibility as the baseline in their work. And of course they will struggle and fall like a toddler that tries to get, you know, walking. I'm really good at like, metaphors. And, you know, they will struggle and they will fall at things.
But at the moment, it's like not even attempting to give people the tools they need to make the web accessible. And I think that's like the biggest challenge. And then the rest is all following from that.
Jay: Okay. We actually had one in our YouTube chat that says, "Given that automated testing can't catch all the accessibility bugs, how much and what manual testing should we do?
Eric: That's a good question and I'm personally struggling with that because I — I test websites by looking at it, which is something, I think, something that you can only, can do with a lot of experience and, like, seeing a lot of the failure modes or or the issues that crop up. You know, I look at a link and I click on it and it behaves weirdly and then I go like, "oh this must be an issue," and it usually is. And then I, you know, I go in there and I find the root cause for the issue. But that's not for everyone. Not everyone can just amass the amount of experience which you need to do that. So I think automated tools can help to find issues.
I think automated tools struggle with providing solutions for those issues because you always have to have someone who tests the validity of these claims and issues in the context they appear because sometimes, you know, there might be a little bit of wiggle room there. But there's a whole group of accessibility issues that you can easily find with automated tools and that are, like, real hard fails, like images without alternative text, wrong language declarations, I don't know, buttons that have no label on it. So there's a lot that you can easily find.
And I think having this first line of defense in an automated tool is always good for, like, finding errors that have been coming to the code base.
Jay: Alright! We do have a question on accessibility and usability testing. It says, "How much do accessibility and usability testing cost and why should I do these?"
Eric: That's a good, good question that I can't answer straightforwardly usually. When I did websites for a living, I always said it costs as much as a car costs which basically means, like, you can get like a small, you know, mini-type of car or you can get like a really big type of car. Or you can get an American-sized car, which is like, super big.
Which is totally, you know, you can — you can change that. We at Knowbility usually calculate around four working hours per page for simple pages. For like more complex pages, it can go to six and eight hours per page. And that is all manual testing for accessibility. I'm not 100 for accessibility. I'm not 100% sure what the usability prices are and and how much, like, effort that is. But there, it also depends on like, what kind what group of people you want to test the website and, you know, is it a test that involves someone doing the — also crunching the data, or do you want to crunch the data yourself and do all that research yourself. So yeah, the best way to to get like a quote is to reach out to accessibility professionals and ask them, you know, "This is my page, these are the pages I need to test."
And then you get a quote back and you say, "Oh, this is a lot!," or you say, like, "Oh, this is reasonable."
Jay: Thank you and I'm gonna and — we had a comment from Jock. I do have your questions so I'm gonna kind of intersperse those with some of the other ones that we are receiving through chat. So I'm gonna hit that first one. It says — and this is talking about looking at designing a website I believe, but then also, you know, being able to use that website on more mobile devices. So the question is, "Should I instruct or direct web designers or developers, anything, regarding the swipe feature that is used on the Apple iPads?"
Eric: I'm struggling a little bit with that question because I've felt that there, there is some context there that I'm missing.
Anthony: I think I have a set of questions here, too.
Eric: Yeah so in general, there is a set of — yeah, there is a set of questions — a set of swipe gestures that you can use when you're using like voice over and stuff of that, stuff like that. And there are cheat sheets online that you can download and that instructs you how that works and Anthony can probably talk about that a little bit more. And yes, when you're testing with screen readers, you have to make sure that you are aware on all the modes and, and that they can use to access the content.
Anthony: I might be able to give some more context here. If it's the same set of questions, there's some background here. so the person writes, "I have built content for a single-page website whose audience is adult sufferers of dementia, from mild cognitive impairment to profound dementia. And it's also going to be these folks may have poor eyesight — kind of paraphrasing here — and also would, you know, the audience would include their non-disabled, as written here, relatives, basically. So that gives us some context, but I guess what I would add for the swipe gestures — if the website is coded accessibly, voiceover features anyway should work normally without any interference from the developer. And I guess, I'm supposing here, kind of like scrolling right?
As a sighted person scrolls, that should work normally if it's done accessibly. But here, I can add a bit more context here. The person writes here, "Broadly, what special features of a tablet that do not exist/hold with a laptop of computer should I instruct the designer and developer to incorporate into the finished website?" So maybe here's a bit about responsive design, right, Eric? I mean like, what, yeah, how should they consider when they're gonna have people probably approaching things on tablets but also on desktops and, you know, more and more as we all do it, on our phones?
Eric: Yeah I'm, I mean the thing with accessibility is that it's already, like, trying to cover all those modes and it does some of those things better and some of these things not as good because, you know, it's not specifically for that one use case — tries to be very general. So for tablet use, I think, like, having big buttons that you can easily tap especially with, like, people with cognitive disabilities, it can be useful to have like clear instructions, clear colors, not having any yeah, and any misunderstandings between what things do. Like the 'next' button should always be at the same position, in the same color for example. And, and just making sure that that works. I don't think that designers and developers would integrate things that don't exist within a laptop computer because a lot of laptop computers can be used with touch screens at this point as well, especially on the Windows side. And so I think, you know, just follow the best practices. Try to make the interface as simple as possible. Maybe think about, from a design-perspective, to have single-use screens so that you don't do a task on more than one screen at a time so you don't, like, overwhelm people with features and functionality. But yeah, I don't, I don't think there's anything that's super special considering the mode of the, of the delivery mechanism, basically.
Anthony: And that was another question, was about screen sizes and whether they should, like, give specific dimensions of any sort or, as you were saying, just basically, if you make it responsive on one platform and it's accessible, it'll resize to a tablet or an iPad Pro, for example. Right, those are huge screens there.
Eric: Yeah and, you know, responsive design is super important for accessibility because it covers a lot of people's ability to access the, the web content or the other content in general at the same time, so there is not this like, "Oh, to look at it on your phone, you go there and to look at it on your big computer, go there." As for screen sizes, basically all the screen sizes, which sounds harder than it is. So, especially with the new CSS grid CSS Flexbox functionality (and this gets develop-y, but that's what I promised — I've got the blue beanie on, right?) You, you can specify your content to just adapt to any size you can with grid. Say oh, this is my grid, my layout for like small screens and then you scale it to two-column layout then to three-column layout, then you say like, "Oh, I want space on both sides when it's over a certain size." And you can all do that in like one line of CSS for each screen size. So it's really straightforward to like make sure to have like, start with a small screen, always mobile-first, linearized, and then, you know, zoom out. And once you say like, "Oh this looks not good," you go into the next stage. And and make a media query and make sure that, that your layout adapts to that stage.
And yeah, and then you know it can float around really nicely between those stages. And you should should try to avoid to have specific width and specific breakpoint width because I think that is pretty much a thing of the past. Because of so many, many screen sizes, you can't — you can't just say like, this is iPad size. That's not a thing because there are like seven different sizes of iPad these days, right?
Anthony: And so you know, the set of questions here, the person talked about CSS, CSS 3. What resources do you recommend for more info on CSS? They recommend here that they get a link to W3 Schools — is that something you refer to, or maybe, what what are your go-tos when it comes down to giving these kind of recommendations? Besides your own personal experience.
Eric: Yeah! Yeah … W3 Schools was a really, like, not preferred to go to a couple of years ago. I think they improved. That said, I always go to the Mozilla Developer Network — MDN — because they are basically a wiki and you can make contributions if you want to. And if you are not like I am, you really like that kind of stuff. And they also have, like, all the current information on there. It's a very active community. So that's what I, for any documentation on the web, I recommend that. There are great articles on csstricks.com, which really give you a good insight on what the new features are. They have a great grid and flexbox article that gives you all the information on that with nice illustrations. So, you know, because CSS is such a visual medium, it makes a lot of sense to have, like, something to look at while you're, while you're learning it. And but also good, like, textual descriptions, of course.
And there are a couple of good video series on YouTube as well, on new CSS features. So if you're a visual learner, I, you know, on YouTube, there's almost everything.
Anthony: YouTube, YouTube is great for lots of stuff. I would recommend this and also Googling like screen reader demos that YouTubers do. People are making good stuff like that online now. It's quite nice.
But I want to continue here with that same set of that single-page website and they write here, "Do you have any advice how I should address, speak to my audience of people suffering with memory loss without insulting them?"
So, this is anything goes on this. "It's a soft, non-technical question. I have yet to find a website anywhere in the world —" wow, "with such an audience and thus have no example to study or emulate."
So what jumps out at me real quick is the importance of plain language, writing in plain language on any of the copy that they include. What else would you say? Maybe things to reduce anxiety? I mean, I'm not sure. You can take it kind of anywhere it strikes you.
Eric: Yeah, I think this is, on one hand, this is, like, content-specific, so you want to make your content straightforward and clear, and, you know, you probably don't want to use, like, metaphors and other like phrases that could be misinterpreted. I think you are, you want to be direct with those, with that audience. I think there's no, no need to be especially, like, soft or — or like — hesitating to them. They are people living with memory loss and that's how I would address them. And you know it's — it's a disability and I don't think there's a right or wrong way to do that. I would, I would be very straightforward. I would be — you know, just make sure that you don't talk down to them but talk to them on eye-level because that's something that happens totally easily when, when people, especially if they don't have, like, background working with people with cognitive disabilities on a day-to-day basis, they always — they often fall back onto, like, not taking them as seriously as they should. So I think giving them the benefit of the doubt and being really straightforward, you know, with them is super important.
Anthony: One thing that just occurred to me right now and it's the book recommendation. It's a book I've been meaning to get to just because it's a topic that I'm interested in. It's called "On Vanishing."
Oh, the author is the name escapes me right now, but it's all about, like — I think it's a former chaplain or a minister and she writes about working at, like, nursing homes, working with people that have memory loss. It's just an interesting book, whether or not not this person has already read it, or just anybody: "On Vanishing." I haven't gotten to it yet, but I think it's a good — and it's non-technical and all that — but it's a good way of kind of approaching this, this group of people. I want to turn to Jay real quick and see if anything else new has come up on YouTube or elsewhere.
Jay: Oh of course, we've got a long list of questions here.
Anthony: Alright, let's go for it!
Jay: Okay so we had a series of questions and let me see, hopefully I can read these properly. "I have a question regarding ARIA Hidden or ARIA Modal when making accessible modal dialogues. These ARIA properties only prevent screen readers from reading contents that are outside of the active dialogue right? They have no effect on keyboard behaviors like trapping the keyboard focus within dialogues? In other words, we need to separately code JavaScript to trap keyboard focus, right? So I think they're looking for some confirmation.
Eric: So the simple answer is, yes that's correct. The complicated answer is that it's complicated because it's ARIA. And so yes, if you're using ARIA Hidden, basically the content, the accessible name in the role of the element is taken away and the element disappears from the accessibility tree. That's true, however, it still stays in the DOM, which is responsible for the keyboard navigation and moving the cursor to the, the element. So if you have an ARIA Hidden link, it will still be in the tab navigation, it just won't be announced because it has no accessible name and no role, so it's basically like walking through like a really foggy — what, I told you I'm good at metaphors — and it's, it's something that you don't want to do. So yeah, you have to put the rest of the website as inert, so you have to make sure that it is basically all deactivated and you can't move it. And role dialog is basically only saying, "This is a dialog." There is different behavior in different browsers. So on webcam browsers, like Safari on iOS and Mac OS, actually having a dial — an ARIA dialog element, an element with the role dialog is actually setting the rest of the page trainer, which basically means that if you have a hidden dialog on your website, there is a possibility that everything else on your website is not available to screen reader users at all, which is terrible. And we've seen that with client projects so beware.
But good news: So that's like the third level down. There is a big push to make a proper HTML dialog element a thing and I, for the first time in my life I'm, positive that I will live long enough to see the dialog element in HTML working properly.
Jay: Alright, here's another one. This is, "When are duplicate ID errors a problem for accessibility? Is it only an issue for input fields?" They would like to understand more about this issue.
Eric: Good question. Yeah, so this is basically — so this is an error of a WCAG 4.1.1.2, which is name row value. This is a completely different thing (4.1.1 passing, of course). And the thing is, when WCAG 2.0 was created, HTML did not have a lot of good fallbacks when there was an error in the code, so you didn't actually know what would happen when someone would do, would do something like having two IDs and then referencing that ID in the code. Now, with HTML5, so for about 10 years now, it's specified that the first ID is used. So this is actually something that is only a problem if you meant to point at the second ID or the second element with the same ID and you have not done that. It's super uncommon that it's a real accessibility problem. That said, it will always trigger failure of WCAG 2.0 because, or, because it is in the spec and that's how we have to test it. So yeah, that's, that's just how it is. But, but yeah it is usually not a big issue in terms of, like, an accessibility barrier.
Jay: Alright, we have another one here, "What suggestions do you have to show that focus has been set on a non-interactive element with tab index equal negative one? We definitely don't want it to look like the focus indicator used for interactive elements."
Eric: Yeah, the best way is to have it look like the focus indicator on interactive elements. If that's not a possibility, there are a couple of ways to do that. So one would be if it's on like a box of a sort of thing, you might add a box shadow to it. But beware, that is not available in high contrast mode, for example.
If you are, set it to a text, you might want to add like a two-pixel left border to the element to make sure that, you know, this is the thing that is there, that the focus is there. It's mostly a design challenge and I think designers can come up with much better solutions that I, that I can come up with because I'm not a designer. But yeah, I think, in general, keeping it as close to the standard as possible is usually the right way to go.
The other question is for many of those, like, setting the focus, you don't need to have a visual focus per se, so. WCAG says you have to have one but that is mostly important once you move the focus from element to element. So if the page loads, for example, there is no visual focus on the page although there is a focus theoretically around the whole page. So if you have a single page application and you load a new view that fills the whole page, I think no one would expect to see a focus outline in that case. So I don't think that's like a super hard failure. As long as the next tab stop is clearly identifiable, you can orient yourself around that, I think that would probably be okay.
Jay: Alright, and this one was sent into us but this is also a question I have sometimes, too. Our developer's website is highly technical and has several complex diagrams and flow charts to explain operating systems, architecture, and concepts. Could you please recommend some guidelines for implementation captions and long descriptions? Thank you." So I know that's a big one for me too, is when, when we're getting really long descriptions of items.
Eric: Yeah, I mean there's no way around it, to just write it out and describe the whole image. I mean, there — there are probably programs and apps and maybe, you know, ways to have an accessible version of that chart, but I think the easiest way is to just write out what is, what you can see on the chart. What the next steps are, you know, if it is a line charts or organization chart that you clearly specify what that is and then just writing it out in the long text, hiding it in a maybe details element on your page and, and saying like, here this is, the long version of this, this content. Because in the end, that will also help you to understand the chart better. And, for me, it happened a couple of times that I did start the exercise and I was like, "Oh yeah, this whole branch is totally not useful for me" or "I can simplify this." Because I can, if I can simplify it in text, I can also simplify it in the chart. So it gives you a nice way to, like, review your work for existing content. I would just, like, write out what you see, like, where the chart starts and how it, how it works out. So I don't think there's a lot of leeway to do something else.
Anthony: Okay I have a follow-up question about that real quick. So the long description shouldn't be confused with the HTML like longdesc, right? Is that still a thing, Eric? Or are we done with the longdesc?
Eric: Longdesc is not a thing anymore. R.I.P. longdesc. [Laughter]
Eric: You know if you, if we later at the bar, I can talk to you about the long and hard life of the longdesc attribute and why it had to die at some point because it's actually a fun story. Well if you're me it's fun. For everyon else it's probably like, 'nah.'
Anthony: Sounds like a topic for a row of drinks, right?
[Laughter]
Or gross thing, yeah it's funny. Anything else? I think there's more.
Jay: Oh yeah, there's, there's plenty. We had a question about what accessibility issues for people with aphasia. So if you're designing your websites, what are some things to keep in mind if your users have aphasia" — and I can give you a quick summary of aphasia if you need —
Eric: Yeah do that, especially for the people watching on YouTube.
Jay: Not a problem. So aphasia — and I've just pulled a quick mayoclinic.org, just so I'm correct in my understanding — and this is a condition that can impact your ability to communicate. So it can affect your speech, your writing, also the ability to understand language, both verbal and written. Typically will occur after a stroke or head injury.
Eric: Yeah see that was all good information and I knew, like, half of it really well and the rest of it, I was like, yah, that sounds about right. So it's always good to have, like, — especially if you're talking about medical conditions — to have a definition for that. So the most important thing is, don't trigger strokes. I mean, that's like, that should be the top of your list.
And you do that by avoiding flashing content, you know, stark lighting conditions, maybe avoiding, like, high contrast. I mean, we are in the web. We always say, like, your contrast needs to be higher and then, you know, people with like aphasia or like other visual disabilities, say like, "Oh, can I have less contrast?" And I think, with dark modes and stuff like that, we're getting there.
Yeah, so you want to make sure that you don't have content that triggers those conditions. You also want to make sure that you don't have too much movement on your website or in your app because that can also be triggering. And that basically gives you the baseline. And then for the results, once you are — once a person is experiencing those conditions and it looks like they are very varied across like different, different people, you know, the normal accessibility principles need to be followed. So make sure that all the content is properly perceivable, that the content is operable and understandable, and that they can access it and use all the different accommodations and and tools that they want to use to access your content.
Jay: And I think for me, from my background when working in school districts and looking at, you know, principles like Universal Design for Learning, you know, when I think, "Oh, somebody's going to have difficulty with potentially understanding language," you always want to have that, you know, other medium, possibly for them to understand. So, you know, I'll — immediately, my brain is going to go, "Oh well maybe I need to look at how my layout's looking." Also maybe include some visuals, but if I do that, then I also have to remember about making those visuals accessible as well.
Eric: Yeah that's, that's correct. And that's the big, like, warning sign. If I had like a red warning sign, I would hold it up, of having different content for different types of disabilities, which I always warn about. People really like to say, "Oh, that I can just do a website for screen readers," and then go like, "Yeah, but if someone has low vision and comes to the website, what happens? Then do you want to, basically, dump them out to the screen reader website as well? You know, what if it's someone who's deaf comes to your website?" You don't want to give them the same experience as for screen reader user because that makes no sense. So, so you know having different ways, different lanes you have to get into that also define only one disability in the end, that's always, like, a dangerous path to go.
And, and so thinking about universal design, having one product that everyone can — or inclusive design — one product that can actually be adapted to your own needs. That's the much more useful way to go around with those with those problems and making sure that you don't run into the issue. you don't run into the issue. That you say like, "Oh yeah, I did something for people with certain disabilities," but it doesn't work for all the other people So you want to make sure that you are building your content inclusive.
Anthony: Question here I've got. Just a short one, but probably deserves a long answer. It goes, "Why bother with alt tags when A.I. can fix all that?" So that even the premise there might be a little off there, about the artificial intelligence fixing or giving image descriptions —
Eric: Yeah. Shoutout to Nick who sent in that question in like, a joking way, but I really wanted to answer it so I put it in the document. So yes. So the question is, "Why bother with doing something for accessibility when there is A.I. or tool to to fix it?" And the answer is tools are really bad at doing that job. Like there are things — and I talk about that with, like, automated testing that tools can do really, really well, like looking at code, making sure that, you know, to highlight errors or potential errors. That's all good and well.
But if you have something like alternative text that is so dependent on the context — an A.I. can identify what is in the, in the image and suggest a good alternative text for the image on its own. But there will always be missing the context around the image. And, you know, I always say the best A.I. alternative text is as good as the worst manually created alternative text. And that means you're just looking at the image and you describe what's in the image and you put it into the alternative text without any awareness of what's happening around you. And that's better than nothing. And that can even be, in some instances, better than like an empty alt text or better than, you know, someone who means well and then writes a bad alternative text. That happens. But in many, many situations, it's just not a good experience. So yeah, you always have to look at the surrounding things. And, you know, I'm the first person who is happy once A.I. is so good that it says, like, "Oh yeah, and we analyze the rest of the page and we know that you know what the alternative text should be, alternative text should be and it's always spot-on"— I'm happy to cross off that testing step from my list to test. But until that happens — I think realistically I won't live long enough to experience that, so — and then I'm happy to be surprised.
Anthony: Alright, we're about 10 minutes to the top of the hour. Any more questions, Jay?
Jay: We have a, we have quite a few. I don't know that we'll be able to get through all of them today, but as we said in the chat, we will make sure that if we have not covered your question in this video today, we will be putting up a blog post fairly soon to make sure that we have answered all of your questions as best we can with the information that we have in here. But we do have — let me, I just had it and now I've lost it.
Eric: That's okay, take another minute to find it. Just, just to say that: You can buy this! just go to knowbility.org and you can buy, you know, this expertise and and ask as many questions as you want for exchanging money. And don't forget to donate to the, to Knowbility so we can do more of these, because then you can also answer more questions. Hint, hint. Nudge, nudge.
Jay: Actually this, I think is a good one, too: "If somebody doesn't know about accessibility, or if they don't have anybody in their immediate circle with a disability, what are some things that they can do to either become a better ally for people with disabilities? But I'm also thinking about how do I get buy-in, maybe, from my colleagues that I'm working with and I'm trying to push the importance of accessibility? Like, what are some good ways to do that?
Eric: Great question. I think the, the most important thing is: Read. There's a lot of content there out there that can be, that you can read that give you a context on how people with disabilities use the web. One of those three sources is called, 'How People with Disabilities Use the Web.' It's on W3C. https://www.w3.org/WAI/ website. So you can go there and really read up in a very, like, straightforward way on what the needs are for people with different disabilities, what areas do they experience, and how they use tools and techniques to fix them. So I think that's always a great start to, like, understand what the actual needs you want to address are.
Because I think a lot of people don't actually, even if they want to make accessibility happen, want to avoid talking about disabilities, which is probably a natural reaction but I think you can't dive- you know, diverge from the actual disability and the challenges and, and make accessibility. That just won't, won't happen because you have to prioritize by the barrier. So that's the w3c.org/WAI/ and then somewhere there is, 'How People with Disabilities Use the Web.'
To convince your, your co-workers and stuff like that, same website, there is the business case for digital accessibility, which is an amazing resource. Sharron Rush, our CEO, worked on that. And it's a really good article. It's much less technical than as you would expect from the W3C resource, which makes me like it very, very much. And you — it, it has quotes from different people who worked with the, worked on accessibility in their companies and showing what the benefits are, both in legal, in like humanitarian, social goods, regards, but also for, like, innovation and all these aspects. So it's really, really good resource: 'The Business Case for Accessibility.' And I would, I would super recommend that. I mean, the buying power of all people with disabilities in the world is a lot of money. So, you know, you, you really have something in your hand and that's people with disabilities and their, like, circle of, you know, friends and family. Because, guess what? If you don't produce an accessible TV, someone with a relative that has a disability will also not buy that TV. And Jay, you're muted again.
Jay: I'm that person that always wants to make sure I'm muted until I shouldn't be. I want to thank you both for being here! This was just — my mind is blown. I've, I've learned quite a bit today. I hope everybody who's joined us has. Thank you, everyone, for attending! I'm going to share my screen real quick as we wrap up our event. If there's questions we didn't get to, please feel free to jot them down into the chat. You can email us, you can go to Twitter. Let us know. See what we can do about it. But please, stay connected with us. We want to keep having these moments to interact and engage with you.
We have our newsletter that you can sign up for at bitly — so that's bit.ly/KnowbilityNews.
You can follow us on all the social channels @Knowbility. And then, of course, you can always email us at Hello@Knowbility.org.
And we do have another community event coming up. This will be in December, looking at how to make the holidays accessible. So talking about some best practices in terms of, you know, gift giving, planning your events. Things from like, how to make braille note cards; when you're purchasing subscriptions for loved ones, if you're purchasing something that's going to be a digital subscription, is that website accessible; some things to consider to make sure that you know that that gift is really going to be the gift that they, they want and can fully use and enjoy. So we hope to see you in December!
And, of course, as Eric mentioned before, it is Blue Beanie Day and to celebrate, of course, you can donate to Knowbility. So just go to our webpage, Knowbility.org/donate
And again remember, today is Giving Tuesday and it's just like the, you know, cosmos has aligned for us. What better way to celebrate web accessibility and making the web more accessible for all disabilities than by giving to Knowbility on Giving Tuesday. We do this because this is something we are passionate about. You know, it's something we think about, even when we shouldn't be thinking about it, because it is something that is very important to us. So we hope you are able to give as much as you can. Don't forget to check with your employer about matching donations for today because it is Giving Tuesday. So please, again, visit us at Knowbility.org/donate and truly, any amount helps. Send it to your friends. Send it to your family. Spread that word around, let them know. Somebody was asking about how to be a good accessibility ally? This is a great way to start, by bringing that awareness and helping us spread that message and bringing forth our mission. So with that, thank you, everyone! This has been a wonderful experience and we will see you next time. Thank you!
Eric:Thank you!