 Yeah, can you hear me okay? Hello Thanks for being here. So we're going to talk about the missed implying accessibility today Sarah shizari. I'm UX researcher and we have Jen here. She's a senior Interaction designer. We're going to talk about how to build UI component for screen reader users So I want you to close your eyes for a few seconds I promise I'm not gonna play any magic or anything but close your eyes for a few seconds and Imagine that you are going to browse the web while your eyes are closed It might sound terrifying, but You will have a torch the torch will light up a small piece of this face for you as you're browsing the web so Imagine that situation and this is that situation that I'm describing is how blind users are actually using the web So now you can open your eyes and imagine you are developing the content of the web for those types of people The context is a dark space. No one can see the screen that you are developing They can't actually see the whole page or anything They can they're only able to see a small piece of your screen at a time if they are using a screen readers So how would you design or develop something for that context? So we're gonna walk you through how we did it how we did with the pattern fly team at Red Hat the UX design team so The analogy here is that the web for blind users is a is a huge dark massive space And that has huge amount of information for people who are blinds to use it They have to have this torch called the screen readers that will allow them to light up a small piece of space at a time So again, we will walk you through to tell you how we did it So another activity for you guys So can you guys by shows of hand can you tell me who in the audience can read the information on the screen? Is there anyone no one so honestly you guys all see this on the screen You know, there's information up there, but it's still not accessible to you and the point I'm trying to Make here is that accessibility is more than designing for disability because at this point You guys are a hundred percent able to see the information. You know the information is up there But it's not accessible So the only reason you can't actually access it is because you're not familiar with the language So accessibility and designing for accessibility is a lot more than designing for disability We have to think about usability and understanding users needs and their capabilities So this is the actual definition of accessibility designing Accessibility is designing for usability for the people with the widest range of capabilities So why should you care? Actually, it's the law out there that if you are dealing with government education and non-profit organization There is a standard level of accessibility that you have to meet so if those customers are important to you you definitely have to meet some levels of accessibility and Also good accessibility is good usability. So Usability and accessibility there are not synonyms. There are different words that have different meanings But in order for you to have a great usability of product you definitely have to include great accessibility and if you are Including accessibility in your design is not going to be you're not going to be targeting a small portion of users out there Because if you have a good accessibility of products, it's going to benefit a large population out there For example in this picture if you have a a ramp for wheelchair this guy didn't have to carry the Bicycle with him. So again accessibility is good usability and when you're designing in like products or Application you have to bear in mind that you're going to use this product in the future your abilities your Needs your capabilities going to change over the time So definitely have this in your mind when you're designing you're designing for the future you and The more you wait to address accessibility of your product It's going to be tougher and harder for you to do it because accessibility is going to affect All aspects of your design so the earlier do you and earlier you plan to include accessibility the easier to belt and And if you test early in the process is much easier to belt and it's going to be much nicer at the end So when you're designing for accessibility try not to prioritize one group of users over the other ones and try not to Deprioritize one small group of users because when it comes to accessibility really doesn't matter How big those population group is so imagine your own company if there is hundred thousand employees in your company And there's only one wheelchair user. You definitely have to have a ramp for that one user So think about that when you're designing a web accessibility Because well, if there's only one user out there that needs accessibility Web technology you definitely have to give them that chance so accessibility and inclusive design always go hand-in-hand and Definitely want to make sure you design something that meets everyone's needs and capabilities and you come up with one common solution that That works for everyone. I Love this code. It says we are all just temporarily abled so basically when you're designing for accessibility You're not again designing for one small population because we at some point in life We will have some sort of disabilities that we will benefit from the accessibility Features that we have developed so talking about different users We already talked about different types of users. We have out J But on top of that we have different devices and those different different devices Require different inputs and they have different types of outputs So there is a huge combination of a combination of preferences and users out there we have large different users and different preferences to using and to use those products and Again to be honest It's not easy and it's not gonna be doable to design personalize or customize Experience for each of those preferences. So at the end of the day, we have to come up with one solution that works for everyone Well, as I said when it comes to accessibility number doesn't really matter if there's only one person who needs accessibility Technology we have to provide it but just to put you in the context and say how how Significant that requirement is we have one five point billion users out there that have some sort of disabilities and That's That is 20% of the world's population Today's presentation is gonna be about users who have some sort of visual impairments and developing things that is Usable for them. So just to put you in the context. There are 256 million visually impaired people out there who are using the internet and out of those 200 something million there are 36 million people that are 100% blind and sightless meaning that they don't they can't even see anything that you develop on the web so Little bit about who are these people? So Norwegian people they rely on tags Audio and haptic data and they benefit so much from this manic HTML information architecture and all cons contents and controls available as tags They have this superpower that many sighted people don't have they're able to listen and understand screen readers in very high speed and Just to show you an example of how Like this superpower sounds like I'm gonna play something from the screen reader I'm just I want you to listen and try to understand how what what it means and what it says so Go ahead and give it a listen Is there anyone in the room who understood a word more than a word? So yes, this is the superpower. They have they have this Incredible talent of understanding this audio. There was nothing wrong about the quality of this audio It was hundred percent of high quality of the recorded of a screen reader So they're able to understand this in even higher speed So when you're designing for accessibility you have to bear in mind that although they don't have the visual Abilities, but they are able to do something else that we are not familiar with it also when talking about low vision people and they rely on contrast font size and audio a lot and This group of participants or users are brought in a broader range than the no vision people They have the ability to use the screen readers and also all sort of other assistive technologies Such as this one that you see on the screen So at at Red Hat with pattern fly team we we started accessibility effort and To understand if the if the components and whatever we are developing is usable for these users we decided to go to the actual users and See things from their perspectives do want we wanted to observe how they interact without products and whatever we developed So we decided to work with this this school that There's a school called governor more head of school down in Raleigh. It's actually it's black sheep it's a black ship a school for blind and We started working with them to make sure To test our products and see how how they perceive how they interact with the products This is a picture of the students as we've worked with we started working There are like 10 to 10 to 12 students. They're junior high school Students and we started working with them since November 2017 We did a couple of activities with them the one that we want to talk about is the co-design and development and Testings that we did with them every week. So we went to school to work with two Norwegian students and we had a we had one designer one developer and work one research in the sessions and What we did was to test various Implementation of the components that we had we gave them the component we gave them tasks and we observed them How how they interact with the system and we heard them out as they were working with the system to see the Expectation and the preferences we went for the preferences using the device and the screen readers There was one student who was very comfortable with Jaws Which is one of the screen readers that is out there and she used Windows Laptop and we had another student who use iPad and she has voice over there So as they were working with the system we Observe them how they interact how what they hear from the screen readers How they react to what they expect and what they prefer So these were the questions that we were trying to figure out as we were working with them So what we learned from them I'm gonna just tell you high-level findings of what we learned and Jen gonna talk you through the technical finding of of the of their interaction with the web components So one thing we learned is that cited keyword only users are not equal to no vision screen reader users, which is Misunderstanding out there keyboard accessibility does not equal a screen reader accessibility So again if you are testing your product for accessibility You can't actually just rely with rely on keyboard accessibility You have to definitely test it with the people who actually use a screen reader and then complying with the Accessibility standard is not enough. I know there are accessibility guidelines out there. It's good to follow them but You definitely still have to test it because complying with them wouldn't give you the best experience out there We observe some some some situations that whatever Whatever presented to the students wasn't something that we expected to get from So definitely we have to test to make sure everything is working just fine And then the components that we develop is gonna be affected and influenced by various technical issues Such as devices browsers screen readers and the moods of the screen readers that the users actually using and In a design workshop that we did with the students. We observed something very interesting the students there were mostly no vision there were some of them who had some low vision but It's still they did have some understanding of the visual aspects of the web, which was very interesting to us just to figure out And I'm gonna leave you to read that code from one of the participants events you was designing a web page for us and I will ask Jen to take over and talk about the technical findings Thank you, Sarah And then can you guys hear me? Okay, it's my microphone on close enough the first session We had with our screen reader participants was to have them teach us how they use a screen reader to navigate a web page As part of this activity we learned that the same general methods are available in most of the screen readers They are different in terms of the exact key commands you would use and the results that get announced by each screen reader But we also noticed that Jaws provides the most full-featured robust Experience of all the screen readers So for all the examples we show on this page on all the remaining slides It's based on the Jaws inputs in the out and outputs So the first method they shared with us is how they go from The item that they're currently on and shift focus to the next item using the up-down arrow keys So it'll shift focus from the current element to the next element in the DOM when they hit the down arrow key Another way of navigating through the web page is by using a specific key command to navigate to a specific type of element So in Jaws the user can hit the H key and it'll go to the next heading on the page or tab for links B for buttons or F for form elements Buttons are also considered form elements and in Jaws There's so many different types of elements that you can navigate by that This is just one of the the common sets of elements that these users would navigate by Also most screen readers provide the ability to open a dialogue that will list a specific type of elements So similar to the previous method the user can Enter a key command to open a dialogue that lists all the headings on the page for example So without changing their focus on the page they can easily scan all of the headings that are on the page to Get a sense of the structure of the page and figure out where they need to go in that page to figure out what they're trying to do So if it's the first time that they're visiting a site the heading structure is very important They will scan the headings as shown here to understand Where they need to go to complete their task and to get familiar with that page the same way that you would visually scan a page layout to understand the organization of that page But if it's a site that they're already familiar with and they know what type of element they're looking for whether it's a form Element or a button and so they will pull up a dialogue that lists that type of element or use the specific key commands To navigate to that type of element. So to illustrate these methods I'm going to share with you what Jaws announces for the sample HTML shown here So this HTML would show as this example on the left on the screen You can see that there are a couple of headings. There's a bullet list of links and a paragraph When the Jaws user hits the down arrow key Jaws will announce heading level one accessibility guide Then hitting down arrow again would announce list two items because the next item in the dome is the unordered list Then when they hit the down arrow up key again It announces both the list and the link as bullets same page link understanding users needs and Then the next bullet same page link checklist and Then hitting down again would announce list in because they've come to the end of that list If the user is using the H key to navigate by headings It reverses the order So now it announces the name of that heading first accessibility guide because they know that they're on a heading and then it announces heading level one and Then the second time they hit the each key. It'll say understanding users needs heading level two So these users as Sarah demonstrated they can listen pretty fast So they'll run through pretty quickly Using the the keys to scan the contents of the page the same way that you just visually glance at it to understand the structure And then here again is an example of the heading list dialogue showing the headings that are in the sample html So as I mentioned before there are so many key commands available for almost any type of element that you can think of I'm just going to take you through the links as an example You would hit the tab key and it would take you to the first link on the page in this this case The context that it is of a list item is no longer provided because it's just skipping straight to the links And then here's an example of the links listed dialogue for those links as they would display on the page So hopefully these methods illustrate the importance of providing a name that is meaningful because often when the screen reader user is Navigating a page these elements are pulled out of context So you've all always heard that using a link name that says click here is really bad And this is why because when they pull up that list of links dialogue Having a bunch of links that say click here. They have no way of knowing what those links actually do Another thing to point out though is that even if you provide a meaningful name It's important to check that if all of these links show up somewhere on the page They should also have the same URL if they happen to have different URLs But the same name then that's going to be a major usability issue for your screen reader user Another thing that these methods illustrate is the importance of having a heading outline that proper clarifies the structure of your page Contents so in the same example on the right You can see that it's pretty easy to glance at those contents and understand the structure of the page You can easily find the title you can see the sections in the content and in the page But if you remove remove those styles so that everything looks the same It's much harder to glance at this example on the left and Understand where you would need to go to find the contents you're looking for and so providing the heading outline in a way that's Semantic and and properly identifies the heading levels And also using things like lists to properly define list items makes it much easier for the screen reader users to understand Where to go to find the contents that they're looking for? The remaining sessions we had with participants was to review components that we were implementing for pattern fly Two of the components we were reviewed with them were a button menu and a navigation menu We decided to start off with the button menu because we wanted to start with something that was fairly simple and basic Because this was the first time we were doing any kind of activity like this with the participants So we weren't really sure how it would go and we also decided to use What we call the kebab menu because that icon looks like meat chunks on a stick So with the button menu we were interested in understanding how the screen reader user interacts with the toggle and the menu But we were also interested in understanding how the screen reader Perceives the label on that button when we use an icon instead of text for the button So our implementation consisted of a button that included an SVG icon and Then a div that had links for the menu items We instead of testing two Variations of this menu because in our first test we noticed an issue with a voiceover So our first variation had both aria has pop-up set to true and then also included aria expanded Set to false when the menu is hidden And then such a true when the menu is visible We later realized that the issue with aria has spent has pop-up Was more of an issue with the participant having an older version of voice of of the iOS on her iPad And that version of voiceover did not support aria has pop-up but we had also learned with that first variation that Using just displayed none to hide the menu from screen readers resulted in some weird behavior with Jaws So in our second variation we ended up using the hidden attribute to hide the menu both visually and from the screen reader and We removed aria has pop-up because we wanted to test if there were different results when we only had aria had aria expanded and So again when the menu is visible we remove that hidden attribute and aria expanded changes to true Both variations had aria hidden set to true for the SVG icon to hide that Element from the screen reader because in our case we were providing that meaningful name in the form of aria label on the Button element itself, and we labeled it more actions So we noticed when we were testing this that the variation that had both aria has pop-up and aria Expanded and Jaws gets announced as more actions button menu And this is regardless of what state the menu is in the aria expanded attribute gets completely ignored in this case But in our variation that had just aria expanded Jaws would announce it as more actions button Collapsed when the menu is hidden and more action more actions button expanded when the menu is visible When we reviewed these variations with our participants the feedback we got from them was that either Variation provided them with the information. They needed to know that there was something they could do on that toggle to get Something else they both provided cues to the user that they could toggle to get more and Also in further reviewing the w3c recommendations for aria has pop-up We learned that there is an expectation on what role you assign To the pop-up that displays for the element that has that attribute So it expects one of these five roles menu list box tree grid or dialogue So in our example with aria has pop-up We should have used role menu for the menu the div that was the menu and the role menu item for the children links in that menu Another thing we learned was how to properly hide elements So we already know that display none will visually hide elements on a screen But we learned that you should not rely on that to hide elements from a screen reader We also knew that aria hidden would hide elements from a screen reader and does not hide elements on a screen But we realized that hidden is the most effective way if you want to hide elements both from a screen reader and on the screen So essentially using the hidden attribute is the equivalent of using both display none and are hidden such a true If you are going to use display none you should couple it with aria hidden Or you can just use the hidden attribute instead and then cases where you would use the aria hidden attribute are cases like where we had the SVG icon we wanted to hide that from the screen reader because we were applying the label to the parent element instead Also decorative elements you can visually hide you can hide them from the screen reader using aria hidden The next component we tested was navigation a similar interaction pattern to our button menu You have toggles in this menu that can show and hide a show and hide a sub menu Those toggles are also mixed up with elements that are just links on the page So in this case you can see DeLore is a link to another page But Ibsen is a toggle that displays another menu The first question we had was what button what what role should we use for those menu items in our navigation menu? Should it be a button a link or a menu item? we had learned when During our first session with participants how they use the links list dialogue to pull up elements on the page and We decided that it was important to have all of those elements in the navigation menu to be listed together in the same dialogue and So that meant if we were to use a button role on the toggle Then it would not list be listed along with the other links in the navigation menu Also, if we were to use menu for the sub menu Then we would have to use the role menu item for those links instead of the link role And those items also would not be listed in the links list dialogue All in the items with the role link would show up in the links list dialogue We knew in and using a link role for those toggles that we are breaking with standard practice Where you should only use links for the elements that are actually links and have a url value But in this case We decided it would provide a better user experience for our users to use a link to toggle the sub menu instead of a button And then the other question we had to decide when we were implementing a test page for this was Do we use aria has pop-up or aria expanded? We had learned in our previous session that either attribute will communicate to the user that they can click to get something more But we had also learned that aria has pop-up has expectations about what role you apply to that thing that displays In our case we would be using menu And if we were using a menu we would have to use menu item for the links And we'd already decided that we wanted to use the role link So that meant we were using aria expanded in our case So in our test page for navigation, we had a nav element with an unordered list of links and Then the sub menu also was an unordered list of links inside of a section element Inside of the list item that includes the toggle that displays that sub menu We also included a heading inside the sub menu that had the same text as the toggle that displayed that sub menu And then like with the one variation I shared of the button menu We used aria expanded and the hidden attribute on them the menu so our participants had no issues with using the role link on those toggles they understood that when that element received focus and it announced that it was expanded or collapsed They knew that there was a sub menu and whether it was visible or not So in this case you can see the menu is visible and aria expanded is set to true the other thing that we learned During previous conversations with them and reviewing the button menu was that when they toggle the element To display the menu. They expected focus to automatically shift to the first menu item So when we built our test page, we had focus automatically shipped to the first menu item and that sub menu and our participants didn't experience any issues with this When our jaws user toggled that link for science Jaws announced that it was the environmental science link and it also announced the label that we gave the section element That contains that sub menu But we also noticed when the participant used the links list dialogue instead to activate that toggle It would still shift focus to that first menu item, but nothing was announced Our participant overcame this issue by shifting focus forward and shifting focus backward The same way that you would kind of feel around when you're in a dark room to figure out where you are To get a con get a sense of the context of where she was on the screen But there is a web content accessibility guideline that states that there should be no changes in focus that are not controlled by the user So if we were to provide if we were to follow this principle But that means that focus should stay on the toggle itself and not automatically shift focus to the first menu item and This is an in line with inclusive design because if we were to automatically shift focus For the user thinking that we're optimizing that experience for the user We run the risk of potentially making it very challenging for other users So we decided it was better to be conservative and keep focus on the toggle rather than Automatically shift focus and run the risk of some users being really confused and disoriented by that Another question we had though was what should happen when the user moves forward? They're in the sub menu. They exit the sub menu. Does it stay open? Does it automatically collapse? Adobe has an example of an accessible mega menu where they handle this flow very nicely And I highly recommend that you Google this example and just play around with it and see how they show and hide the Some menus as you just use your tab key tab through the the elements the links in that menu So we had headings in our submenu the feedback that we received from one of her participants was that it was helpful to have the Heading as I had shared with you before there are key commands that let you navigate to specific types of elements So when she was in a sub menu if she forgot what sub menu she was in She would just use the shift H key commands to shift focus to the heading in that sub menu because she had learned and Using that menu that there was a heading Our aria current its purpose is to announce which link is the current page. So in this example If you navigate to the home page and then you shift focus to that link Jaws will say home current link and our participants understood what that meant They knew that that meant that that was the page. They were currently on And then there are many examples that use aria control this type of interaction pattern But we found in our tests that this attribute is really verbose and pointless for this use case So with aria controls you provided the id value of the element being controlled in this case the section With the id not bar submenu 3 is being controlled by the link that is a toggle and so when This link receives focus The section is hidden so Jaws completely ignores that attribute because as far as Jaws knows that element doesn't exist on the page And then once the menu is visible if you were to place focus on that toggle It will announce the element that it controls and then it provides a key command that the user can use to jump to That menu item, but in our implementation the menu is the very next item in the DOM that first menu item is going to be the next element to receive focus by the user and that is the interaction pattern that these users expect that when they if they have Focus on the science toggle link and they move down They expect focus to immediately go to the science menu and that down arrow key is much easier and simpler for them to use then the key command the Jaws and provides for Jumping to the element being controlled and also an in previous test We had noticed when participants would Indicate that there's too much information being provided to them So they they just want the information They need to know where they are and they don't want to hear any extra information. That's just added noise So this is a case where aria controls seems to just provide more noise provides no benefit to the user for this specific case But there are our UI patterns where aria controls would be beneficial So if you have a toolbar component for example, and that toolbar has a sort button or a filter button Those sort and filter controls control the list below the toolbar So that would be a case where you would want to provide them with a way of jumping to that element That's being controlled because the next item in From that filter control or that sort control is going to be another item in the toolbar So having an easy way to jump to that list that's being controlled is a case where you would want to use aria controls So that's the end of our presentation if you're interested in seeing our final implementations, please visit our pattern fly workspace Pf-next.com and take a look Thank you. Any questions for lunchtime? Yeah, only five minutes over. Yeah, and I think we didn't start late. I mean we started 12.5 something like that. Okay