 Alright, thanks for joining me guys and staying this late to join this session. I'm Sarah Chisari, I'm a UX researcher. I work with pattern flight team. We're going to present some of the accessibility work that we did for pattern flight design system. Basically, I'm going to talk about some of the research and design activities that we did for accessibility, some of the observations that we gathered. Jen is going to talk about some of the WCAT guidelines and a few demos of some of the stuff. So hopefully you will like it. Yeah, and this is the final presentation in a series of four presentations that we did today related to pattern flight. So as I said, I'm just going to go through some of the research and design activities that we did and some of the observations that we made and tell you some of the stories that we found. The first activity that we did with a few kids from Government Moreheader School. Government Moreheader School is a special school for blind and low vision students down in Raleigh. So the first activity that we did was basically we tried to bring a group of these students to the Raleigh office that we have and we had some usability testing going on in those sessions and what we did was just basically we observed those kids using our systems and applications just to understand what are their behaviours, what are their general interactions look like when they are using devices and how things look like basically. So these are the kids, some of them, as they are entering the office. And here is a student using her rail display and just to give you an example of how it looks like or how it sounds like to interact with their web through screen reader. So this is how they explain the web. So this is how they hear and interact with the web. Is there anyone in the room who understood what it said? No? Well, I thought so. But there was nothing wrong with the quality of that audiophile. It was actual speed that the students or the kids actually listen or interact with the web. So this other observation that we have and which is really interesting video, this kid is using his iPhone. The screen is off, but he is listening to his screen reader and interacting with his phone. It's just amazing just to look at how he uses his phone this way. Let's move on to the next video. It's an old picture. So this is an interesting observation that we got from the YouTube old testing. We didn't have a good picture of it, but anyways, one thing we observed was that kids with low vision, they tend to keep the devices very close to their eyes. That was really, really interesting observation that we wouldn't even... You have to be there to see them and to understand the real experience with the devices or application that we have. So from now on, we're going to just talk about some of the WCAG guidelines that we found that actually support some of these observations that we have. So the observation we made with the low vision users is they need to be able to see the contents much larger than we normally design them. So one way that they can access those contents is by holding them really close, but they also use screen magnification. The WCAG items 1.4.4 and 1.4.10 are the guidelines that correspond with this observation. So basically that means that your font sizes should be able to scale up to 200% without loss of content or functionality and also up to 400% without needing to scroll in more than one direction. So just to kind of illustrate that, we pulled together some examples of before and after. So the before has violations of those guidelines. And I'm going to zoom in and see if anyone in the audience can point out where someone with low vision who is zooming in where they might start to have issues using the UI on this page. Does anything jump out at anyone? So in this page design, it can be common for people to developers or designers to have contents that are fixed at the top or the bottom of the page and to just have a scrollable window. But as the user starts to zoom in, the contents that are fixed start to take up more real estate on that screen and then the scrollable area is much, much smaller. And so it'll make it much harder for those low vision users who zoom in onto the page to be able to use those contents. So then if we switch to the after example, you can see here that I'm able to scroll the contents of the page. But also when I start to zoom out, I still have that fixed header and fixed footer in this page. And so some of the things you can do for the low vision users are also some of the things you do to make a website more responsive for mobile devices. If you're using media queries that are based on the EM unit instead of fixed sizes like pixels. So if the media query in this case is based on 75 EMs, which means that as the font starts to scale up, then don't have that scrollable area the way I have it implemented in the larger size. So another observation that we had is coming from this kid who is 100% blind, but she's using her iPad, using screen reader, touchpad and her keyboard. So the interesting observation is that kids tend to do like interact with the web like using combination of stuff. Just because they're blind, we can't assume that they're not going to use the screen or the touchpad. So through this observation we figured that over the time those who are blind or even low vision build this mental model of the web. They do have some sense of what the structure of the web should look like or what the layout should look like. So basically they're expecting things to be and using this mental model, they would expect vertically where to tap and how to interact with the web. So really interesting observation here is a combination of input and output that the kids use and the WCAG. Yeah, so it's really important to not assume that because someone is using a screen reader that they have no concept of the arrangement of elements on the screen as this participant illustrates in this video. It's also important to not make the assumption that because someone is using a screen reader that they are blind. So this next WCAG item kind of speaks to that principle and it talks about how you have visible labels in the UI and then you can have labels that are accessible to assistive technology. And so the visible label that you see in the UI should be at the beginning of that accessible name. And like a good example of this is someone who has dyslexia and might be using a screen reader to help them consume the contents of a web page. So you can imagine that if they are interacting with those contents and they, I'll switch to Safari, and they are clicking on this link, if they're getting different information about that link, then what they see on the screen, it can be very disorienting for that user. So for this example, I'm going to demonstrate how I can use voiceover on my Mac with Safari. And most screen readers will have the ability to pull up a list of elements. So here I'm going to pull up the list of links and just point out some of the issues that we have on this page. So you can see here, and I don't know how visible the text is, but this card with the title Cherry, it has a toggle labeled Nutritional Information is the visible label. But the label that you can see that would be provided to the screen reader is Cherry Nutritional Information. And so that is breaking with that WCAG item. Whereas if we go to the example after it's been fixed, you can see, scroll to the bottom again. This was another issue in the previous example. These shouldn't be links because they don't have URLs. So I actually, in this example, they are now appropriately defined as buttons because they act on the page instead of linking you to a different section of the page. So a button in the context of a screen reader could fall under the form control category. And then there's also usually just a list of buttons as well. So here you can see all of these nutritional information buttons start with nutritional info. And this is a typo on my part. It should say nutritional information for Cherry, nutritional information for banana. So that's how you can augment these button labels to provide more context for these users. So the next sort of activity or the research activity that we did with the kids was basically going to the school and working with the kids in person and just observe them how they interact with the devices that we provide. So last time they came to Red Hat Office, but this round we went to their school and see how they use our devices, our application in their own environment. So we started this collaboration with two kids, both of them were blind. And they were using, like one of them were using Safari, the voice over and the other one was using JAWS, I guess, for some of the experiments that we gave them. So what we did was just basically we gave them some task and we observed them as they were performing this task. And while they were working with the systems that we gave them, they were just thinking out loud and they would share the experience they have. So we made some very interesting observations there as well. One of the observations that we made was about the navigation, like how they actually navigate the way. So our assumption was that because they are blind and they use a screen reader, they would just go through the web sequentially in a very linear order, like one by one, they would actually read or listen to this web in a sequential order. But that wasn't the case. Like, as Jen showed you, there is a voter or the dialogue that most of the screen reader user actually use. They pull it up and that voter or that dialogue, they can choose what type of like CSS or HTML element they want to see. So they're actually familiar with this HTML tag that you put in your code. They know what landmark is. They know, like, what should be bottomed, what should be firm. And so they have expectation of different content to be what type of the element should be. So basically use this form or this dialogue just to navigate to different sections of the web instead of just going through the web sequentially in a very linear order. Yeah. And in addition to the dialogue that lists the elements, there are also key commands that let them jump from one element to the next. So they know that they're going through all the buttons and then they could skip through all the buttons in the context of the page. But the WCAG item that is associated with that observation is link purpose. And we kind of touched on this in the previous example, but I'll just like go over that a little bit more just to call it out. And then also another WCAG item that's related to that observation is section headings. And so making sure that your heading text is descriptive and that you're using correct heading levels in your page. Because the first time a screen reader user comes to your page, they scan that heading outline to understand the basic layout and information architecture of your page. So it's really important to make sure your heading levels and your headings are defined properly. So I'll go back to Safari and back to the before example and pull up the screen reader voiceover. And so first we'll go over the headings. So you can see here, the heading level one, the first heading I come to is at the top. And then as I start to go down, wait, I never switched to the before example. Let me bring that back. So as I start to go down, it moves to the second column and then starts going through those headings. And so you can see in this page, like the visual presentation in the contents of this page do show something similar to a heading. These card titles, I would say are headings. The page title is included here in the breadcrumb, but they aren't identified as headings in the HTML. And therefore it's really hard for screen reader users to access those contents and understand what are the contents of that page. And then the other example is with links. So if we go to the links on this page, then you can see here I have three links labeled nutritional information. But as I go back and forth, you can see they aren't providing access to the same contents. So it's okay to have links with the same name if they have the same URL and they're going to the same place. But if they are providing a different URL, then you should provide additional information for screen reader users to communicate what those links actually are. And actually, as I mentioned before, these shouldn't be links because there aren't URLs that I have associated with these. These act on the card to expand to show additional information. So really they should be buttons, but the same principle applies to both links and buttons in this case. So the next observation was about how these kids actually orient themselves in a page. So for example, if they are one part of the page and all of a sudden they forget what the screen reader says, for them to figure out where they are, they try to use back and next key on their keyboard just to go back and forth just to see where they are. So very interesting observation. So for any sort of a state they are in, they need to know what was the previous stage and what was the next one. So that's how they don't understand where they are, that's how they orient themselves within the page. So back and forth has to be visible to them or to the screen reader at the same time as the current state. And so the WCAG item that corresponds with this is change on request. So basically any time you're changing the context for the user, it should be initiated by the user. I think a good way of describing this is don't teleport the user. So don't take them to some other part of the page without them realizing it. Or if they choose to go to some other part of the page and then they exit out of that to take them back to where they came from. So to illustrate that principle, I'm just going to take you to our pattern fly website where we have a list of React components. And here we have an example of a popover. So you can see here I have this button, it's going to open a popover when I hit the enter key. And now that I have opened the popover, my focus is automatically shifted to the first clickable element in that popover, which is the close button. If I were using a screen reader, it would read all of the contents in that popover because we've basically implemented this popover to be like a modal. And that's how modals work when you code them correctly. And then when I exit out of this popover by hitting the enter key, then it takes me back to that button that opened the popover. So it's really important that you don't just immediately take them to some other part of the page when they exit out of things like modals and popovers. The next round of activities that we did with the kids was a web design workshop. So this time again, we invited the kids to come to our office. But before even doing this workshop, we were invited to participate in like a job fair activity at their school. And they wanted us to bring some sort of activity to the job fair just to demonstrate how we work at Red Hat, like what we do as a UX design team, what we do at Red Hat. So for that special event before, we should just do a card sorting activity just to show them what we do and like sort of a research activity that we could think of. So for that, we created like brain labels for each card so that the kids could actually read the cards. And it seems like to be really like engaging activity for the kids and they liked it. And we thought it was a good idea just to use it as an inspiration for another workshop activity that we were hoping to plan. So we took that idea and in this next round of design workshop that we were thinking about, we started using, like we started having cards, but instead of just cards, they were like felt cards so that it would be easier just to touch and hold and move around. And we also created like brain labels for them. And the idea for this activity was just to see how kids actually visualized web pages. Like if they were the designers, how they would design a web page. So we gave them some cards and those cards we told them these are the links that you might see on your website. But we want you to arrange those cards or those links on your page in a way that you think is easy for you to use that website or just to navigate that website. So these are some of the cards we gave them. We said the main focus of the page is article and there are some elements on that. On that page we have site heading, we have a link for comments and some other stuff. So basically we gave them those cards and we gave them a board, like a felt board and we told them that's your blank page. So go ahead and just design this blank page for us. And those are some of the kids that participated in that activity. They came to the Red Hat office in Raleigh and Lex. So this is them in action. They are designing this blank page from their perspective. And what we asked them to do was basically go ahead and arrange the stuff on your blank page. And the next task for them was to tell us the order, like what's most important component or element on this page for you. So those are the numbers that you see next to the cards. So one of our main questions for this workshop was that do these kids have any visual understanding of the page? Like some of them were blind. So we had no clue whether or not they have any perception of the visual aspects of the web or the layout or structure. So a very interesting comment from this Norwegian student. She said, I visualized where the content will be instead of just thinking about content sequentially. That's an interesting comment. The next comment is coming from a low-vision student. She had a very sophisticated comment. She said, I like to visualize the end product and feel as if web design can be compared to visualizing the end structure in Minecraft before starting a design. So again, very interesting observation or comments from these kids. So these are some of the guidelines that we thought they're likely. Yeah, so those observations correspond with this guideline regarding information and relationships. And talk about the importance of using landmark rules to clearly identify the regions of the page. And if you have more than one landmark role on a page, then you should use ARIA label to differentiate the landmark elements. So to illustrate that here, I'll bring up place over again. Wrong button. And if I bring up the rotor menu, it has a menu that shows all of the landmarks on the page. So you can see here, I have typical landmarks like the banner. I have my global navigation. I have my main region. And within that, I have two navigation regions, but they aren't labeled. So as a screen reader user, I have no idea what those navigation regions are. But you can see as I shift focus that they are two distinct navigation regions. And so if I exit out and go to the after example and pull that menu up again, you can see now all of the navigation regions have a very distinct name. And these are labels that we define within the context of pattern fly that we recommend using for these different components. So our global navigation component has the ARIA label global. And the screen reader knows because it's a nav element that it is a navigation region. So the only thing we've defined for that ARIA label attribute is global. And then the next navigation region on the page is what we label as local. So when you're in the context of that page, this is navigation that's local to that page. And then within that page, I also have breadcrumb navigation. And again, the ARIA label for that is just breadcrumb because the screen reader provides the context that it is a navigation region. So as I said, one of the tasks that we gave the students was so after they laid out the cards on the page, we asked them to tell us what's ranked the order, what's the importance of these cards to you and give us the order of the cards. So when it comes to ordering these cards, which one should come first and then second and third and fourth. So an interesting comment from one of the kids was that, so we made a mistake and we created a card that has both previous and next on it. And one student said, first of all, I would separate these two. I mean, these are not the same. So they're different actions. So they have to be different buttons or links or cards. But an interesting comment from here was that I would have next first. Like I would order, basically like I would order next first and then previous. So the context of that was that the kids were reading an article. So once they got to the end of the article or the article page, naturally the next reaction would be to go next or the next action would be just to go next. So that's why they wanted to see the order to be switched. So they want to see the next first and then previous. Yeah, so that observation corresponds with these two WCAG items, Meaningful Sequence and Focus Order. And so basically it means that when you place the elements in your HTML, that those elements follow a very logical order. And that they also should match the visual order that they're presented on the screen. And so here I'm just going to stay in Chrome and show you that example I think is on this page. So as I tab through, you can see here I have a form. And this form is where I can decide what Sunday do I want to make the featured Sunday. And I can choose a different Sunday than USS Butterscotch. And then save that form with this submit button. However, there's an additional form element for that form on the page that comes after the form submit button, which is this checkbox. So that is not, that's part of the form. And so all of your form elements should come before your form submit button. So the after example here is I have my, all of my form elements are now organized so that they come before the form submit button. In this example, the sighted user who's only using a keyboard to navigate the contents of the UI, they could see this and know that this is coming after the form submit button. But for a screen reader user, they're going to assume that all the elements in that form would come before the form submit button. So it's very important that you not place form elements after the submit button. I think this was our last observation. It was again interesting comment from a kid that if there is some additional information on the page that is not the main focus of the page or the main content of the page those type of information such as comments or related articles should be hidden by default and will evolve whenever I want it. So again, very interesting because these kids, I mean they're using screen readers and they could be overloaded with a lot of information. So it's very important just to give them what actually matters to them. Just have a focus of the page and kind of hide these not very important information to them. So there wasn't really a good WCAG item that corresponded with that. But I don't know how familiar some of you are with the different main like leaders in the accessibility industry. Hayden Pickering is one of them. It's a really good site called Inclusive Components where he provides examples of different components and the things he does to make them accessible. And it was interesting and this article he had about collapsible sections, how he points out that hiding the contents allows users to not have to tab through all of those contents. They can easily skip over them if they're not interested. And that really aligned very well with the observation that this participant had made. There was one WCAG item that kind of is similar on the bypass box. And it's written that it's very specific and it corresponds with the skip to main content link. So if we go to the beginning of this page, here we have this is one of our pattern for our components. It's a skip to content link. And so it comes at the very beginning. So if I'm tabbing through the page, I can skip over the banner and the navigation and ends up right in the main region of the page so that I can start interacting with the page. And they kind of are very, the way the guideline is worded, it seems to be more specific about that. But there are also comments about just acknowledging the fact that people should be able to have easier access to different contents of the page. And so I think it's worth considering other ways that you optimize the experience for keyboard only users for skipping over contents. It's worth noting that while we've pointed out that screen reader users have all these different ways that they can access and navigate the page. The keyboard only user, they are just kind of going through all of the clickable elements one by one. So the more that you can kind of optimize the experience for them, it's worth considering. And so I just want to share some of the URLs that we were showing today. So this is the site that I had these before and after examples. There are many other examples that I didn't go through that kind of talk to different web content accessibility guidelines and how you can test for them and then the things you can do to address them. And also color contrast is one of the things that you might be interested in testing. We didn't go over that because it didn't really correspond with any of our observations. But there are some color contrast checkers that can check that for you. These are some great ones. We, in the context of pattern fly, we use the axe tooling provided by DQ to check all of our color values. So if you are using pattern fly, you're going to have colors that meet those contrast requirements. And then also just another great thing about pattern fly is we are building in a lot of the accessibility as much as we can into the components and then also working to document for the components the additional things that you need to pay attention to when you are using them. So as much as we can build for you, we're trying to, but we can't build everything into the component. So having some awareness is definitely a good thing. And then we had some extra slides in case we had time, but we are at time or time for questions. So we'll just stop now and see if anyone has questions about anything that we went over. Yeah. My recommendation would be to pay attention to the heading outline. I, just in my testing and screen readers, I haven't noticed that it provides much information if you're scanning just the list of headings. I think there are some screen readers that will provide you more of an organization based on the landmark regions that you define in the page. But I wouldn't rely on using those section elements to chunk the information in a way that's meaningful. Any other questions? Okay. We will be at the UXC booth tomorrow and Saturday if you are interested in going through some of the other before and after examples, feel free to come by. And then we also have just Cata Coda demos related to pattern fly HTML and pattern fly react components as well. So thank you very much for coming to our talk. So this concludes today's Debcom. This is great. Because this presentation is over, this is the last one. Everyone's free to leave and do as they please.