 Hi, I'm Jessie Huff, and I'm the accessibility lead for Patternfly, where it has design systems for our products. Today I want to talk about not only a process for accessibility, but some key takeaways that you can use in your own work. There are many approaches to accessibility, but it's all about thinking through what our users would experience. There are two main tools we're going to talk about today, and that's the keyboard and screen reader. Keyboard users could be someone with a motor impairment who has difficulty with the fine motor movements required for using a mouse, and screen reader users could be someone who is blind or an impaired user who relies on assistive technology and can't see where to click the mouse. However, there are many different types of users that can fit into these categories and other categories. For example, someone with dyslexia might use a screen reader to help them understand the context of the page. We're also going to talk about design systems and their particular accessibility considerations, as well as the design development and testing process. So how does a user navigate to everything on a page with a keyboard? Well, there are two general considerations with keyboard accessibility, and that's going to be whether this is a native element or something custom. Native interactive elements will already be included in the tab order. These are going to be things like your links, buttons, et cetera. But if you're building something custom, you probably need to look into the expected keyboard interaction and pay more attention to focus management, as well as looking into attributes like tab index to better understand tab order. Tab is going to be the main way to navigate through a page, but some other typical interactions are going to be enter and space to initiate an action. Usually arrow keys are used within an interaction pattern. The escape is always to leave the interaction and then shift tab to go backwards on the page. There's a lot of differences between screen readers, but the May 3 are going to be NVDA, JAWS, and voiceover. Our pattern fly strategy has been to pick one and narrow in on that, as it can be difficult to satisfy all of the screen readers, but when you focus in on one, it can be a little bit easier. Our choice has been voiceover due to the availability to our team, since we're all working on MEX. But I often hear designers and developers asking for an exhaustive list of everything that we consider for a screen reader, but sometimes it's easier just to open up a screen reader. This will allow you to far more quickly understand what your issues might be. I know that it can be intimidating to open up a screen reader for the first time, but just learning the very basic commands can actually get you pretty far, and there's a lot of guides out there to help you. A site user can take a look at this page and kind of get an idea of how the information is being structured and communicated. Screen reader users have alternative ways of doing that. Screen readers are typically able to navigate by categories such as headings, links, form controls, articles, and landmarks. So it's important that we're communicating this information structure. So one does not simply select headings based on size, style, or color. It should be based on the information, architecture, and what we're trying to communicate. I want to play a quick screen reader demo for you to show you how some blind users have trained themselves to listen at extremely high speeds. The computer music is effectively able to run in the distance if the software doesn't have a user control to read the text. The computer music is also available on the screen on the screen. The information might read through the text. English is commonly spoken at around 120 to 150 words per minute, but some screen reader users have trained themselves to understand more than 450 words per minute. So what may seem like a disadvantage can sometimes be an advantage. Imagine reading your emails and half the time it normally takes you. It's also a lot harder to address the long way to address it. Accessibility is something to consider at the end of your project. It's something that has to be considered at the beginning because it affects almost every aspect of your project. But when considered in the beginning, it's much easier to devise an elegant solution than it gives to all. So let's talk about design systems and pattern fly specifically. Pattern fly is a component library that products can use to create their own products. It creates a consistent and unified design with a lot of initial functionality already built in. Our process starts with design and determining the visual and interaction expectation. Then we move to HTML where we build out the actual structure and then we pass it off to React to build out the interactions. This leaves us with two repos and offerings, HTML and core. There's more of the structure and styling and the React side that has more of the interaction built in. However, when considering accessibility and design system, there's a lot of potential complexity. This is because you can't always predict how someone will use your component. So you can build in a lot of foundational accessibility but we really have to also provide the support for flexibility and customization so that it can take these components, building blocks and then build to make accessible with it. Often we might prioritize knowingly or unknowingly users who are a lot like us. This is normal but not ideal. Conversely with accessibility, we might prioritize users on one end of the spectrum. Even though this might be done with good intentions, this isn't ideal either. Instead, no single user group should be given priority over other groups. Most users with disabilities don't want prioritization anyway. They just want equal access, the same access. This is inclusive design. Inclusive design is about recognizing that users are different and don't fit into specific groups. Users have different combinations of needs and preferences and we need to provide a solution that works well for all users regardless of whether the user is using a mouse, a touchscreen or a keyboard. So often when people think of accessibility, they just think of someone who is blind or someone with a physical impairment. There's so many situational, temporary and permanent cases that users will experience. Perhaps their user is a non-fluent speaker so having clear, concise language will really benefit them. Or maybe next month you break your arm and now using a mouse is extremely difficult. So you start using your keyboard to navigate pages. Accessibility affects more than just one user or user group. So cool, where do we start with this? Well, we start with some best practices and web standards to help us guide. Often you'll hear about an acronym POR to explain the four principles of accessibility. But truthfully these principles should be considered the four principles of usability as well. Perceivable, a user must be able to consume or perceive visually or audibly all pertinent information regardless of device or technology. Operable, it should be operable or a user must be able to interact with the site and its information. It should be understandable or the information must be clear and understandable to the user, including things like consistent navigation, patterns with logical clear and concise labels for all users. So basically nothing confusing or basic UX stuff. And it should be robust. Within limits websites should work well across platforms, browsers, and devices to account for personal choice of all users. There's a lot of overlap of accessibility considerations between designers and developers. For example, on the designer side, we have color, contrasting usage, content, copy, readability, things like your headings and page titles, links, buttons, icons, et cetera. But in between the two, we have things like layout and structure, consistency and responsiveness, the interaction patterns to be considered, but the developer might be a little more specific into the tab order and bypass blocks, more into the semantics of the HTML, the aria, the roles, et cetera. Let's start with some visual design considerations. We'll start with visual acuity or the sharpness of a user's vision. Some things that will affect this are gonna be things like text size, font, style, capitalization, size of all the elements, bleeding and different types of spacing with letters, words and margins, and also the heading of a page. But field of vision is also something that will affect the user's experience with the design and this is the area of vision people can see clearly when their eyes are in a fixed position. People generally have a field of vision of approximately 180 degrees from left to right and 100 degrees up and down. With the sharpness vision in the central five degrees and color vision in the central 20 degrees. Some types of visual field loss are typically grouped as central field loss or vision is reduced or absent in the middle of someone's vision. For real field loss or vision is limited to the central portion of the visual field, sometimes called tunnel vision or there could be other field loss where it could be in different sporadic places. Some things that will affect this are really gonna be your design layout and we're gonna take a look at an example of that. So this shows a ticket machine that has poor clarity of layout viewed with a normal vision and the same ticket machine viewed with poor peripheral vision. So if you can see with this tunnel vision they can't really see what's going on in the page very easily and it's hard to navigate. But on the second side, they redesigned this and this redesigned layout shows the same machine but an overall layout that is better for that peripheral vision loss is a lot clearer to see when you have that tunnel type vision. All right, now let's talk about color. Color is a very big one when it comes to our designs. Some two big ones are gonna be your contrast and light sensitivity and this is gonna be like your combination of colors and then also a user's perception of color and then things that are gonna affect this really your use of colors. So taking a look at this example we have a couple of different combinations of text and background and you might think just looking at this that these would pass but actually none of these combinations of colors pass. These colors can still be used in an accessible way but when they're combined in a low contrast manner it's not very accessible for a number of different users with visual impairments. Also the use of color can really affect someone's interaction with the design. As you can see there are different experiences that someone might have. We have the full color perception or no disability. We have complete red-green disability, complete green-red disability and then complete blue-yellow disability and then also complete color disability altogether. And these are gonna be important in terms of how you use color to communicate things. You should never use just color to communicate information as if someone has these situations they may not really be able to get that information. So you should always be using additional text or something else aside from just color to communicate. An example of an accessible design mockup that you could pass off to a developer is this example of a card. Note the accessible naming strategy used for this card it includes a basic formula that is easy for developers to follow. For example, edit whatever the name of the item is and this makes it a lot easier from the designer to the developer to add accessibility in. It points out the purpose, the naming, the interaction, et cetera. And also if possible, avoid hard coding names and this allows for future localization. Let's talk about some basics of accessible development. When developing, you should think through these three questions. First, is it discoverable or perceivable by all users? Basically, can you see or get to it? Can you easily navigate to it by keyboard or by a screen reader? Is it interactable? If you can get to it, how easy is it to actually use once you've focused on the element? Can you interact with the element by keyboard? For example, if it's a button, can you press enter to initiate the action? Can you use a screen reader to initiate the action? And finally, is it understandable? If the element can be found and interacted with, is it clear what this action does? If it's a button, does it have visible text that would be clear out of context of the page? If it doesn't have visible text, doesn't have it RA label or an accessible name? As you can see, this kind of follows that acronym POR that we talked about earlier. It's also really important to be understandable and usable. So the flow of information should make sense. Because screen readers navigate the page in DOM order, if you use CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to pure earlier in the page, try to physically move it earlier in the DOM. For example, if you have a floating element that may be to a mouse user, they can click on it easily. It might be all of the very bottom of the DOM POR keyboard user. So we should be considering these things when making our designs. The structure, the visual information architecture should be mapped to the various rotor menus that exist by default. So I've mentioned earlier that screen readers use these rotor menus, or they can navigate the page through different means. So we should make sure that the structure of our page kind of maps out to these different things. So there should be good headings, landmarks, links, form controls, et cetera. These should make sense. There should be descriptive, without overloading with information. So headings should convey structure and content, and it shouldn't skip levels. So a common practice is to use a single H1 for the primary headline or logo on a page. H2 is a designate major sections, and H3 is in supporting subsections. It's also important to check your links, your form controls, make sure they have the labels, et cetera. So I just mentioned labels. Well, how do you know if you need a label? The big question to ask is it understandable and clear without one? The very first step is making sure your HTML is semantic. This is gonna be incredibly important because everything builds off of semantic HTML. The question to ask is, is there visible text? Then there probably doesn't need to be an RA label. RA adds the description to screen of users. It doesn't have to reiterate or override what might already be there. So check that your RA is useful. It's important to understand that RA can only affect the semantics of an element. It has no effect on the behavior of the element. For example, when you make an element hidden to screener users with RA hidden equals true, that does not change the focus behavior for that element just the way it's announced to a screener. Remember, your RA labels are for humans. Please don't use RA label equals form control one or something like that. So to give you guys a better understanding, here's an example of some link labels. A common example I see is using something big as a link text like read more. For a set of users, they can see the correlation of the card, but out of context in a screener, this is really confusing. That's really important to have clear, concise link text that explains the context of the link or the button. For example, read more about Qtees instead of just read more. Interaction expectations. This one can be varied depending on what you are doing, but as I mentioned before, there's gonna be your main interaction patterns with a keyboard, and these are pretty standard across patterns. So depending on what you're working on, these should still be consistent. For a screener, it's gonna be a little bit different based on the screener you're using. I've included some of the quick guides to NVDA and JAWS in this slide, but really you should check WCAG and the why are you authorizing practices, and there's a bunch of other resources out there that will help you with the exacts of what to expect with what you're working on. So testing and regressions. The very first step is to validate your HTML. As I mentioned before, this is incredibly important. This is gonna be your foundation for almost all accessibility related things. So it's gonna be very important for you to start there. And you can also add accessibility automation to whatever you're building. So as you can see from this little screenshot here, this is actually our automation that we've added to our CI CD build. So every one of our PRs that goes into our code base is tested through accessibility automation. We use Axe as they have a browser extension. They also have different scripts and we've written our own script based on Axe Core. And this really helps getting a lot of the foundational issues you might see, a lot of the easy fixes. However, automation can't find and fix everything. So we really, really recommend doing manual testing with keyboard and screen reader. There's nothing that truly, truly beats being able to look out with your own eyes and see if it makes sense. You can also do some integration testing. There is Cypress that does excellent for checking your keyboard interaction. This will really, really help get that foundational keyboard accessibility. And you can also teach accessibility knowledge across the team. It should be part of the design and development process which includes everybody. So it shouldn't be just one person. It should be across the team. And I also wanna do a quick demo here for you real quick to show how we can use Axe. Like I just mentioned that we have in our build to check some of the foundational issues and then going into the keyboard accessibility, how we can go through some of those and then also test with the screen reader. So one of the number of things here, first I wanna start with dropdown. I wanna show you some of the interactions we can see with this. And I wanna start with Axe. As I've mentioned, we have this already testing our entire CI-CD build. But you can actually use this as a browser extension. So let's say I wanna narrow in on just this one example and see how my accessibility is doing with that. I have my full page version right here with just the example. And then I can click here and scan all of my page with Axe. And as you can see, there are no issues with my component. However, to show you what I look like if you did have some issues, I just have plain Google here and I scan my page. And Axe will actually show you your issues and explain them a little further. It'll break it down into where it's actually located, the source and give you a recommended solution for this. This is a really great tool to find some of the foundational small issues. But let's say I wanna take a look in different formats. So I wanna take a look from keyboard. One of the things to note as well about page accessibility is it's really awesome to have a skip to content component right here. And this will skip your keyboard navigation past all of those nav links, which is really helpful to keyboard users because it's really annoying to have to go through every single link before you get to the main content. So if I click that, now I'm already inside of the main content page without having to go through all of my navigation links. So if I wanna show you how to go ahead and test this, once I tab to my dropdown, I press enter to initiate that action. And from there, my focus is shifted into the menu and I can use arrow keys to make sure that I'm actually going through everything. And something interesting to note is actually our disabled items have focus here, which isn't always the case. Usually when you have a disabled item, you won't have focus, but based on some user feedback they got from a JAWS user, we've actually enabled this functionality based on their feedback. I'll just press the escape key and I'm out of the component. If I wanna go backwards on the page, I can use shift tab. So I'm gonna open up voiceover and I'm gonna start off by showing you guys the different headings and landmarks, form controls, the different menu items that a user can navigate by. And then I'm gonna pick a component to navigate into and show you how that might sound. Skip to content side nav group, headings menu. You are currently in a voiceover menu. This is a list of voiceover menu options. To navigate up and down the list, use the arrow keys. To choose a menu item, press return. To close the menu, press escape. Form controls menu, no items in web spots menu, tables menu, landmarks menu, articles menu, window spots menu, links menu, headings menu, heading level, heading level three, heading level three, primary toggle, drop down, menu pop up collapsed button, drop down, menu pop up expanded button, menu drop down seven items. You are currently in menu, link, menu item one of seven, action, menu item two of seven, disabled link, menu item three of seven, disabled action, menu item four of seven, horizontal splitter five of seven, separated link, menu item six of seven, separated action, menu item seven of seven. You are currently on a menu item. To choose this menu item, press Control, Option, Space. To close this menu, press Escape. Drop down, menu pop a collapsed button. Voice over off. There are a lot of resources out there that can help you when you're considering accessibility. We have our own accessibility guide, but there are also lots of resources online. We should always check if there's an established practice, which is going to be through WCAG. But if you can't find a thing firm, there's often articles documenting others who've done it before. However, you should still try and test when you're building, just because your following good pattern doesn't always mean that your specific implementation is accessible. And if there is a firm standard of practice that you can find, definitely test across use cases and platforms through a keyboard and one or more screw knitters. If you're stuck, ask for help. There are a ton of forums and communities out there that help each other with accessibility. One of my favorites is the Web Alley Slack channel, where a lot of professionals from all disciplines help each other with accessibility. So let's build something cool and accessible because friends don't let friends shift in the accessible code. Thank you to everyone who's helped and contributed to this presentation. And thank you to the pattern flight team for all of their accessibility efforts.