>> Sharron Rush: Well, thank you all for being here. This is Be a Digital Ally's monthly series on how to approach a practice in digital accessibility, which, of course, we think everyone should do. We’re Knowbility, a nonprofit organization based in Austin, Texas. We've really been trying to shout to the rafters about accessibility since 1998, '99. We started Knowbility and we've been advocating and training and raising awareness ever since.
Today, if you're joining us now in the Zoom, please introduce yourself in the chat—your name, organization, what you're interested in, and if there are other Be a Digital Ally or BADA topics that you'd like, please do include those in your introduction. I already told you a little bit about Knowbility. What we've done this year—and we'd love your feedback about this—is we've taken, as I was just talking to Phil about, some of the most popular and most useful episodes from AccessU and we've shortened them. Most of the classes there are 90 minutes or three hours, so we've made a shortened version and shared that recording as our monthly series, and then invite the presenters here to do live Q&A.
So today's episode is called "Accessibility 101 Plus: Core Concepts," and Tom Brunet is here with us, one of the presenters, and Phil Jenkins. Jess Lynn is not with us, but you will see her on the video. I see I did this out of order. Mark, thanks for moving the slides forward. So we're really thrilled that they're here with us. And if you've never been to AccessU, you should put it on your calendar for next year. We have a date now. We're always at St. Edward's, and next year we'll be there from May 12th through May 15th, and then you could hang out with Phil and Tom and other accessibility experts in person.
But this is the next best thing; we're gonna hear from them. Now, Mark, is there anything that I missed that I was supposed to say? I know that we have a fundraiser going on, so anytime you can go to our website and donate to our end-of-year fundraiser. It runs through December. We have a newsletter where we... wait, Phil and I were just talking about the fact that we sent one out earlier this week. The AIR kickoff is tomorrow night. We're gonna get together and match up teams and nonprofits to start the competition, our annual competition to see who can build the best website for a nonprofit organization. It's always a lot of fun and we learn a lot every year. Donate, volunteer, because we're a nonprofit organization and we can use your help. We appreciate all the community support that we've gotten through the years and that we continue to get. I think that's all the stuff I was supposed to say, and I will now get out of the way and let you hear from Tom and Phil and Jess, and then we'll stick around and we'll have live Q&A. And they are very fun to talk to, so don't miss it. Thanks for being here.
Thomas Brunet: All right. Good morning. So I'm Tom, an STSM at IBM for product accessibility and architecture. STSM stands for Senior Technical Staff Member. Also here we have Jess—a little off camera, but she'll be talking a little bit later. She's our visual design lead for IBM accessibility. Just a kind of a random comment: so this is... you know, we often describe ourselves as far as our shirts. I typically pick this one for my talks because it just happens to align with the color palette of our websites. So it has sort of like pink and purple kind of themes, and you'll see some of that, I think, in the deck.
The intended audience for this is labeled as Accessibility 101, but it's not necessarily only intended for those that are completely new to accessibility. So, I think it would be great for people new to accessibility, but I think it will also be great for those that have some familiarity with accessibility but maybe haven't gotten the foundational education on how some of this type of stuff works. So we're gonna split this into kind of five different sections. Some of them are related, some of them are a little bit different. So we're gonna talk about how do you make the case for accessibility first. We're going to talk about how UI components actually work, how the native applications work with going from components all the way to screen reader, we're going to talk about screen reader navigation, and then Jess is going to follow up with some of the design stuff.
I think I should start with... kind of the motivation for this talk was that oftentimes when we're talking to product teams or we're talking with our focals, we're talking with people that are already working in the space of accessibility. They come to us with questions that are just illustrations that there's some foundational stuff that they just don't quite understand. And this has sort of been a talk that's been mulling around in my head for, like, 20 years at this point. So there's some pieces in here that this is kind of my first stab at trying to take this approach at it, and you know, maybe this will evolve and become something more over time.
So just going to start out with just making the case for accessibility. A lot of times we're dealing with... we're starting out, how do we communicate like why we need to do this kind of thing? And so we're part of the IBM Design team now, so we often start with our products and we start out with Design Thinking. And we think, okay, everyone should be focused on their users first and foremost. What are they thinking? What are they doing? Why am I trying... what task are they trying to accomplish? It's not just like what features and functions can I throw at the application; what is a user trying to do and how should I make that work? But the key in here is that everyone should be focused on their users, but who the users are can be influenced by stakeholders. So we have to think a little bit about what our stakeholders want to do. Sorry, what's the session? Is this Accessibility 101? Okay, thank you.
So we have to think a little bit about our stakeholders in this as well as not just our user. So another aspect of this is, like I said, Design Thinking. We're thinking about empathy. So we have this little chart on the side that we graph out: what are our users saying? What are they doing? What are they feeling? What are they thinking? And we try to get our own mindset inside the mindset of our users to figure out what kind of path they're trying to accomplish. What are they doing in their day-to-day job outside of the application? What are all the different points of friction? And so this empathy is the ability to take on another's perspective to understand, feel, and possibly share and respond to their experience. And so a lot of times people in our industry look at it and say, okay, well, we need to build empathy for disabled users also.
And so we have these kind of exercises. This is actually a picture of me at my kids' elementary school STEM Fest, where we brought in some of these vision simulation goggles and color blindness, which for kids is like, "Hey, that's a cool thing." And we've done this a couple of times to just kind of give a little bit of an 'aha' moment. But the reality of this is that this builds kind of a superficial understanding of empathy. You know, understanding why simulation isn't necessarily reality. And so a lot of times we get into these mindsets and it's like, well, now I take the goggles off and then I do this thing that I couldn't do with the goggles on. They put the goggles back on and so... it's really hard to get like a full simulation of the environment this way. And so when we're talking about empathy with people to try to build our cases, we have to also communicate that as well. Yeah, you get an idea, but you don't get an idea, so you have to work with users to get the picture.
But the flip side of this is we also have to empathize with our stakeholders. Yeah, we would all love to just do this and just get paid, but that's not reality. We have to convince somebody to pay us, and so we also have to understand the needs and wants of the people that are paying for the work in the first place. You know, what are they up against? What are they trying to accomplish? And then mesh that with our users to make sure that everybody wins. Okay, so making the case for accessibility for stakeholders. One of the common things that I run into is just how we talk about accessibility causes a problem for the conversation.
If you look at Wikipedia for a definition of accessibility, it is the design of products, devices, vehicles, or environments so as to be usable by people with disabilities, which is an apt description of what accessibility is. However, I find that that mindset a little bit understates the value of accessibility as a field. You know, do only people with disabilities benefit from accessibility? No. You know, so when we focus on that aspect of accessibility, sometimes our stakeholders are like, "Oh, well, that's just a niche thing. We don't have to worry about it." So a definition I find that's a little bit better actually goes into the universal design concepts. And so in this definition, universal design is the design of buildings, products, and environments to make them accessible to people regardless of age, disability, or other factors. It addresses common barriers to participating by creating things that can be used by the maximum number of people possible. So this isn't focusing on "I'm going to design this to be used by one person," it's "I'm designing this to be used by everyone."
And so focusing on that kind of mindset shows that accessibility expertise enhances rather than restricts that user experience. This is a common graphic that we often see in a lot of our presentations: up to one in four adults in the United States have some type of disability, 27%. That's huge. But sometimes you get this in front of somebody who's a business person and they just pop in their head the 80/20 rule. And so they say, "Oh, cool. If I skip 20% of the people, I can save 80% of the work." And that's not true either. So we try to take the mindset of, like, yes, it's a requirement by 27% of the population, it's an expectation by most of your population, and it's an enhancement for everyone. So this isn't something that you're just targeting for 20%; you're trying to build this for everyone.
And just to throw that home a little bit more, what accessibility is really about is building applications to establish patterns so you have unambiguous interactions. So that when I'm interacting with an application, it always behaves the same way. And if it always behaves the same way, a screen reader knows how to operate it the same way, users know how to operate it the same way. So as long as we have established patterns across all the applications, we all know how to use it the same way. And so when a new user comes to it, they don't have to figure out, like, well, how does this button work? Do I touch it? Do I click on it? Do I swipe at it? Do I use a keyboard? It always happens the same way. So just a couple examples here, you know, these are WCAG Checkpoints 1, 3, 2 for meaning. Full sequence.
So when a user copies and pastes content out of a site and they paste it somewhere else. That, content to follow a meaningful sequence. So if the cops one place to another, that's not about a screen, reader. But you get the same behavior that a screen reader's expecting. 1, 3, 4 orientation. I don't know how many times I pulled out my phone and I've turned it, and it doesn't turn the way I want it to. I mean, that's just something that we all expect to happen. 1, 3, 5. And that's my input purpose. When you tap on your input field. You expect it to come up with the appropriate keyboard. Typing in my phone number. I don't want all the alphabet. Just want the numbers. If I pop up. My email address. I expect I have the Comms and the S. So identifying those input purposes. Helps me, just as a normal user as well. 1, 4, 3. Contrast, minimum. Low-collar contrast combinations are just difficult to read. I can't count the number of times. I looked at something, either on a screen, a billboard, whatever I was like. I just cannot read that the contrast is so bad. Keyboard users expect to be able to press tab through the fields, press, bar on the buttons, operate the menus with the arrow keys. This was a big one that we went into a product I won't say which one. And they're like, Hey, you know, we designed this thing. It's awesome. It's great. And I went in there. I was like, Okay, well. I'm a power user. I'm your main. Target audience. I can't use this thing. They're like, what do you mean? Well, I hit Tab, and it doesn't. Doesn't go through it. Take me 20 min to go through this form field. Take me 5 min to do. You just put the keyboard operation in. And they're like, Oh, crap! We did this wrong. So, sometimes bringing that. Other mindset into their. Field of understanding. Helps also build the case for accessibility.
So yeah, I mean, just 1 other note here. So I mean the semantics and patterns that. Talking about. This isn't just something that we said, Hey, like, we're gonna build a button this way. This is decades of ux pattern evolution. It's involved millions of users. It's not just our intuition. So a lot of times when we look into these user guidelines of design. That's not just something that we came up with. That's. Decades of understanding. So there. The bottom line is, you know, like we're trying to build with. And so if you have a product that's built without accessibility structure, it's just a facade. It's just going to collapse. So a lot of times we come to designs, and it's just like. That's really cool again. It. Interacts really well on the demonstration. We build it. And it's like, Well. Yeah, this thing wasn't really thought through. So doing. The but accessibility from the beginning. It forces that intentional structure and forces intentional semantics. It. Forces, those intentional experiences. So it's like. Yeah, if you write a book, and you just throw all of your thoughts on the page. Bits and pieces in there that are gonna make sense. But if there's no outline, there's no underlying structure. It's going to get boring. And so same thing happens with our user interfaces. That's sort of the. Business. Casey type section gonna move on to describing ui components. And the power of abstraction.
So is this a button. No! It just says, click me on the screen. That that's not going to do anything. It's just a button. So how do I make this thing a button. So I draw a box with a different background color. I defined a box area of the screen as a click target. I change the color on hover. I change the pointer. I. Have to have some mechanism to reach it by keyboard. I have to hook events for the keyboard. The mouse. There's a ton of stuff that goes into making that thing a button. In fact, if you look at so. Glui is a graphics. Library, Ui Toolkit, and the. The file for implementing a button is about 140 lines of code. And that's like the simplest ui components that you can think of. So why HTML became so popular was that. I could just mark that thing as a button. And abstractly indicate it, and let the browser do the. So I say, Hey, I've got, you know, open tag button. Here's my text button. It renders it puts the background, puts the borders, all the hover behaviors, all the mouse behaviors clicks. It. Makes it tabable. So this is a little screenshot from chrome. Here. But it's not really the browser. It's the user. So problems a little bit different from Firefox. It rounds the edges a little bit. Links would just links as a text-based browser for Linux. Puts little brackets around it. Still makes it tabable. And then a screen. Reader, you go through and you hear. Click me, button. So I do this thing once to just say. Things a button, and all the other behaviors get attached to that. Click me so I don't have to build the buttons for all these different environments. I just abstractly.
So what Css. Came in to do is say, Okay, well. I have this thing, but I like the way it looks. And so I want to control the visual aspects of it. And so Css. Gives me the ability to say, well, I want this thing to actually be blue. I want white text. I don't want the rounded corners. You can make things look a little bit more consistent across the visual platforms. But I'm not affecting the Semantics. So I still get to click behavior. I still get the Mouseovers. I still get. Tab behaviors. The text based browser looks exactly the same screen. Reader still comes out the same. I've said this thing is a button. And everything knows it's a button, so I can interact with it. And then gay aria, because what people would do is, they would say. Cool. I can make all these Javascript behaviors and stuff. I'm just gonna make a div. Which takes away the semantics. And then that would get rid of things so. We introduced aria to say, Ok, this div is actually a button, so I give it a roll of but. And then I still get the text, browser behaviors and screen reader, as I did before. But if I take that role off, this is why we got the. Are. In 1st place, we lose those semantics, so we still get the visual looks like a button. But it doesn't act like a button. The net of this is. All the user interface components, and when we make them accessible. Is really about defining the semantics of that thing. Whether it's a button, or an image, or. Accordion, or. Table. Most of the problems that we run into these days are somebody has. The native thing isn't working well for me. I want to build something that works. Like my own way. But then they don't match that up to some established pattern. And they don't assign the Semantics to it. And then it doesn't behave as everyone expects. And hey, it looks cool on chrome, but it doesn't work in the text. Browser. So most of what we're trying to do is make sure that we have the semantics right? So that it just works everywhere. And we don't have to think about. How's it work with a screen, reader? Well, did you make it as a button? Then the screen reader will know how to operate it.
Okay, so. So how does this work like in the big picture like. How does the screen reader actually talk to you? Just a little bit of history. So IBM. Jim Thatcher actually is a researcher out of New York. Had a colleague that was blind, and he wanted to help him work with. The creators, and so. Back in in 1,009 he built. Kind of the original actually is before 1,009. But. 1986 is when it 1st became products. They built IBM screener for us, which. The way that it worked? Was it actually read. The buffer of the characters being sent to the display. And we figure out how to read it to them. So then, in 93, there was a. Big problem coming up because OS 2 windows started coming up with these windowed operating systems. And they're like. I'm gonna lose access to the computer, because. Just reading that text isn't going to work. And so what. IBM did was they built what's called an off-screen model. And so what this did was it sort of played a game of pictionary. And so, as the computer would send draw commands out to the graphics card, it would intercept them and try to guess at what was happening there. It would look at the background and the text, and whatever. And it would say, Hey, this thing looks like you're trying to draw a button. So I'm gonna tell the user that it's a button. So it worked. But it wasn't great. So in the late 90 s. It figured out, hey, you know what we need to. All those semantics. I was talking to you about. We need to just tell the screen readers this is what I'm doing. And so what ended up happening was the creation. The Msa. Api's. So Microsoft. Accessibility, apis. And so that tried to standardize, being able to control the role's properties for just basic stuff eliminate the guesswork. We're no longer trying to play a game of pictionary, we're saying, hey, there's a button on here. There's. And so you build a tree. And be able to tab through it and interact with it. And Noah was there. And so then, about 9 years later, it got expanded to. To try to close the gaps that were left by Msa. So there were a bunch of different roles in states and properties that weren't quite there in the original, and that's tried to expand it. So that's what we use today for. Chrome Firefox Eclipse on Windows. Macos on Linux have similar. Parallel apis.
[Image showing the transformation of HTML code into a DOM tree, then into an Accessibility Tree used by Assistive Technology]
So how does this basically work from going from the accessibility tree all the way through. So I have an example up at the top here of HTML, so it's a button with a class on it, and a type so. Simple HTML, button and. And so the browser takes that, and it converts that into a tree's pars tree. You know the Div, which is a container and a button, which is child, and it has all the properties on it as well. And then the browser converts that into an accessibility model. So if you go into. The developer tools of your browser. You'll find somewhere in there. There's an accessibility section. Chrome just has an accessibility. Tab. And you'll be able to see these trees, and so you'll be able to see that it parses this thing into. Here's my main page, generic generic. Down here somewhere is a button. And then that has a bunch of states and properties with it. So there's a. A name, a button, and so you can look at all the different ways that you can name buttons from the label by. Label actual label, the contents. So in this case. Contents, a button, and then there's other. States and properties that go with that focus and so forth. This is really what the screen reader. Sees these days. When I started. IBM. 20 something years ago we had to go straight to the Dom because this didn't exist. And so this is now what screener is mostly are interacting with. So when you're trying to figure out what the problem is. Sometimes looking here. Kind of helpful, but often looking here. Gives you a better idea of what's actually going on.
To put a little bit more visual onto this, you know. So. This all happens inside the browser. Html gets converted to a dom. That gets converted to browser rendering engine. So what you see on the screen, and to. It's called an Msa. Server. So there's a little component inside the browser. That's travel. A little server. That's feeding that accessibility. Information to the users. And so the screen readers interacting with that Msa inside the application. So every accessible application has one of those little components in it. That says, Hey, here's all the stuff that I'm trying to display. Here's what it looks like. Here's all the semantics. And so then the screen reader, can feed that out. Texas Speech Engine and braille display so forth. There are a couple of tools out there that will actually. Leverage that to do testing, so it'll say. Yeah, I'm going to rob this thing. I know with all the different components are. Tell me what you want to do. Click on things, and so forth. That's the kind of how things work on the insides.
I want to say another little thing about navigation. So I've mentioned a couple of times. You have to add keyboard interaction to things, make things tabable. And so. Basically, people are introduced to accessibility. The keyboard is to use the tab key. And so in this case, click, tab, you go to Link before hit tab again. You go to tab with a tab, which is Maria. I felt. This is an example from the aria authoring practices. And hit Tab again, and you go down to link after. And so one of the. That happens. Once you teach somebody how to use. Tab is. Oh, well, in order for me to read anything I have to tap. And so they start putting in like before, and they go tab to all the tabs and tab to the content, and tab to each word. And so you're starting tabs all over the place. It's like, no, no. He understood the basic concept. But you're taking it too far. You don't want to do that. What you want to do is. Tab to the tab. Use the right arrow, right, left arrow to go between the tabs, and then we'll talk about the content in a minute. And so stealing some. Some very nice visuals that just put together. In our carbon design system. These are the kind of visuals that we. Used to try to convey keyboard interfaces. So, you know, have the 1st tab to the content. Tab out. So that's something that has. Links inside of the tab panel. This is one where you tab the tab to the panel itself, because there's nothing in it. That has that can take focus. And then some illustrations on. Navigating back and forth. So these are the kinds of things out of the design time that we're trying to convey to our developers of. This is how you interact with components in a standard way. And so do this all the time. Make everything work this way, and users will understand how to operate.
Moving on, I said. They're talking about. How do screen readers users get to the content without tabbing. And so Then we introduce item, navigation. So this is. Visual from our website, the tools page of our website. And this is sort of an item navigation view. So say, main region heading level, one tools of different phases, and so forth. There are these little braces are metadata that the screen reader will read, and then this is the. The content from the actual application. So you'll see same page Link. That's the semantics that are coming through from the screen. Reader. This launch thing is a link that goes to the same page. But people don't often understand that there's multiple reading modes. So they'll understand. Okay, this page gets converted into a text version. But I also have a heading version of this, and I have a tab version of this. And there is a region version of it and a table version of it. There's a lot of different modes. Screen readers provided the user. So if you just go through one mode you'll get a completely different. Sub view of the page. And you'll notice that. And the item mode, I'm saying, heading level, one tools. With a heading navigation, I'm saying, tools heading level one. So a lot of that is for verbosity. When I'm here. I don't know what's heading. When I'm in heading mode. I already know what the heading. So that piece of information is less important. On the content. So there's tricks that they play with. To help the user hear what they need to hear first, st so that they can. Quickly skip the rest of the content. Next one.
Okay, so. What didn't show on the previous slide is that these things all line. In item, navigation. Having level one tools as a second item. But my heading navigation. It's the 1st item. And it's not my tab focused navigation at all. And so what users are actually doing is they're jumping around between these different. Modes of navigation, so. You know, I I go down, down. Item mode. I get down to somewhere and say, Well, okay. I want to skip this section, but I want to go to the next setting, so I hit H. Jump all the content and go to the next setting. And I might tab from there. Like. Go back to the heading. After that, go to the tab. It's this dynamic thing between all these different reading modes. You're not just reading top to bottom. You're jumping the sections you jump to forms. And the more you use an application, the more you know how it's laid out. The faster it is for you to be able to go through this. Studies have shown that. 300 users tend to jump to heading first.st For getting your own pages. So we want to give gooding level navigation of how to get around pages. I mean I I've seen users that will do tricks of like. Oh, I know it's. The last like, input on the page. So I'll hit. And jump to the bottom, and then go up one. As long as you keep it consistent. People know where things are, and it's not really hard to get to. Figure it out. So that said, like, you don't want to just ignore your headings, because then they got to go. No, no, no, no, no, no! To get to the thing they want to. Want to be able to go like heading down.
And then one other bit on this, that. Is also often a little bit misunderstood is the difference between focus and point of regard. We, as visual users, are very familiar with focus. You click on something. It gets a little blue box. You tab little Boxer on the. But a screener user also has this concept of. We call it IBM point of regard. Think there's other names for it, but that's when you're going down down. Your point of regard is here. But your focus may be somewhere else when I hit Tab. It pulls both to the same place. So you can have the thing you're interacting with, which is focus. But you can be reading somewhere else. It's a lot of times dialogues. You'll jump into the thing you're interacting with. But then you'll want to go up and kind of read. What is this thing? What's the context of this. And then you'll actually start typing. So that's. That's where you get these kind of like dual reading modes. That's the technical side of this. I'm gonna pass it off to you. Just talk about design a little bit.
Jess Lin: Thank you. Yeah, I'm jess I'm the visual design lead for. I have accessibility team. And I guess before I go into the design and the process. Could I see a show of. Hands and even thumbs up on zoom. If you are a designer, we're familiar with design. Product design. Cool. Okay, yeah. So. Okay. Got some thumbs up. So what is design? Design is the part in a product development cycle where. So this I'll be talking more about how. Actually let me go back. So in a product. Team pretty much how design plays out. So our. IBM accessibility team creates. Lots of tools and guidance for a wide audience on IBM.com. But the bulk of our tools and guidance is geared towards product teams. So. Product managers, designers and developers. And why design is part of this accessibility. One is. Because we truly believe it starts with design before it gets into development. And I guess technically, it starts with the product manager. But. It would pretty much just be telling the designers and developers to do it. So the doing will start with design.
Yeah, so what is it? It's part of the product development cycle where user needs are identified. Content is created. A prototype is mapped out, and then these user-centric solutions are then. Documented and annotated for developers to implement as the design intended for it, and not leaving. For developers to kind of guess around of what it might mean. I think that's where a lot of. Confusion and miscommunication happens to where you end up with a website where. I can't talk through this page, or I can't. There's this newly designed custom component, and it has no keyboard interactions because it was. Developer had no idea that was supposed to be part of it. So we really wanted to. Start with designers and empower them and educate them on what and how they can. Incorporate accessibility in their designs. So, if you are familiar with design, you might be more familiar with. These terms of research or ux research content. And then. Ux and visual design, or ui design. And ui ux just stands for user interface and user experience. So again, because these are all user centric, we want to make sure that. We're talking about all users and not just. Cited users. Who can. And ignore users who need more of infrastructure to work with.
So, how is design related to accessibility? And the same 1, 2, 3 user needs content and prototype. Number one under user needs are identified. We have to understand and. Incorporate keyboard users in these user needs, types of disabilities. And even. Like, Tom said. It's not just empowering people who have disabilities. But if you have situational needs, if you're out in a really bright. Day, and you can't see your screen, or if your mouse ran out of battery, and you need to use your keyboard to navigate a page. And understanding the different types of assistive technology. And the main one being like a screen. Reader, how does that. Play out and understanding the fact that they even exist to begin with, can help with the designs. The number 2 content is created. So this is where you have headings, heading levels, alternative text and labels for image and icons. Providing captions and. Providing captions for images, complex images, but also providing captions and transcripts for. Videos, number 3. Prototype is mapped out. There's keyboard interaction, error, handling and color contrast. And a lot of these things, you'll see that. You might argue like, well, I feel like heading level. I feel like it's under ux. And. Like debate where things might fit in, and that's all fine and fair. I think we're just trying to create a standard. And then. You can decide among your team who will be more comfortable. What, as long as all the tasks are tackled and addressed.
So how then, do we relate accessibility to designers? I think that's. What we are working on most of the time. But we also work on other things, but we are also in the process of continuing to iterate this as well. Myself being a designer and joining the team, knowing about accessibility. I was kind of like a prime user testing feedback person. For myself. I was like trying to create. Tools and guidance in a way that I would understand it in a way that I would. Explain this to other designers. So a big problem that we have is. One. People are just designers are just unfamiliar with accessibility. Like I said before, I joined the team too. I don't. I didn't know what it meant to make my design accessible. And even understanding the why, like, when I on boarded to IBM, we had. Workshop to build empathy, and, like Tom, showed in his previous empathy slide of. Trying different goggles of what people with different range of. Can see trying out. Screen readers, and such. And I was really. Definitely, really convicted. And I was like, Wow, I. Am a terrible person. I'm a terrible designer. I did not. Incorporate, or even think about accessibility. But it was very exciting to just join the accessibility team off the bat after that, to learn. And all that to say. Problem number 2 designers don't know how to make. Accessible, and number 3. They want a way after they've tried to do all these. Tasks to check if their design is accessible.
So the solution, what we're trying to do, what we have done and are continuing to iterate on is. To address Number one. The unfamiliarity we. Are trying to explain accessibility in a simple and concise manner. English, friendly, not tech, heavy or not even like accessibility, language. Heavy, and if they don't know how to make their design accessible. We are trying to number 2, provide tools and guidance. Not just. That, but to tools and guidance that they are able to use in their workflow. Figure out where and how designers work, and then plugging it into the relevant workflow patterns.
Understanding what tools they use, and then also creating like, whether it's a plugin or... yeah, widgets in there in the direct tool itself. Number 3: they want to check if their designs are accessible. So, we have been working on whether it's visual examples of what a good design looks like—like what good and bad design as well, just to compare—and having office hours, or open calls for people to bring... a lot of times, it's more specific or it's so specific that our general guidance we can't tackle everything, but they can bring their designs and discuss with our accessibility researchers and experts of, "Am I doing this right? This is this new thing we're working with. How can we make it from start to finish, so that it is accessible as well?" So getting something like more hands-on help.
And so like I said, what we did and are continuing to improve is our... we have a design toolkit. We have a design annotation kit. We have created component-based guidance, and we've hosted and are continuing—I think there might be one going on right now—office hours and component review calls. And this is just more of a specific segue of design review calls into component levels for people maybe working on a design system and then just reviewing of what it means to make it accessible. So number one, we have the design toolkit. This is also on our platform, IBM slash able, and under what we call Equal Access Toolkit. We have a path for tools: we have planned, we have a design, develop, and even how to review. And as you're launching, again, this is more like product team, product design focused, what you can do for each phase.
And for a design, we broke it down into content, UX, visual design, and then a last tab to review, and that kind of just is a different way of viewing the content and content, UX, and visual where it just lists out, and you're just reviewing to make sure you tackled everything. And for each page, there's a short like introduction, description of what it is, how, basically, how content relates to accessibility. So it would be a lot of providing proper text and multimedia content. And then we also just have an "expand all" button right now so that you can just if people want to search through the page of specifics, they can do that.
So you'll see we have divided into... there's 3 levels. This has been a struggle as well of how we want to convey what these levels mean because they're not necessarily like Level 1, do this, and then like it's not like a step 1, step 2, step 3. It's not a linear progression, but it's more like Level 1: this is where you get the most bang for your buck. It's almost like priority levels. Level 1: if you do this, you'll get the majority of it. But you're not completely... you're not done with accessibility until you finish all of Level 3 as well. So we're working with that because some people think they just need to do Level 1. And it's also gets confusing if you're familiar with like the W-C-A-G levels, and people think it's... because it's not a one-to-one map either.
So we're working on that. But under each level is one to few words title for each accordion topic. So we have, like headings, alternative text for visuals, input labels, error messages. We want to make it really short and succinct because designers don't like to read a lot. We are not the technical side. We like a very, just brief. So after you open each accordion title, they're also laid out similarly in a template. Sort of the title, and then a paragraph of what is it, explaining it—almost like forcing designers to... who knows if they read this part? But we want they need to have some sort of learning before they understand what they need to do. So this is sort of the why. Why do we need headings? Why is this important? How does this relate to accessibility and design, vice versa?
And then we have a section of what to do, and these are usually quick bullet points as well of tasks. They could become a checklist. And then a good and bad example of what to do and what not to do. Yeah, visual examples have really helped based on our user feedback sessions. We've tested this also with a lot of users to get to the point that we are. And after that, we have a list of resources that from IBM, but also external as well, and we have a list of requirements—IBM Accessibility Requirements—that it's addressing, or if you want to read more about the requirement, you can go there.
So, yeah. And then we also have—it's almost paired with this design toolkit—is a design annotation kit. So we had started this kit in Sketch, which is one of the design tools, like prototyping tools. So there was Sketch, but now we've mostly moved to Figma. So we have it available in both, actually. So yeah, Sketch and Figma, just design tools. And so it's part of going to where designers work and plugging our tools and guidance there. So the design annotation kit is nothing crazy. It's just pre-made like heading level annotation widgets, and I know there are a lot out there that exist, too, that other people made. But it's more... it's more reminding designers, too, of like, when you look at this kit like, "Oh, yeah, I forgot to annotate the headings," or "I forgot to mark down what this and that means." So they're like little reminders there. It's not hard to make like a toolkit that says like H1, but yeah.
And then we have component-based guidance as well. So Carbon is IBM's design system, and most, I feel like, companies, especially in tech, have a design system or people working on the design system as well. So on their website, they have on their left just a whole list of all their components. There's maybe close to 40. And so we use that space as well because this is where a lot of designers and even developers come to get component-based guidance. So we and they already had an accessibility tab on there, too. So they have like usage, style, code, and accessibility. So how to use this component, what is the styling for states whichever, and help for developers, and then for accessibility.
We kind of follow a template, and we've created this template for us to follow as well. In the first paragraph, we'll state whether or not any additional designations are needed for this component, and if there are none, we'll also say that, like no design indicators are needed. But the 3 sections that will be on every page is what Carbon provides—so pretty much what's already baked into this component. We surface that to kind of celebrate what our design system has already done for Carbon. But at the same time, if you modify this component, or if you create an accordion, what did Carbon already do that you also need to make sure you're doing or not breaking when you modify it?
And then we have design recommendations for specific instances where design annotations, or a designer needs to pay attention to pretty much, that is not baked in usually because it is situation-based. And then we have the very end some developer considerations, again, since this is where both designers and developers come in. So this is kind of an example of the first section, like "what Carbon provides." We might include like keyboard interactions, we might include like labeling and names for components, but we would surface what the tab order should be like. Again, designers don't have to do anything here; it's already baked in, but it's also helping designers learn as well, like, "Oh, this is how the tab works." They might never even test this on a website, but they'll be able to see how it works, what keys are used, and so on.
And then, even for creating these visuals, we've created a template of how, when you're contributing a new component, the things that you need to look out for, and so that it's not just reliant on me or one person to create these visuals—anyone can. And so we've created, just again, maybe a kit of: these are the widgets you use to create this visual, this is the spacing that you should be looking out for, use like semicircles and straight lines. It's just a way to, as we scale, especially as a big company, to make sure we look consistent. Yeah, that's a visual design pet peeve.
So we have those, and then you'll see that we have color differences. They're not specifically pointed out because it's still in a completely different section, but we have color differences to show for off the bat that these purple annotations are different from these magenta annotations, but the function is the same. So we didn't specifically call that out, but for the magenta ones, it would be what designers have to do, and the purple ones are the ones that are baked in. But it's also specifically labeled above as well for what designers need to do.
But an example of design recommendations would be for like headings, to make sure you are annotating, marking somewhere, somehow, what the heading levels are on a page. Because Carbon accordions are not set as headings by default, so some of them they could just be text on a page. But if you want them to become headings, then you have to specifically label that as such in your designs. So like labeling what level it is, H2, heading level 2, and then a note, "include titles as headings." However you want to communicate to your developers that it should be headings.
And then I don't have visuals for these, but office hours and component review calls, again, are things that we are doing and also looking for feedback from people on the calls, too, of, "Is this working for you? What type of things do you want to see in office hours? How do you want it to be set?" And then specific component review calls, too, of working through with designers and developers who are modifying, updating, or creating new components what all accessibility considerations are needed, because it's not always easy to see on their own. And that's it for the design section. So.
Thomas Brunet: The words are often used to describe guidance when people start looking at like WCAG and everything is: "It's an encyclopedia." And so they're like, "I got this huge volume of information. I don't really care like to read every little detail about everything." And so they get into this, "I just don't want to touch it, because it's just too much."
So one of the things that—and Jess showed a little bit of this—that we put together is what's called the Equal Access Toolkit. And this is free. It's public. The reason this stuff is free is that IBM's core business isn't really accessibility services. It's something that we have to do for our products. We have to work with business partners and our customers, and they're like, "Well, what are you guys doing for accessibility?" or, "We require our vendors to meet certain requirements." And so there was always this back and forth of like, "Well, how do you get the information?" You know, we're going to make it public so everybody can access it; everybody's on the same page. So this is the same stuff that our product teams are using.
And so, you know, there's kind of a high-level overview, and as we broke it up into going from plan to design to develop to verification to launch. And so we break it up by phase. So, as Jess was kind of commenting, yeah, the actual work starts in... but there's also some planning involved, like what requirements are applicable to me, what kind of things do I need to think about from a project management perspective. So we broke those up into tabs for each kind of role. The design you'll see split it out for content designers, UX designers, visual designers, and just doing your basic review. So there's a lot of kind of role-specific guidance built in here all the way through.
A couple of resources that are pretty good as far as the semantics I was talking about: Authoring Practices has a section about patterns. So these are a lot of the... not necessarily patterns, but there's also like "button" in there. So if you're going to customize an accordion, come in here, and they will have pretty good examples and all the different keys, and what all those expected interactions are supposed to be. That's a good resource. Also off of our site, go into the Carbon Design System—that's what Jess was showing. we have all the different kind of components that we've implemented, and there's comments about style and code and accessibility.
And then one last thing I will talk about, back to toolkit of our tools. Question is, you build stuff, and how do I check that it works, or how do I do it in the first place? Requirements: this is where you'll find the design toolkits for Figma that Jess was talking about, design kit. So there's a kit for Sketch and Figma, so you can get that and use that yourself. We have a bunch of development tools that will check inside your browser, automation, so forth, CI/CD, whatnot. There's some guidance on like doing actual testing. So we call it verification test, where we start with the automated test first, then some manual stuff, and then screen reader. We find that that's kind of the easiest way to tackle it. But if you tackle all the things that you can automatically detect, that makes a screen reader a lot easier. And then some stuff about reporting.
Jess Lin: Yeah.
Mark Boyden: Okay, that's the end of the edited presentation from AccessU, and we're gonna go ahead and bring on Tom and Phil to answer some questions here. So, alright. And then where are my other... there's Tom. Why is that not... okay, so for questions, you can either put them in the Q&A, you can raise your hand if you'd like to ask them live. I've got a couple here, but and, Tom, if you want to turn on your video, I can pop you on as one of our Q&A people as well. And if anybody from the audience that would like to live, huh! Be careful out there, Tom.
Thomas Brunet: I dropped my kids off at practice, so I'm just sitting in the car.
Mark Boyden: Okay. Well, I'll start with one that's in the Q&A then, which is: "What are... do you have some suggestions on how to get buy-ins from leaders and stakeholders that don't feel that this is a priority?"
Thomas Brunet: Yeah, it's always a challenge. And that's one of the things that I addressed kind of in one of the earlier slides. It kind of depends on the person, the business, the situation. Sometimes we have to go at them with, you know, "This is the regulatory picture and the industry, what the customers are asking for," and go ahead with that approach. Sometimes it's, you know, like I said, we try to explain to them that this is something that impacts your user experience overall. And so ignoring it means that you're affecting your general user experience. And so it's something that you need to think about more realistically as far as the quality, satisfaction of users, and so forth. So it really just kind of depends on who's listening. Sometimes you have to try a couple different angles. Sometimes it depends on what industry you're in. So if you're into the financial sector, you know, they respond much more to the risk side of things. If you're in an area where risk is not an issue, then maybe it's more like the user experience side of things. So it really depends on your industry and the situation of the product and who's listening as to which angle really is gonna work. And feel free, Phil, jump in if you have other comments on top of that.
Phill Jenkins: No. Other than, you know, some of the advantages of making it accessible—besides avoiding the lawsuits or expanding the users, things like that—is that it changes the brand perception, right? So if you can then claim that, "Look, we are more accessible," so we think about our users, our customers. So it changes the perception of the brand. Leaders and stakeholders can leverage that.
Thomas Brunet: And I guess one other note. You know, sometimes we've been with organizations that maybe the leadership's not really bought in, but you know, somebody down the line actually is interested. And sometimes once they kind of start playing around with it a little bit and realize the value, that starts bubbling up. So sometimes it's top-down, sometimes it's bottom-up. I mean, there's no one-size-fits-all, unfortunately, with like how you get buy-in in a particular organization.
Phill Jenkins: Yeah, I'll echo that. And I think, generally speaking, you want both options: threat and opportunity, right?
Mark Boyden: I'd echo that, too, and I know that this is one of the biggest questions we continually get, and I would echo, too, that it's so dependent upon the situation and who you're talking to. All right. The next one I have in the Q&A says: "If I can use the Div roll, or the button, or that, or ARIA, how does one determine the best method to use? Are there better cases for one over the other? Or is there one best method?"
Thomas Brunet: Yeah, we typically, if you can use the native HTML version, that's your best bet. These days you can usually style using CSS native controls to do almost anything you needed to do. So generally, the native one's gonna give you as much as possible from it. So like, for example, if you have a button, it'll have all the click behaviors, tabs... you're not gonna have to worry that you forgot something because most of that stuff is just gonna happen for free. Once you start going to a div, then you have to make sure that you've done everything that the native control did already, and if you're not super familiar with what all those things are, chances are good you're gonna miss something. So that's why we tend to recommend, you know, if you can use HTML native elements, use HTML native elements. Now, the reason that people get away is they're trying to do something that's like so different than what the native HTML element looks like that CSS just won't hack it. A good example might be like a toggle switch. For instance, they'll use a checkbox under the covers, but visually it's like an on-off toggle switch. And so that is so different from how a checkbox looks that they just can't get it to do with CSS alone. And so in those cases, they might go to something like a div. There may be ways even to do that with CSS, but that's kind of an example that I can think about on my end that's kind of different enough that you probably have to go to divs.
Phill Jenkins: Yeah, I think your point there, Tom, is that divs let you change the semantics, not just the look and feel from the stylesheets. So something semantically has to be changed, roles and things like that.
Thomas Brunet: And then there's a couple of controls that are like combinations of patterns. Trying to think of one off the top of my head... I mean, like an accordion. I think there is a native control now that is sort of like an accordion, but it's not fully fleshed out, so there's still some issues with that. So, you know, sometimes people make an accordion that's using, say, a div that acts like a button to pop open the accordion. So there's a couple of these different scenarios that are just like you're doing something that's not quite supported the way the native control is. But even then, sometimes we're able to use CSS to get that thing to still use a button under the covers.
Mark Boyden: That's fair. I'm gonna add on just a little bit cause I remember when buttons didn't exist in the HTML space. So how does one kind of decide button or link?
Thomas Brunet: That's... we've had that debate a couple of times.
Mark Boyden: You both smile. Hmm.
Thomas Brunet: I don't know that there is a definitive answer, necessarily. However, typically what we've done is links are usually when you're going out to another page. There is the exception of jumping into a page for like an anchor, but it's usually more of like a navigation type of semantic. Whereas a button is usually something that is triggering something within the same page. Now, submit buttons are different; that's a form submission. It's sort of going to another page, but it's really performing an action first, and then the result of that action is the navigation. So there is a sort of difference between navigation-type functions and triggering widget behaviors or state changes and that sort of thing. But there are some scenarios I know we've run into that it's sort of like, "Well, is this thing a button or a link?" and sometimes it's weird enough that it doesn't necessarily matter. You just kind of pick one; you just kind of have to choose. We tend to use links more for navigation-type behaviors and buttons for more like state changes, submissions, and actions on widgets.
Phill Jenkins: Yeah, some of the usability gurus out there—Nielsen Norman, I think it is—give guidance on when to choose which. So there are strong opinions out there on the intent of a button. If you do an AI search, you see that it says, quote, "Use buttons when a user causes a change in either the backend or the frontend of the website, such as submitting a form, opening a popup, or a modal or panel. Use links when the user action doesn't affect the website at all, such as just jumping to another site."
Mark Boyden: Thank you. Last question I've got here is: do you have any suggestions on how to address the many PDFs on a website? It's not quite what you were focusing on, but how do you respond?
Phill Jenkins: I have some anecdotal personal experience working with a large financial company, and they had PDFs of their statements that a user would use to download their bank statement, right? Then they hired a company to make all those PDFs accessible, and there was a link to "Download the Accessible PDF." It turned out that all of their users clicked on the accessible PDF link. So they basically just said, "We're gonna make all our PDFs accessible, and we're gonna have one link, and we'll make everybody happy." So that's anecdotal data you can take to the bank and share that with your clients, your stakeholders, and say, "Look, large companies have found this case. Offer the accessible PDF link; they'll click on that almost a hundred percent of the time."
Does that answer your question, you think?
Mark Boyden: I don't know; it was an anonymous question, but we'll...
Phill Jenkins: Yeah, in this case, it was a... if anybody... yeah, it was a generated PDF, so it wasn't like a static annual report. Those are done once; there's only one version. Those are sometimes more typical, and maybe there's like one copy of a PDF. More and more now, though, more people have just the HTML version of the page, and then they also have a downloadable, printable version of the PDF. And so the same content is available in the accessible HTML, so downloading the PDF to print is probably not as critical to make it directly accessible if you're gonna download and print it, unless we're talking about the font size and the color contrast—things that affect printing. But if the PDF is the only version that needs to be viewed online, then you have a different use case. So you have to think about those other aspects of it.
Thomas Brunet: Yeah, PDF is a complicated animal because it was originally created to not be accessible, and then they added this accessible layer on top of it. And the side effect of that is that a lot of the generation tools do not make accessible PDFs. Yeah, you can get Acrobat Reader and pay for that and then kind of tag it up. We tend to try to stray away from PDF in general. At IBM, all of our documentation is in HTML. Even our ACRs we deliver as a standalone page; everything's in the one-page HTML file. So we personally don't have a lot of experience just because we stray away from it. But that said, I've played around with generation tools in the past. Most of them—at least last time I played with them—didn't do a very good job at it, and so there was a lot of manual work in generating PDF, going back into tagging it up. And that's gotten better, I assume, with the new AI stuff. Pretty soon, with automated tagging, at least it will make that process a little bit faster. There's still gonna have to be some sort of human involvement to review and make sure those tags are done correctly. So it is a fairly manual process every time I've looked into it.
Mark Boyden: I know there's a boutique industry around accessibility and PDFs. And then there's the aspects for people with visual disabilities who need magnification and stuff like that, and the issues related to reflow that PDF doesn't support and such. I know Knowbility supports the concept of HTML over PDF as well.
Phill Jenkins: Exactly.
Thomas Brunet: Yeah, that kind of goes to the early part of my talk. HTML is so defined around specifying the semantics of the content and letting the browser make decisions. PDF is, "Here's the visual and here's the semantics," and they're separated and not tied together in any way. So the HTML format is just much more flexible in letting the user kind of define how they want to experience that content.
Phill Jenkins: Yeah, it fundamentally goes back to: why is the PDF there? If you can get to the root cause of why it's available in PDF, you can start tackling the suggestions on how to fix it, right? Is it there because it's just been there forever? Is it there because people want a nice printed version of a thing, or whatever? And you can address it that way.
Mark Boyden: So you guys have a really nice structure set up, it appears, and good documentation. You're able to bring everybody in your teams in to follow these guidelines and stuff, but beyond that, I'm sure you guys run into a few common accessibility issues in spite of that, working with all the teams across the board. What types of things do you run into along those lines—keeping everybody, I guess, aligned with your vision?
Phill Jenkins: I think I mentioned one: the acquisitions. So when IBM acquires another company, we kind of start their journey from the beginning. You know, they have an existing thing, and they're like, "We have to migrate and make it accessible because that wasn't a requirement before." So that's an example of a challenge we find often: new company, new team, new to accessibility. How do we help them?
Thomas Brunet: Yeah, I mean one thing that's helped IBM a lot is, yeah, we showed some things and talked about the Carbon Design System. Our design team basically built an abstract definition of what the components look like, feel like, and interact with, what the patterns are, and so forth. And then they went out and implemented that abstract definition in React and Angular. And so we had a consistent behavior and look and feel across all of those. And the beauty of it is that we can address the accessibility in all these components, and so that gets adopted across the enterprise. And you know, it's open-source, so anybody who wants to use Carbon is welcome to use Carbon. Since that came out, our accessibility issues in general have cleaned up a lot. I mean, that handles all the low-level stuff, so we can focus on more of the complex problems now. So mostly what we're dealing with these days, like Phil said, there's... one second.
Phill Jenkins: While you're doing that, Tom, let me just mention another example is new technology. So AI chatbots and some of these newer—I'll call them new technologies. The Carbon Design System has just come out with new ways of identifying things that are generated by AI. They have an AI slug or an AI icon that says this content was generated by AI, and there's shading and visual markup that lets the sighted user know that it's AI-generated content. And it's also a way to make it accessible—correct contrast, etc., etc.—but for the specific purpose of identifying trusted AI content, for example.
Thomas Brunet: Yeah. So that was... there were three things I was gonna bring up already. The third one is actually old technologies. You know, we run into things where somebody's adding a new feature to maybe an old Java application, and that team doesn't have the skills anymore because it's not a common thing. And so trying to figure out how to get some of these old technologies back up and running and understanding how to configure those right—that's hard as well. So there are challenges like new patterns with AI chatbots, a scenario that we're investigating and trying to settle on, and then sometimes it's the older stuff.
Mark Boyden: Okay, gentlemen, thank you so much for being here. Thank you for the presentation. I'm gonna share a slide with our feedback survey link, and we will be sharing this recording with everyone. And again, thank you for being here. We really appreciate it.