How to Create Web Products for People with Disabilities? Le Wagon Presentation Recap

Again, honored to be with you all. Let’s talk about how do we make web products for people with disabilities. Really quick introduction for myself. I’ve been living in Tokyo for the last almost one year and a half. And I’m the CEO of a company called Equal Entry, and my company’s focus has always been helping companies get their technology to work for people with disabilities. So my whole career has been working with people with disabilities and technology. I graduated from University of North Carolina with a Bachelor of Science in Computer Science. And I was fortunate to meet Jason Morris, who is blind, while I was studying my degree. And we got to work on a project for someone who is blind that needed access to ancient world maps for his research. And so, for me

in school, this was like my first interaction meeting someone who is blind, or having someone who is blind as a friend or, you know, as someone that I could learn from and learn from their experience. And I got very excited about how technology can be used to give access to people with disabilities to information that they couldn’t have before. So, my first introduction to this idea of making information accessible was, maps are usually very visual, you’re usually supposed to use your eyes to look at a map, and so our project at this time was to use sound and touch to explore maps in an interesting way for Jason. And so that got me—you know, I got very motivated from this project, and from there, I worked for Microsoft, and then Mozilla, kind of in this topic.

And currently, as I said, I run my own company, and I consult in this area, and I love meeting new people. Coincidently, I would say, just for the topic tonight, knowing that probably many of you all are Le Wagon, either current students or past students, I would say my entire career, I’ve never been someone that was like my B.S. in computer science really mattered that much. I think my experience has always been the projects that you work on and the things that you build are what matters. And when I even look back at my degree, one of the reasons I highlight my project is, like, that’s really the main thing that got me a job at Microsoft and sort of launched my career, was working with Jason and building this project. So I definitely felt—or I do always feel like it is about finding interesting

projects. And again, aligned with that, I do run two Meetups, one that’s based in New York City. Even though I live in Tokyo, I still run a Meetup in New York City on—and monthly we have interesting topics, always in this area. And then I also run one in virtual reality, in Mozilla Hubs. And so that’s totally other topic, but does play into the web a bit. Let’s get started. This video is loading here. This is a video. I like to show this video, just before I even go into talking about accessibility; I’ve come to rely on showing this video. So this is a video from Apple’s developer—their big developer event, from, I believe, like four years ago.

So I’m just going to play the video. [VIDEO PLAYS] [MUSIC] VO: People think that having a disability is a barrier. But that’s not the way I see it. You can catch up with friends.

S1: Ready? VO: You can capture a moment with your family. Siri: One face. Small face. Focus locked. [camera shutter]

VO: And you can start the day bright and early. You can take a trip to somewhere new.

S2: Three miles to the summit. VO: You can concentrate on every word of the story. Auto: A bird began to sing. Jack opened his eyes. VO: You can take the long way home. Or edit a film, like this one. [clicking] When technology is designed for everyone, it lets anyone do what they love. [laughter] Including me. [clicking] [END VIDEO]

Logan: So, I mean, this video always makes me feel a bit emotional because, you know, I love this video from the standpoint that it’s really important when you explore this topic, one, to like, you know, really meet people with disabilities and listen to people with disabilities. But what I feel like is so important about this video from Apple is it was created by a person with a disability. So this woman, Sady, is using what’s called a switch operator, so instead of being able to type on a computer keyboard, you know, with 10 fingers, she needs to control the interface using head gestures where she clicks on mouse buttons to control—I think this is iMovie, or, you know, it’s one of the video editing software tools. And so I really love this example because

I’ve spent a long time in my career working in this space, and you will often hear people saying like, “Well, why do I need to make this accessible? Someone who’s blind isn’t going to use this.” Or, “Why do I need to care for this? You know, no one’s going to use this.” And this video really speaks to that, like I think the whole point is we all have our own interests, we all have our own passions. And so when technology is accessible, as she says at the end, you know, people can basically do what they want.

And especially when you think about careers and that being employed and having a job is, obviously, an important part of having happiness in life. People with disabilities have traditionally not had very good employment opportunities, and a lot of countries have sort of had this idea that we’re going to give people welfare or we’re not expecting people with disabilities to work—you know, they can’t work because they’re disabled. So, the whole thrust of my talk today is to show you these techniques of things that you can put into your web technologies to make sure that, you know, everyone can use your products. And when you do that, one of the standard points is, when you design for something that will work for people with disabilities, it almost always ends up being something that works better for everyone.

And so, you know, I always feel like that’s kind of a cliché to say, but I do believe it’s really true in a lot of cases, when you really put that kind of thought into what you work on. So, this is just a quick intro to the concept of disability and the concept of technology. So, generally, like, there’re many different types of disabilities. These are just sort of high-level categories. But an important thing to understand is that, many times, a person with a disability to access information, they need to use something called an assistive technology.

Most typical example—someone who is blind, they can’t see the screen; they can’t see your website. So they need to use a tool called a screen reader to read the screen, read information that’s displayed visually, convert that information into speech or text—you know, it could be Braille or it could be synthesized audio—to understand your website. So that’s an example where your website will be accessible for a person who’s blind, if your website works with their screen reader. Similarly, someone who has low vision, which would be someone that, you know, maybe even wearing glasses still has trouble reading text. There’s a technology called a screen magnifier, which allows someone to zoom the screen, enlarge text, enlarge the font. People who are deaf or hard of hearing, closed captions, which I’m sure everyone is familiar with, and a good example there for accessibility

for everyone—you know, those of us living in Japan that don’t speak the language fluently, relying on English closed captions for information that’s displayed in Japanese is something that everyone needs to do if they don’t speak the language. So this is a good example where even the closed captions are designed for people who are deaf. They have many other use cases that help lots of people. There are different types of mobility impairment.

So, Sady, that I showed you in the Apple video, she is a quadriplegic, so she doesn’t have movement of her arms or her legs. So she’s using a switch control with her head. She also doesn’t have speech, or easily understandable speech, so she can’t use speech recognition. But potentially someone whose arms are paralyzed but can use their voice or mouth, they can actually use their voice to control the computer and do everything they need with their voice and never touch a mouse or keyboard. I’ll show you examples of these.

And then the last one is cognitive. Cognitive is sort of the catch-all in accessibility right now, because there are so many different types of brain function, disability types. You know, there’s attention deficit disorder, dyslexia, Alzheimer’s, autism. There are so many different types of cognitive disabilities, so it’s hard to say there’s one assistive technology that works well for this disability type.

But one example is for people with dyslexia, being able to change the font on your website. So if your font doesn’t have a lot of spacing between the letters, that can be hard for someone with dyslexia to read. So if they can customize your website and re-render your site with a different font, that will make that easier for them to use. I just want to check. Are there any questions in the chat? Before I go into the first example.

It doesn’t look like it, but Sasha, let me know if there are any questions, if I miss something. Kaverina: Let me read the question to you. We also want people who will listen to this afterwards, who won’t have access to chat, to understand what’s going on. So the question is, I’ve heard that screen readers do read out loud the concerning gender-friendly writing, as in German we write—we say “besucher,” which is male, and—sorry, I don’t know German—“besucherin,” which is female; therefore, we write “besucher” out like I guess a little star in it [**], but I heard the star is the wrong sign and one should use something else. Do you know which one?

Thanks a lot. Logan: Interesting. Yeah, well, I love how detailed that question is. And I’m not an expert either in the German language, but I think that’s fascinating and that does come up as—so technically, and I didn’t go into this, but like, there’s different requirements for saying that your website is accessible, and a lot of times—and I come from the United States, and we have a lot of laws around accessibility, and so a lot of people, when they think about accessibility, they’re thinking, “I need to meet this law.” And usually that law maps to something called the Web Content Accessibility Guidelines. So, specifically to your question, for the Web Content Accessibility Guidelines, there’s no rules about how a screen reader pronounces certain symbols or, you know, like if you supply the text, and if your text is accurate

German, your only requirement is to make sure that the text is marked as German, because there is a requirement to tell a screen reader what language the text is being written in, because that way they know to change how they pronounce things. But if there is some kind of rule in German language or convention, the speech synthesizer should be following that. And yeah, I mean, again, we could probably take this offline, because I’d love to learn more about that. It’s definitely a very detailed question. But technically, there’s nothing you should have to do if you’re writing proper grammar in your language, to make the screen reader speak it accurately.

As long as you use text correctly in the language, then you’re doing the right thing.

Kaverina: Thank you, Thomas. I also have a question from myself following, very similar. We had a code course [**] with students recently, and the people had their nicknames, and we used Alexa to say loud the nicknames, and some people have a nickname and emoji, and Alexa had been pronouncing the name as like, for example, “Sasha, cat typing on the keyboard, sun shining brightly, and then the cocktail [**]”—something like that. It was very long. And it just brought me to the idea that probably, for the web accessibility, we should not use it much, emojis. What do you think? Logan: Yeah, I love that you brought that up, because that’s another very astute observation. This is a problem on social media especially.

Like, the one I like to call out as a funny example is, at least for a while, people liked to put the clap emoji in between every word to say, “I’m emphasizing, I’m spelling out this point that I want you to listen to.” And technically, to be accessible, the screen readers are doing a good thing, and Alexa is following what a screen reader would do. It’s basically turning the emoji into a text alternative for someone that can’t see the emoji. But exactly what you brought up, like, it makes the text really long. And in so many use cases, it’s very frustrating and annoying.

So, it’s not a very easy answer, but the screen readers now have a setting to say, “Don’t pronounce emojis.” So some people might choose to turn that setting on, especially if they’re using social media. They might say, “Like, okay, when I’m on social media, don’t read the emojis.” But maybe then for a certain tweet that they really want to know exactly what someone said, they would turn on “Read me the emojis.”

That is a hard one, though, because it’s like technically you want all the information to be there, but then the user experience is really bad if—you know, like your user experience is bad, too. It’s like that takes so much longer to listen to, the more text is in there. So, two ways to think of that. One could be like don’t overuse emojis or don’t string together the same emoji over and over, would be a good best practice. I mean, I’m old enough, too, that I don’t really like emoji in official communication as—I don’t know, though, like I’m old. So I think that is, though, interesting that maybe sometimes an emoji is being used to symbolize something else other than what it looks like visually. These are all deep questions, and it kind

of gets into a very complex part of how do you make images accessible for people that are blind. Any other questions? Kaverina: Yeah, we have another question. What is a great way to describe a picture on your website for visually impaired person?

Logan: Yeah, that’s good. So that kind of connects into the point. It’s very much context-dependent. So I was going to use Feelcycle, which is a Japanese spin class that I go to a lot, just to show some examples. But I’m happy to, if anyone in the chat—if you have a website, and you’re okay for feedback, I’m happy to open up anyone else’s website.

But let’s take this example from the Feelcycle website. We have this image, and I can’t actually read all of this Nihongo, but it’s basically marketing a new service where you’ll be able to do the class at home, at a bike, and it’s telling you, “Feel anywhere is coming.” So, on this page, the fact that there’s a guy like holding his hand up, riding a bike, and sort of like, you know, looking very enthusiastic with a microphone, it’s debatable if that needs to have a text alternative for someone who’s blind. And this is like one part that’s really confusing about the standard, is that a lot of people try to go above and beyond, to describe every single image, and it kind of becomes the emoji problem that Sasha brought up, where, like, do I really need to know

that to understand this site? Maybe, maybe not. But that’s where you—you have to put that thought into your site. It becomes way more clear when you have to do it.

Like say you were doing like a pie chart on your site, or like Le Wagon, you guys had statistics of—we had 50% female, 50% male attendees to the school; if that was a pie chart and that was a graphic on the page, that would need to have a text alternative that said, “50% female, 50% male.” And that’s one where you can be absolutely sure, yes, I need to have a text alternative because that information—if it wasn’t text on the page, I have to give that for the image. But ultimately, like when you think about describing an image, you need to think about how it’s being used. So the other example could be our Meetup page for this event. Technically, because the name of the event is “How to Create Web Products for People with Disabilities – Talk with Thomas Logan,” it’s got

the date, I think, somewhere down here. It mentions Le Wagon and Equal Entry. So, this image doesn’t really—this image was like used, right, for social media, but all the information is already on the webpage. So this is more of an advanced idea, but you basically don’t need to describe the image if the page already has the text describing everything about it. People that are blind get annoyed because it’s kind of called the “stutter effect,” because it sounds like your screen reader is stuttering and reading, like, the same information twice. And so, when you think about listening to a webpage, you want it to be all the information but as short as possible, because if you make the webpage longer to read for someone who’s blind, it’s going to basically take them like twice as long to read the page.

So, that’s the idea, and if you guys have a website you want me to pull up, I can talk to you about any images on your site. But that’s the idea.

Kaverina: I just wanted to add one thing, that Thomas made me fix the visuals for today’s event two times. [laughter] Just to let you know.

Logan: Yes. I was going to use that as an example in a little bit. Because I figured— S: [indiscernible] just for you [**]. Logan: Thank you. I feel special. Yeah. I mean, that’s part of the hard part, too, is that, a lot of times the role that I get into is, here’s all these rules for accessibility, and you know, my company—a lot of accessibility companies are like, “Here’s all the rules. I need to follow all these rules.” And like fail, fail, fail, fail, fail. And the reality is like so many websites still don’t work great for people with disabilities. So definitely, my company now, we take much more of a pragmatic approach of like try to find, you know, the biggest issues first and work on those, which is a great segue to the keyboard is where I really recommend starting for everyone on

this call. Like, any web application or website that you’re building, you need it to work with the keyboard, and just the keyboard. So you basically have to unplug your mouse or turn off your trackpad, and try to do everything on your site just using the keyboard. And it’s kind of amazing and unfortunate that most websites fail this. And so that’s why I’m like, “Start here,” where—do everything only using the keyboard. My company recommends thinking about scenarios.

Scenarios could be user journeys, user stories, taskflows. You really want to think about accessibility from the standpoint of, like, say your website has a signup or register process, and so that process is like, fill in your name, last name, email address, maybe some checkboxes about your interests. That all needs to work from the keyboard, and so we recommend like, focus on the top two or three tasks that someone needs to do on the webpage, and try to get those tasks to work fully just with the keyboard.

And then you want to ensure that focus is displayed visually. And I’ll show you an example of this. You want to make sure that anything interactive—so basically, anything you can click on with the mouse needs to be clickable or actionable from a keyboard. Do everything just using the keyboard. And then if you did need to have custom keyboard shortcuts, make sure they’re documented. So like if you’re building a web application, web applications are more likely to need to have keyboard shortcuts. So, a couple examples. Start with Feelcycle again, because I just chose—to show problems. So when you load the Feelcycle page, this is a common issue that you’ll see on a lot of websites, is there’s modal dialogs, and a lot of sites start with a modal, where, you know, they’re either trying to advertise

or get you to sign up for a newsletter or take some action first. So this is a really common problem that, like, as I’m tabbing on this page—the keyboard user can actually get to all of the controls behind the modal window, even though it’s sort of visually darkened and not supposed to be something you interact with first. You’re supposed to, like, either interact with this click button, or you’re supposed to close or click here. So, from a keyboard user, you would actually only want two tab stops on this page to start with, like close it or click here to take this action. But because I can tab through everything else on the page while it’s open, that’s really hard, right, for—that’s like not a very fair experience for someone

that has to use a keyboard, where a mouse person is like, “Oh, I’ll just click close and start there.” So, then the next part is, this is more of your standard test you would do on any webpage. You load the webpage, and then you just start tabbing. And so here, this is called a “visual focus rectangle.” So we have this blue outline that shows us that the keyboard focus is currently on the Feelcycle logo. When we hit tab, it moves it over here, next to—it’s like a black background; it’s kind of hard to see. And so this is another accessibility requirement, that if you’re really trying to design an easy-to-use site, you want this to probably be either a little thicker or have a stronger color contrast wiki thing [**] that is focused around it to make it

really stand out, for someone to see visually. And then the other problem is it’s confusing, like accessibility has this idea that focus should move logically down the page, left to right. So like, it should move tab, tab, tab, tab, tab, tab, tab, tab—it should move logically. But on this page, we can see that as we tab, it actually skips around between fields. And so that’s kind of just this common accessibility issue that can come up if you use CSS absolute positioning, or if you use a tab index property in your code.

So, an example of a site that does this pretty well is Google Maps. We can see here that as we tab, there’s like this blue outline, and we can kind of see where the keyboard focuses, and it goes logically down through each of the items on the list. I can press escape to close the menu. They have, when you press shift question mark, because they’re like a web application, they have a bunch of custom keyboard shortcuts for people that either can’t use the mouse or don’t want to use the mouse. So this is sort of a really good design pattern. It’s not an accessibility requirement, but if you’re building a web app, it’s really good to have these displays of what keyboard shortcuts work.

So that’s the keyboard. And I would say like, start there as really your first place. And if you get that all working, like the screen reader for someone who’s blind is already going to be working a lot better, and that’s why my company recommends do this first, because before you start thinking about how it works for someone that’s blind, you just need to get it working for someone only using a keyboard, because then it’ll help make the next part easier. I’m going to show you this very quick video, because it’s from NYU, but this is showing a problem for screen magnifiers. This is a very big problem. So this is someone that might—even wearing glasses, needs to really magnify the screen. This is called “horizontal scrolling,” where to read the text you have to actually move your mouse pointer around the screen.

And this is also like probably your experience on a mobile phone. If you go to a site that’s not responsive, you’re like, “Wow, this site is so hard to use. I have to keep scrolling back and forth to read the text.” So that’s kind of really important to know why responsive design is really important for the websites you build, especially now, like in 2020. It’s like we should never have to make someone scroll the viewport to get the text, like they should be able to, you know, go to like, say, 400% zoom in the browser and still fully use the website. So that’s another simple test you can do on your site, is to try to go to 400% zoom and see if the site still functions. And see, like on the Meetup.com

page, I don’t have to scroll and pan around to read text. So that’s going to be a way better experience for someone with low vision, and it’s also going to work better on a mobile phone, for someone using this site. All right. I’m going to move fast here because, wow, the time went fast. I’m going to show you speech recognition. I really like this as—the screen reader is what I’ll end with, but this is sort of understanding how you can use your voice to use a computer. And this technology currently works on Mac, iOS, Android, and PC. When I first started doing this talk, this only worked on the PC.

But within the last two to three years, this technology has become available on all the platforms. Let’s show you kind of how it works. [VIDEO PLAYS] Roman: Windows 10 has introduced a powerful new feature to the desktop experience—a personal assistant named Cortana. Cortana responds to natural commands spoken to it, while using your computer. You just say, “Hey, Cortana,” and she animates to let you know she’s listening. But Cortana has limitations.

If you combine Cortana with Windows Speech Recognition, you can now continue using your computer. You’re not limited to commands that Cortana knows. You can now navigate the web. Hey, Cortana. [beeping noise] Red pandas. [beep] Start listening. [beep] Red panda, Wikipedia. Here, I use Cortana to open the web and search for a specific prompt. In this case, I was looking for red pandas. Because Cortana doesn’t have any information on the subject, she searched the web for information. She displays a number of links, but since Cortana does not operate within Internet Explorer, I began utilizing Speech Recognition. I did this by saying, “Start listening.” Speech Recognition can listen for any name of a link you see on the page. Scroll down. Two, distribution and habitat. Show numbers, 35. Okay. I demonstrated using the “Scroll Down”

command to move the view of the Internet Explorer window. If you don’t see a link on the screen or the application doesn’t understand your voice, you can say, “Show numbers,” and everything will become numbered on the screen. Then, all you have to say is the number and the word “okay” to have Speech Recognition click that link. You can see that using Cortana and Speech Recognition together, I’m able to explore more of Windows 10 touch-free. [END VIDEO]

Logan: So, that idea of showing numbers on the screen, that is basically how this technology works on every platform now. And we kind of want to avoid someone having to say “show numbers,” and we would rather people, like, you know, if I’m on the Meetup page, I want to say, “Click Explore.” And then I don’t want to have to move my mouse or the keyboard, I just want to use my voice, say, “Click Explore.”

What becomes a problem is, like let’s say that you have a site that, like my profile photo right here. This doesn’t have a text label displayed with it. So if I was using my voice, and I wanted to click on this, what would I say? What would be my voice command to do that? And that’s where “show numbers” becomes this technique where, when they number everything on the UI, my image would be replaced with a number, like 10, and I can say, “Okay, click 10.” And then the tool could say, “Next time try saying ‘Profile.’”

And so it tries to teach you if you do have to use the “show numbers” feature. But I wanted to show you guys that example, to say that that’s one of the reasons why I think usually designs that only rely on icons—you know, like for cut, copy, paste, delete, if they don’t also have a text label on the screen, it’s going to be harder for everyone to use, but definitely harder for someone just using their voice to use, because it’s much easier with your voice just to read what text you see visually on the screen.

And then my last one, which I’m just going to show you this video and then open it up to Q&A, because maybe in the Q&A we can do some demos of the screen reader. But this is a video I made several years ago with a person who’s blind named Jeremy Hartley, and I think it’s really good just to help you get into the mindset of how someone who’s blind would be navigating your webpage. [VIDEO PLAYS] Hartley: Hi, this is Jeremy from SSB, and today we’re going to talk about how screen reader users navigate websites using heading commands.

So, if I hit my H key here, the screen reader will be notified that there are headings on this page, and it will tell me what the first heading is. I’m going to hit H here.

Auto: News Heading Level 2 link. Hartley: Ah, and there’s the news section. So, by all means, I should be able to down-arrow here and read the page as I normally would, and there should be some news articles. Auto: Link. Troops called to rescue amid Colorado floods. Hartley: Ah, there we go. Okay. So, there is a news story, and I could activate that link if I wanted, but I want to see what else is here on the headings, so I’m going to hit the H key again.

Auto: Sports Heading Level 2 link. Hartley: And then it jumped me past the news section, all the way down to the sports section, just with one keystroke. And we’ll verify where we are. Auto: Link. Follow: Furyk takes aim at historic round. Hartley: Okay. So we are actually in the sports section now. Auto: Entertainment Heading Level 2 link.

Hartley: Then I press H, and I’m now on the entertainment section. So, this is one really cool way—they’ve really designed this page to take advantage of jumping around between headings, as I mentioned before, like headlines in the newspaper. They denote sections. Rather than just making the text look big and beautiful, this actually has a purpose.

[END VIDEO] Logan: So, really the important part to take away here is that, when you’re blind—and what I liked in Jeremy’s description—you’re not usually using the tab key to navigate a webpage, you’re using a bunch of other keystrokes. For example, moving by headings, which this video is showing, is one of the most common things that someone who’s blind will do on your webpage, especially like the first time they come to your webpage. Because if you think about a webpage, this page has like, you know, 200 hyperlinks on the page, and if you had to listen to that—you know, you can’t use your eyes to visually scan it—that’s a lot of information to take in. So, it’s easier to move between these headings, you know, like Jeremy was showing, like I want to move between “Editor’s Picks,”

“News,” “Sports,” “Entertainment”—like, maybe I care about entertainment, you know, that’s what I want to read about today. So I would then start reading the page only from this section, and not have to listen to like, you know, the 200 other links that are on the page. So that’s a really important idea for screen readers, is that you do want to sort of break up your page with headings that are helpful and useful.

And one other point I like to call out in Jeremy’s language [**] is when he went to news, and he was moving to sports, in his language he said, “I’m going to move down the page to go to sports.” So that’s another important just like key concept to put in your head, is that blind people don’t typically perceive your page as being spatially laid out, like left, right, up, or down. They really are just—it’s more like a Word document from beginning to end. So, this content should come first, and as I press the down arrow, then I read this content. Keep pressing the down arrow. Then I read this content. So that’s why, you know, he said, “I’m going to move down the page to go to sports,” instead of “I’m going to move to the right and go to sports.”

Because usually that sort of idea of the spatial layout of the page isn’t something that a person who’s blind is thinking about. All right. I’m going to do two more quick demos for you, and then like I said, everything is kind of inside of the deck, so I knew there was a lot of information to cover today. I think another really easy thing that you can do on your websites is test the color combinations. And so I’ve provided a link to this tool called the Color Contrast Analyzer, and this is one of the only accessibility tools that is sort of this absolute rule—it’s like an algorithm where you use this tool to pick the color combinations you use in your website. And so this was an example, and Sasha mentioned

we worked on this back and forth. We want to, like, see if this red color works on this pink background. So we use this dropper, and we select the two color values. And then we get this contrast ratio, 5.6 to 1. So that’s the algorithm, that’s the ratio. As long as you’re getting this tool to tell you you’re passing, you’re technically accessible from how the guidelines view it. And so, really, we’re trying to get a contrast ratio—like, the lowest ratio would be the same color, right? So we’re like picking this and we’re picking this. It’s going to be a 1 to 1 contrast ratio. And then black and white, which would be the starkest, is 21 to 1. So we’re trying to make sure that every time we use color on a page, we’re getting, if it’s big text, at least a 3

to 1 ratio, and if it’s small text, like what we have in the body of the page, it’s going to be 4.5 to 1. But this is a freely available tool, and it’s a little tedious to use, but once you’ve—like, say you’re designing a site and you’re only using a certain number of color combinations, you know, once you’ve tested them once, then you can be like—put in your design specification, here’s the colors we’re going to use on the site, they’re accessible, let’s use these colors, you know, for new webpages we make on the site. And the last test is I really recommend running an automated tool. And this is—especially if you’re working now on a site; for example, let’s say you are working on a project that deals with an American company. There are

so many lawsuits happening in America now about web accessibility, and usually the first thing that people are doing is just seeing if your site passes a certain set of automated checks. So before even trying to use a screen reader, some people just use a tool, like Accessibility Insights, run—this called a FastPass. And this is actually 18 different failures that it found on the homepage for Feelcycle. And so that’s just another best practice for the developers on the call, is that accessibility can be a quite manual process, and you need to learn how to use these different assistive technologies, but this tool is basically a single download. You can run it on your page, and, you know, the goal that you’re trying to get to is to have a run—this is my webpage.

Oh, I have no failed instances. Congratulations. You’re really looking for that as sort of a starting point, to saying—this to me shows like a minimum level of accessibility commitment, and it shows that the company does have an understanding that, you know, there are certain things that just have to get set. It’s not going to, like, obviously, tell you if the alt text was good for an image, but it is going to tell you like if you missed some really obvious things. And color contrast is actually one of the things that can be checked automatically, as long as it’s not an image. So I think we had that on Feelcycle. I think they had one. They might have had one. Let me show you this one. This was like, they had these buttons for going—navigating the carousel.

Those buttons don’t have an alt attribute. So like someone that’s blind doesn’t know that this is like a back button or a forward button.

Auto: [Japanese] Auto: Web content. Application. Voiceover off. Logan: So that’s something that an automated tool can check, is like, do you have any images that are used on your page? And if they don’t have a label or a description, it can flag that as a failure and something for you to check. And with that, I’m going to just go to the Q&A section, and I’m happy to stay on and, like I said, pull up sites or show you guys anything in more detail, you’re interested in.

Kaverina: Cool. Let me read some questions then. For buttons, normally blue/green buttons are perceived as positive actions, such as “okay,” “confirm,” and red buttons are perceived as negative actions, such as “delete,” “cancel”; however, this may be difficult to use for colorblind users. Are there any other ways to handle this, aside from adding icons next to the text in the button?

Logan: Yeah. So, number one, it’s like, okay, please have text in the button, because that will actually already make you technically compliant, like as long as—say the button text said “Okay” and the button text said “Cancel,” and you made the “Okay” button blue, the “Cancel” button red. As long as the contrast is okay, it’s still technically accessible for someone colorblind because they can read the text “Okay” or “Cancel.” But if it was only using color, and like I’ve definitely seen this in sites I’ve done, like sometimes people will be like, “Click the red button. Click the green button.” That would be a clear failure.

The holy grail, like if you want to do the most, it’s like you would make one button have like a triangle shape, one button have a square shape, have different colors, use shading, use an icon. I usually give the example of speed limit signs or road navigation signs, like, you know, in America at least, like the stop sign is an octagon, the speed limit is a rectangle, the yield sign is a triangle. You know, to most effectively communicate information, the more changed attributes there are, the more that it will be perceivable.

But that can go against maybe an elegant design. And I think, I would say I could see that being a design challenge—how do you incorporate that in a nice-looking design. But that would be the thinking, like the more attributes you make different between them, like shape, color, size, the more distinguishable and perceivable it’ll be.

Kaverina: Cool, thank you. Another question. Are there any regulations in Japan for the use accessibility [**]? Logan: So, this is good. You know, I’m constantly learning, living here. So there is this JIS. JIS is the Japanese Industrial Standard. It’s a catchy name. JIS X 8341-3. So that is a standard, and Japan, like most countries that care about accessibility, they are sort of harmonizing with the W3C document. So I mentioned that at the top, that in America we have lawsuits around this, but I do have a link to this in the resources. These are the Web Content Accessibility Guidelines. The Japanese standards basically say you need to meet these guidelines. But at least my understanding for Japan, there’s no legal risk, and this is what I emphasize to people. I mean, there’s a lot of things

that America makes mistakes on, but I think it’s been really good in America that there is sort of this punitive damage if you don’t make your site accessible, because I’ve worked in this field for almost 20 years, and getting people to make the changes has become so much easier now that there’s a legal risk. And I kind of think that’s what Japan would need to push it even forward. And my experience so far in Japan has been the companies that were interested in working with me are big companies that do have a presence in the United States and Europe. They’re not actually getting pressure to make it accessible, you know, from the Japanese government. But that could change. And so, as far as I know, this is the technical standard, but it’s not enforced. That’s my understanding. Kaverina: Cool. Thank you, guys. If you have

any other questions to Thomas, feel free to ask. We still have some time left. So, I have a question to you, Thomas, from my side. What kind of companies do you usually work with? You mentioned you work with the big corporates. Do they want to become more diverse, to welcome more users on their pages? Or are those just working with the people with disabilities and they want to make it more accessible?

Logan: So, it’s the two most common use cases are—the most common use case used to be, I’m a technology company selling my product to the federal government or the state government in the United States. And so that used to be—like I would work with someone like Microsoft, their product, like SharePoint, was getting purchased to be used at like a large agency, like Department of Human Health Services or Department of Veterans Affairs. There was a legal requirement to make sure that the product met accessibility standards. So that would be like where my company would come in, is like a company like Microsoft, or lots of other companies, that were selling to the government would say, “Oh, when I was trying to sell my product, they asked me for documentation of does my site work for people with disabilities.” And a lot of times they were like—they had

no idea, right? So they were start—like 15 years ago, 10 years ago, they were like, “What does that even mean?” And then they would sort of, you know, not have any idea. Now, I mean, I would like to say—I still feel like a lot of the companies that I work with or our company works with have either experienced some legal pressure, like they’ve had some type of notice from someone with a disability, saying, “Hey, I was trying to use your site, and it doesn’t work.” That pushed them. Or they’re a big enough company that they are selling their services to other companies, and the companies that they’re selling their services to have that legal risk, where someone is saying, “You have to do it.” Technically, like a lot of the big companies

really do want to make it work for people with disabilities, and that is ultimately what’s more exciting. But other than like the Apples and Microsofts, Googles, like these really big companies that do very specific implementations, I think most people are still at this point of like, they’re catching up, they’re trying to get it going, and then hopefully they see the benefit once it’s going, that people with disabilities are using their site, supporting them, staying loyal to their brand or to their technology.

And so Apple, why I showed that video at the beginning, is probably the one that did the most work, I would say, in the last like 15 years, because they used to be perceived very, very inaccessible and didn’t work for people with disabilities. And now, what’s really cool from Apple is every time they release a new product, like the Apple TV, Apple Watch, the v1 is accessible. And that was sort of really leadership for a technology company because most companies, up until that point, would be like, “Oh, well, we’re going to release a phone, but, you know, version 1 is not going to be accessible, maybe version 2 won’t, but you know, version 3 or version 4—we’ll get to that.” And that’s really not fair and equitable. So Apple is definitely leading that, where like now, when they put

out a new product, they’re like, “We’re making it accessible in v1.” So that’s good. Kaverina: Do you often have conflicts with designer’s team? Logan: Conflicts. So, at least what’s interesting in the U.S. is that—and I came from New York City, which has like a big design agency and then development agency separation. And a lot of big companies are like, “Let me hire my dev agency, let me hire my design agency, build me a website.” That’s where a lot of the conflict came in, was that—is this the designer’s responsibility? Is this the developer’s responsibility? That’s where I saw the conflict, where the developers would say, “Well, the design didn’t tell me to add keyboard support or use these colors.”

And then the designers sometimes are like, “Well, I don’t do the code.” And a lot of the accessibility standards are really based off of code. That’s kind of a critique that a lot of designers have, is like it’s not enough with design thinking. So, I’m trying to work with several design agencies now. I’m working with one, more design, currently, on like a blogpost series about that, because I do think it’s interesting.

And yeah, I would say that’s more the conflict. I don’t usually have people saying like, “Oh, it’s ruining my design.” But I do have people saying, “Why do I have to do this? Like, shouldn’t the developer have to do this?”

Kaverina: Thank you. So you have been—so far, you’ve been working with companies in America. Have you already started to work with Japanese companies? If yes, are there any successful examples that you can show to us?

Logan: Well, the only—I can definitely hype—let me get this website. So, Makoto Ueki-san, he’s been the sort of—he’s a globally known accessibility leader, so his company, Infoaxia, worked on that JIS standard, and they do a lot of accessibility events. So he’s my business partner. We’ve done like four presentations together here in Japan.

Lots of meetings. I would say like currently, for him and I, we don’t have Japanese clients, so I mean, my goal is definitely to get that. But he does work with a lot of big-name Japanese companies. So, I would also refer people, like if you’re looking for someone here specifically in Japan, that’s my business partner. He’s great and has been working in the field like 20 years, also.

Kaverina: I just remembered how some Japanese websites have a very accessible content in terms of so many buttons, and option fields [**], you need to fill in the information, and everything is not very clear. So I’m just even afraid to think what happens in terms of the people with disabilities, how they can—able to perceive this kind of website.

Logan: Yeah, I definitely think it’s probably very difficult. One other—you made me think of something. I’m going to see if I can get this example up here. They might have already taken it off. This is kind of funny, though, like—let me think of a different—go ahead. Kaverina: Can you please mention the name of the partner again? What is his name? Logan: Yes. So it’s Infoaxia, and let me place that in the—I’ll put a link into the chat.

Kaverina: Thank you. Logan: Yeah. So, this is just another—this could come up for your work. Maybe if—depending where you’re working. One thing that’s happened with all these lawsuits for accessibility is people like freak out, and they’re like, “I don’t really want to work on this. Give me a quick fix.” So this is just one of many companies that are kind of problematic in accessibility right now. So this company gives you this button that you put on your site, and then the idea was you don’t have to do any work on your site, you just set up this button, and then this button will fix your site. You know, they have a help desk, they have some features, like changing the colors. Okay, you can like, I don’t know—they add, like here’s all the headings

on that page. It’s just a very strange solution because it doesn’t actually fix the code. And so this has been something new happening in the U.S., is like when the first round of lawsuits happened, these kind of companies got a lot of funding and started selling these one-line JavaScript solutions. And now, like people actually test it, people with disabilities go to the site, and they’re like, “Well, the site still doesn’t work for me.” And so now there’s lawsuits happening, like, no, you can’t just like, you know, put one line of JavaScript on your page and now it’s accessible. That might seem obvious to you on the call [**], but that is like a problem for accessibility right now, is because there’s been so much lawsuits, people are just like trying to get this quick fix. They don’t

necessarily have the education to do it. But this is definitely not the way to go. So if you know anyone doing that, it’s like, it’s better just to learn how to make the fixes yourself, or work with someone like me, to do that. Because it’s like everything in technology, like nothing works automatically, right? You have to dig in and do testing and do validation. Kaverina: Cool. Thank you so much, Thomas, for your detailed explanation. Guys, if you have last questions, feel free to shoot [**]. Meanwhile, I will post one more time for those who missed, I will post Thomas’s contact. You can check the first link, it’s containing all the resources that Thomas mentioned today, as I believe, some links to the tools, right? That you—

Logan: Yeah. Even ones I didn’t mention. So there’s a ton of stuff.

Kaverina: And also you can add Thomas on the social media and maybe share your website link to get roasted by Thomas in a private mode. I know that many people probably were too shy to share their websites today. Logan: Yeah.

Kaverina: Not to be embarrassed in front of that many people. [laughs]

Logan: Yeah, and I hope to like, you know, post-corona, meet people in person, and I was very happy—thank you for having me today, and I look forward to meeting you guys in the community more, Tokyo people. Kaverina: Yeah. We’ll be happy to see you back in Tokyo [**] once it slows down [**]—like the situation is over.

Logan: Yes. Kaverina: Cool. Okay. Looks like we have no questions. So it means I will wrap up this event for tonight. Thank you so much, Thomas, for joining us. Thank you for your very nice-paced [**] and detailed explanation with a lot of demos and real examples. The last question we have from Helen [**]. Is WordPress accessibility-friendly? Logan: Yes. So, great question. I use WordPress for my company website, so I made that decision five years ago. I kind of looked at all the different content management systems, and it was, I would say, the best. It still is a lot about what content do you display on the site, what’s your content production process, and a lot of the themes that come with WordPress aren’t accessible. So you just have to be careful about looking for a theme that has had sort of that web content

accessibility guideline work done on it. But there are a lot that are accessible, and I would still say WordPress and Drupal are probably two of the CMSs that have done the most for accessibility. And some of the newer ones, which there’s always newer ones—like Webflow, Squarespace—whatever else comes up, you know, they usually do have a lot of accessibility barriers in them. That’s been part of my company’s work, too, to try to like get these companies to put accessibility into the base templates that people start from. Because it’s really hard to fix a template. It’s like you kind of need to start from an accessible template is another accessibility best practice, like start from something that works and then add your content into that.

Thanks for all the nice chat, everyone. Kaverina: Thank you, everyone. Thank you so much for coming. Have a good night for those based in the Asian zone, and have a good evening for those based in Europe—in Lesotho as well, I believe that’s afternoon right now here. Thank you so much, once again, for the presentation, Thomas, and hope to see you someday. Logan: Yes.

Kaverina: In person. Bye. Logan: Bye, everyone.