Latest tech, great! Accessibility, not so much.
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Mangiurea, Oana
All over the FOSS world, we see that out of thousands of issues and pull requests, very few of them tackle accessibility issues. And this is mostly due to a lack of knowledge on the subject, and a fear that it’s too hard to implement these changes. When we say “accessibility,” we immediately think of vision impairment, but being able to use a product with just your keyboard is also an accessibility feature. It’s 2021 and we talk about providing equal opportunities everywhere in tech, but so often we disregard our own users or community. We have this idea that accessibility issues can be postponed and fixed later, as they don’t affect the vast majority of our users. But is that true? One billion people experience some sort of disability. At least 10% of the adult population has a vision impairment. And those are just numbers for people who have been tested and suffer from a long-term disability. By creating accessible products you can... * Improve the experience for all your users * Increase your user or community base * Cater to clients whose businesses have a mandatory accessibility requirement for the software that they use * Potentially expose areas in UI or user flow that need improvement In this talk, following a real-life example, you’ll learn how to check where your project stands today and what steps you can take to make it more accessible, even with the help of your community.
 Hi everyone and thank you for joining me today. I'm Wana, I'm a UX designer working at Grafana Labs and today we are going to talk about accessibility and more specifically web accessibility. When we discuss about it, not everyone knows what it means or why they should actually care. So computer accessibility refers to the accessibility of a computer system by all people regardless if they have a disability type or severity of impairment. When we say disability type, there are several of them. You might know about vision ones where I have color blindness for example, mobility, auditory, neurological, cognitive, medical and psychological. One billion people or 15% of the world's population experience some sort of disability. At least 10% of the other population has a vision impairment and the numbers are actually growing with somebody's age. So it's quite important when you think of these numbers, consider your user base and actually how many people are affected. Why you should care even more when it comes to what you're currently working on if you're having an interface of some sort is what you actually get. If you fix your accessibility issues, you get a tool or an app that is easier to use by everyone in general. And that it also leads to a bigger user or contributor base as more people can start using your project. You get advantage of all your competitors and even cater for clients whose businesses have mandatory accessibility requirements for the software that they use. And that for example includes the federal agency. So even more you can potentially expose areas in the UI or user flow that need more improvement. And in the end it's 2021. We should not only talk about being more inclusive but also act on it. Right. So where you can actually start? You can start by learning about accessibility. If there is one place I would recommend you to start. It's called LI Project. And you'll have all the great resources in there and not some checklists that you can use. Go start with whatever accessibility is and go from there. Do not try to read everything at once. Next as it comes to tools, what we can use as designers and developers as well. For designers we have a few tools that we can add as plugins to our current programs that we mostly use like Figma, Sketch or Adobe Xda. So we have color contrast checkers on one hand and color blindness simulators on the other hand. Unfortunately these are quite static. You can only check what's a picture in the end. But things do improve as soon as we move to browsers. So if you already have a working app or a working website it becomes a lot easier to see your current state of things. So for browsers you have on one hand Firefox accessibility tool and on the other hand Google Lighthouse which also works on Opera very well. Firefox is a quite fantastic tool. I would say it features a color blindness simulator, a color contrast checker. They have audit for contrast, keyboard navigation and text label issues. And it can also show you tabs for order of navigation. I have this in the screenshot. You can inspect a specific element and they will tell you if the color contrast is okay or you can go for the entire page at once. You have then there are other tools like browser extensions. Me as a designer I use very often wave which is an evaluation tool. And I prefer this one because it will highlight all the elements in the page that have issues. And then I can go to whatever tool I'm using as a designer and fix them right on the spot. And I also use other types of color blindness simulator and color contrast checkers both as extensions and online tools. Yet again there is also something called supportive assistive technology. And here this includes voiceover aka screen readers. So these are very important for those who complete loss of vision for example. On Linux you have Orca or a Maxpeak. On Mac you have voiceover and there are a bunch of others available on Windows. All of them are free. And if you really want to try it yourself and see how one of your users might feel, close your eyes and try sending an email using a screen reader. I challenge you. And please don't cheat. I can only tell that puts so much things into perspective. Also if you are a developer you can use a free and open source tool like Pali to run accessibility test on your pages via the command line or notches. You can also automate your testing process with this and make it part of your CI workflow. It's very easy to install it locally and it's a one line of command to run it. Right. Looks and is in a way overwhelming. The more people I talk with or I discuss accessibility they feel overwhelmed right from the start. They say yeah I started reading but then I left it right there because there were so many things to know and so many places to start. And yeah I had the same feeling when I firstly heard about accessibility. But then I started thinking how can I approach things to change this and actually make an impact. And that is to take things one by one. So you can actually break it into smaller pieces. I would suggest and I have an example following this to start by auditing your project. Use one of the tools presented or others. There are a lot of other tools out there that you can use to see where your current project stands today. Identify main issues and then estimate time and effort required. You might even realize what you thought will take a lot of time actually takes just a matter of hour or days. You can create a plan with a roadmap or prioritization matrix or basically anything that works for you. And always especially in this case start small like go after the low hanging fruit. What's the easiest that you can actually fix even today. That way you'll have the board rolling. And lastly because we are discussing on open source involve your community. This is an amazing resource. You can test your interfaces with them. You can invite them to open accessibility related tickets and so much more. And I was saying this is based on my experience and this is something we are currently working on. So I started to discuss more with my team about accessibility and what we could be doing actually a few weeks back only. And I started by doing an audit. The table that you see here is based on real feature and it took me like I think only half an hour to do it. So I identified a lot of the errors using wave. Color blindness for us was pretty okay but we did have some color contrast issues. And unfortunately our app completely lacks a good tab navigation or keyboard navigation. It's basically unusable and we should admit it. So going to main issues that I took out of it. I was saying impossible to use the app with keyboard only and that also makes it impossible to use with screen readers. We have some issues with structural elements like page heading levels are sometimes skipped and we think something that is called page region or area landmarks that are used to identify significant page areas. On forms we are also using a design system. We had issues with having some empty labels for switches, missing some field set and form labels. And then on the color contrast in our case at least we had the issues were code highlighting on inline editors. For example, the red on black had to low contrast and this was for our dark team. Right. So let's go to actually try to fix it. Right. The soon I had that audit done I reached out to one of our front end developers working on the same projects as I were and asked him to help me to think of how much time it will take us to fix all these. So he said to define area landmarks depending on the feature. It can take up to two days if to make sure the labels have dropped down spotting groups and all that probably one day and to use proper level headings another day. And for things because our system is decoupled from the design system team. If we encountered issues coming from that part, we could at least open a GitHub issue and even assign it to ourselves if we think it's a small fix and we have the time. So all of this we can actually fix in under one week. When we said this, people started to get excited except of being scared. Of course, then it's keyboard navigation. This is a lot harder to do. But still it can be from one week to two months again depending on the feature or area. And I wanted to go more in deep to tell you what that entails. You might know that using keyboard navigation, it usually means to navigate via a tab key and maybe space and enter if you want to focus somewhere specifically. It also means to have a visible focus indicator to know where was the element that you currently selected on a page. And that you might have already seen on any type of form that you might have filled. A focus indicator, for example, in an input, it's that border, which is usually blue depending on the browser, but it's mostly blue that will tell you that, hey, this is where you are currently focusing in. But there's also something called persistent of focus. And it's essential that there is an active element or a focused element all time on a given page. As an example, if you have opened a model window and you click it, you click the X button to close it, so the last thing in focus for you, it was that close button. But what, and that disappears from the page in the end. So in that case, we need to specify another active element. Maybe it can be the button that opened the window in the first place. Otherwise, the focus will go back at the beginning of the page and the user can be taken out of the flow. There's also predictability of movement as most of us are going through a page from top to bottom and left to right because that's how we are writing. We are writing from left to right. So we expect to move in a page following this pattern. And if by chance, your elements are inverted in the background and user doesn't see you, you might jump all over the place and that will cause a great deal of confusion. And there's also an important aspect of avoiding keyboard traps. So you go tab by tab from one element to another. But then at some point, you might enter an input which has a multiple select and there's no way for you to be to go anywhere else except select elements in that input. And that's called a keyboard trap. And lastly, a thing called bypass blocks. So this is super important for, especially for navigation elements like menus. If you just entered a website and you want to go straight to a particular area on that page, you might not want to go through each element of the navigation bar. And because menus are often placed as forced elements on the page, you'll have to go do a lot of tabs to reach your desired part. In that case, we can actually provide a skip to content link that's available on the screen. And this is actually a proposed approval that I had just to give you an example of what I could do as a designer to help developers understand what changes we need to make. So up until now, we did not have what's here skip to main content part. You had to go to the entire menu. We were not highlighting menu elements that were in focus. And we were not also not highlighting elements that were behaving like actual links or buttons. So I just added some visual clues on those parts. Right. Final step in our case, after all these changes are done, we want to test them with Pali. That's what I just presented. Our own keyboards, there's nothing for, from skipping that part and voice over tools as much as possible. Then get feedback from the community on the changes. We are very lucky because people in our community already raised their hands being that are very glad to test. We have a lot of colorblind users happy to test. We even had potential new users who were almost 100% blind. And when they heard that we are doing this accessibility improvements, they were so eager to offer their help. And then keep learning, keep fixing and write semantic HTML. Thank you for the time that you allocated for this. And now let's take some questions.
 Hi everyone and thank you for joining me today. I'm Wana, I'm a UX designer working at Grafana  Labs and today we are going to talk about accessibility and more specifically web accessibility.  When we discuss about it, not everyone knows what it means or why they should actually  care. So computer accessibility refers to the accessibility of a computer system by  all people regardless if they have a disability type or severity of impairment. When we say  disability type, there are several of them. You might know about vision ones where I have  color blindness for example, mobility, auditory, neurological, cognitive, medical and psychological.  One billion people or 15% of the world's population experience some sort of disability. At least  10% of the other population has a vision impairment and the numbers are actually growing with somebody's  age. So it's quite important when you think of these numbers, consider your user base  and actually how many people are affected. Why you should care even more when it comes  to what you're currently working on if you're having an interface of some sort is what you  actually get. If you fix your accessibility issues, you get a tool or an app that is easier  to use by everyone in general. And that it also leads to a bigger user or contributor  base as more people can start using your project. You get advantage of all your competitors  and even cater for clients whose businesses have mandatory accessibility requirements  for the software that they use. And that for example includes the federal agency. So even  more you can potentially expose areas in the UI or user flow that need more improvement.  And in the end it's 2021. We should not only talk about being more inclusive but also act  on it. Right. So where you can actually start? You can start by learning about accessibility.  If there is one place I would recommend you to start. It's called LI Project. And you'll  have all the great resources in there and not some checklists that you can use. Go start  with whatever accessibility is and go from there. Do not try to read everything at once.  Next as it comes to tools, what we can use as designers and developers as well. For  designers we have a few tools that we can add as plugins to our current programs that  we mostly use like Figma, Sketch or Adobe Xda. So we have color contrast checkers on  one hand and color blindness simulators on the other hand. Unfortunately these are quite  static. You can only check what's a picture in the end. But things do improve as soon  as we move to browsers. So if you already have a working app or a working website it  becomes a lot easier to see your current state of things. So for browsers you have on one  hand Firefox accessibility tool and on the other hand Google Lighthouse which also works  on Opera very well. Firefox is a quite fantastic tool. I would say it features a color blindness  simulator, a color contrast checker. They have audit for contrast, keyboard navigation  and text label issues. And it can also show you tabs for order of navigation. I have this  in the screenshot. You can inspect a specific element and they will tell you if the color  contrast is okay or you can go for the entire page at once.  You have then there are other tools like browser extensions. Me as a designer I use very often  wave which is an evaluation tool. And I prefer this one because it will highlight all the  elements in the page that have issues. And then I can go to whatever tool I'm using as  a designer and fix them right on the spot. And I also use other types of color blindness  simulator and color contrast checkers both as extensions and online tools. Yet again  there is also something called supportive assistive technology. And here this includes  voiceover aka screen readers. So these are very important for those who complete loss  of vision for example. On Linux you have Orca or a Maxpeak. On Mac you have voiceover and  there are a bunch of others available on Windows. All of them are free. And if you really want  to try it yourself and see how one of your users might feel, close your eyes and try  sending an email using a screen reader. I challenge you. And please don't cheat. I can  only tell that puts so much things into perspective. Also if you are a developer you can use a  free and open source tool like Pali to run accessibility test on your pages via the command  line or notches. You can also automate your testing process with this and make it part  of your CI workflow. It's very easy to install it locally and it's a one line of command  to run it. Right. Looks and is in a way overwhelming. The more people I talk with or I discuss accessibility  they feel overwhelmed right from the start. They say yeah I started reading but then I  left it right there because there were so many things to know and so many places to start.  And yeah I had the same feeling when I firstly heard about accessibility. But then I started  thinking how can I approach things to change this and actually make an impact. And that  is to take things one by one. So you can actually break it into smaller pieces. I would suggest  and I have an example following this to start by auditing your project. Use one of the tools  presented or others. There are a lot of other tools out there that you can use to see where  your current project stands today. Identify main issues and then estimate time and effort  required. You might even realize what you thought will take a lot of time actually takes just  a matter of hour or days. You can create a plan with a roadmap or prioritization matrix  or basically anything that works for you. And always especially in this case start small  like go after the low hanging fruit. What's the easiest that you can actually fix even  today. That way you'll have the board rolling. And lastly because we are discussing on open  source involve your community. This is an amazing resource. You can test your interfaces  with them. You can invite them to open accessibility related tickets and so much more. And I was  saying this is based on my experience and this is something we are currently working  on. So I started to discuss more with my team about accessibility and what we could be  doing actually a few weeks back only. And I started by doing an audit. The table that  you see here is based on real feature and it took me like I think only half an hour to  do it. So I identified a lot of the errors using wave. Color blindness for us was pretty  okay but we did have some color contrast issues. And unfortunately our app completely lacks  a good tab navigation or keyboard navigation. It's basically unusable and we should admit  it. So going to main issues that I took out of it. I was saying impossible to use the  app with keyboard only and that also makes it impossible to use with screen readers.  We have some issues with structural elements like page heading levels are sometimes skipped  and we think something that is called page region or area landmarks that are used to  identify significant page areas. On forms we are also using a design system. We had issues  with having some empty labels for switches, missing some field set and form labels. And  then on the color contrast in our case at least we had the issues were code highlighting  on inline editors. For example, the red on black had to low contrast and this was for  our dark team. Right. So let's go to actually try to fix it. Right. The soon I had that  audit done I reached out to one of our front end developers working on the same projects  as I were and asked him to help me to think of how much time it will take us to fix all  these. So he said to define area landmarks depending on the feature. It can take up to  two days if to make sure the labels have dropped down spotting groups and all that probably  one day and to use proper level headings another day. And for things because our system is  decoupled from the design system team. If we encountered issues coming from that part,  we could at least open a GitHub issue and even assign it to ourselves if we think it's  a small fix and we have the time. So all of this we can actually fix in under one week.  When we said this, people started to get excited except of being scared. Of course, then it's  keyboard navigation. This is a lot harder to do. But still it can be from one week to  two months again depending on the feature or area. And I wanted to go more in deep to  tell you what that entails. You might know that using keyboard navigation, it usually  means to navigate via a tab key and maybe space and enter if you want to focus somewhere  specifically. It also means to have a visible focus indicator to know where was the element  that you currently selected on a page. And that you might have already seen on any type  of form that you might have filled. A focus indicator, for example, in an input, it's  that border, which is usually blue depending on the browser, but it's mostly blue that  will tell you that, hey, this is where you are currently focusing in. But there's also  something called persistent of focus. And it's essential that there is an active element  or a focused element all time on a given page. As an example, if you have opened a model  window and you click it, you click the X button to close it, so the last thing in focus for  you, it was that close button. But what, and that disappears from the page in the end.  So in that case, we need to specify another active element. Maybe it can be the button  that opened the window in the first place. Otherwise, the focus will go back at the beginning  of the page and the user can be taken out of the flow. There's also predictability of  movement as most of us are going through a page from top to bottom and left to right  because that's how we are writing. We are writing from left to right. So we expect to move in  a page following this pattern. And if by chance, your elements are inverted in the background  and user doesn't see you, you might jump all over the place and that will cause a great  deal of confusion. And there's also an important aspect of avoiding keyboard traps. So you  go tab by tab from one element to another. But then at some point, you might enter an  input which has a multiple select and there's no way for you to be to go anywhere else except  select elements in that input. And that's called a keyboard trap. And lastly, a thing  called bypass blocks. So this is super important for, especially for navigation elements like  menus. If you just entered a website and you want to go straight to a particular area on  that page, you might not want to go through each element of the navigation bar. And because  menus are often placed as forced elements on the page, you'll have to go do a lot of  tabs to reach your desired part. In that case, we can actually provide a skip to content  link that's available on the screen. And this is actually a proposed approval that I had  just to give you an example of what I could do as a designer to help developers understand  what changes we need to make. So up until now, we did not have what's here skip to main  content part. You had to go to the entire menu. We were not highlighting menu elements  that were in focus. And we were not also not highlighting elements that were behaving like  actual links or buttons. So I just added some visual clues on those parts. Right. Final  step in our case, after all these changes are done, we want to test them with Pali.  That's what I just presented. Our own keyboards, there's nothing for, from skipping that part  and voice over tools as much as possible. Then get feedback from the community on the  changes. We are very lucky because people in our community already raised their hands  being that are very glad to test. We have a lot of colorblind users happy to test. We  even had potential new users who were almost 100% blind. And when they heard that we are  doing this accessibility improvements, they were so eager to offer their help. And then  keep learning, keep fixing and write semantic HTML. Thank you for the time that you allocated  for this. And now let's take some questions.
latest_tech_great_accessibility_not_so_much_0_179.png latest_tech_great_accessibility_not_so_much_180_515.png latest_tech_great_accessibility_not_so_much_516_563.png latest_tech_great_accessibility_not_so_much_564_2207.png latest_tech_great_accessibility_not_so_much_2208_2267.png latest_tech_great_accessibility_not_so_much_2268_3563.png latest_tech_great_accessibility_not_so_much_3564_3611.png latest_tech_great_accessibility_not_so_much_3612_4319.png latest_tech_great_accessibility_not_so_much_4320_5099.png latest_tech_great_accessibility_not_so_much_5100_6467.png latest_tech_great_accessibility_not_so_much_6468_7295.png latest_tech_great_accessibility_not_so_much_7296_8411.png latest_tech_great_accessibility_not_so_much_8412_9083.png latest_tech_great_accessibility_not_so_much_9084_9971.png latest_tech_great_accessibility_not_so_much_9972_11759.png latest_tech_great_accessibility_not_so_much_11760_13151.png latest_tech_great_accessibility_not_so_much_13152_14471.png latest_tech_great_accessibility_not_so_much_14472_16115.png latest_tech_great_accessibility_not_so_much_16116_21023.png latest_tech_great_accessibility_not_so_much_21024_21947.png latest_tech_great_accessibility_not_so_much_21948_23291.png latest_tech_great_accessibility_not_so_much_23292_23435.png latest_tech_great_accessibility_not_so_much_23436_23723.png latest_tech_great_accessibility_not_so_much_23724_23839.png