 We've got creating accessible and privacy centric products by SAP Tech. So I'll let you take it away. I'm really excited to hear what you have to share with us. Yeah, thank you. Yeah, I feel like this is an important topic that we really need to talk about, making accessible and privacy centric web, and also other products like softwares, native desktop applications, Android applications. I think most of the things that I'm going to talk today are going to cover all of them. But I'm going to follow the route for the web. So in recent trends, websites and softwares often focus on visual beauty and fancy UI, rather than the usability and inclusivity. But the truth is, if your product doesn't support the basic human rights required for surfing the web, such as like accessibility, security, privacy, then it's just not usable by everyone. And if your UX is not usable by everyone, then that sucks. So in this slide, I have actually linked to a talk called some user experience. It's an amazing talk. It covers how, if you're not thinking about everyone, then the user experience can be called some user experience and not like a great user experience because it doesn't cover everyone. So it's not very inclusive. So today, I'd like to talk about some ideas and methodologies that developers, designers, and the product team as a whole can adopt to ensure their products are accessible and privacy-centric. At certain points, this may sound like a little bit of rant, but we'll try to keep it as positive as I can. Before we get started with the talk, I have a brief introduction about myself. Well, my name is Saptak. I'm a self-proclaimed human rights center developer. What that kind of means is I try to focus more on security, accessibility, and usability of websites rather than the fanciness of it. It's not like, with that, it can't be fancy, but I try to focus on those first. I maintain and contribute to some open source projects like Onionshare, Dalai Project, Wagtel, and I'm contracting with Freedom of the Press Foundation. I was also this author of the Security and Accessibility chapter of the Almanac 2022. Now that we have that out of the way, I kind of want to talk first about who uses the web. Before we get into the ideas, before we get into the methodologies, I think it's really important to understand who are the users of your product, because I feel that gives the connection that helps you give a reason to make your products more accessible, more privacy, instead of just because some standards, some laws require you to do so. So the first thing that we are going to talk about is the interfaces used to browse with. So we are all kind of familiar with the mouse users and the touch users. Most of the software, most of the websites that we use are fairly supportive of mouse users and touch users. It works pretty good with them. I would go as far as to say that many designs and websites are made specifically with mouse users and touch users in mind. But there's more. There are much more interfaces. There are much more assistive technologies that are used. So the first one is keyboard users. I think this is kind of something that many of us might be a little bit more familiar, compared to the other ones that I'm going to talk about. So keyboard users, all of us might have used keyboard to do certain kind of activities in the web, such as filling up forms and things like that. But have you tried browsing your web just using keyboard, like just not just a single website, but go to YouTube, go to your master done, do whatever, browsing through all the master done posts. Just try that. So many people do use keyboards, just keyboards, and prefer to not touch their mouse as much as they can. For some, that's like a choice. But for many, that's like the only option. So any people who have temporary or permanent motor disabilities, for them using a keyboard is the only option that they have. So in this slide, I have an image of a person who is holding a stick in his mouth. And what they're doing is they're using that stick to press buttons on the keyboard, because they can't use a mouse because of their disability. This screenshot is taken from a web accessibility perspective stock, which is linked in the slide as well. So that's keyboard users. We have another thing called switch device users. Now switch device users, a switch device is kind of similar to keyboard, but much more restricted. So in a switch device, what happens is, for example, in this image, you can see there is a person who is sitting on a chair. And the headrest of the chair has a switch device, which has actually just two buttons. So what this switch device does is there are two buttons, and the two are switches, you can say. So the two switches, one is used as a select key. What I mean by select key would be an enter on a keyboard or a click on a mouse or a tap on a touch device. And another one is used as a next key. So next key can be similar to the tap key on the keyboard or a scroll in a mouse or sliding up in a touch. So one of the most famous persons using switch device that many might be familiar with was Stephen Hawkins. So yes, there are users who are actually using it. It's not like there are no users. So we definitely need to think about them while making things. The third important one is screen reader users. Now this is one of the assistive technologies that many people are familiar with, because after mouse and touch, when someone says about assistive technology, many people think screen reader users, but there are more. But yes, screen reader users are really important because people with limited or no visions actually need screen readers to read the content of the website. So for making a website usable, screen reader users, supporting screen reader users are very important. So most of the screen reader tools, so different operating systems have different screen reader tools. You can also install different softwares. But what most of the screen reader tools does is the person, the user still uses their keyboard to navigate through the website. And then things are read out to them. And when the tools also allow certain extra features, like you don't just need to go one by one or just page down and down, they have better navigations. Because when we use mouse, we don't just always scroll like that. We know sometimes like, OK, I need to go to this particular section. I just need to go to the footer of the page. That's where I need to go. So the screen reader tools also allow those kind of things which allows them to browse using the heading structure or the landmarks in a page, and which are all set by HTML actually. So it's really important to write good HTML and learn HTML, but we will come back to that. The other thing is, like I was saying for screen reader users, since they navigate with keyboard, the advantage is if you are making a screen reader user friendly, it's probably pretty friendly with keyboard users as well. And Zoom, so this is something that everyone knows about. All the browsers have Zoom capability. Almost all softwares also have Zoom capability. Operating systems have Zoom capability. And this is a really important assistive technology. People with low vision actually use Zoom a lot, but it's also one of the most neglected assistive technology. So it's really important that websites really work with Zoom actually by the web content accessibility guidelines. There are standards till which it should be supported. But you should really support Zoom for your products, for your websites, and always test that the website still works. Like once it goes to 200%, things should not break. Things should not go out of view and things like that. So yeah, supporting Zoom is also very important because it is an assistive technology. And there are many more. So there is mouse tick. There is voice. There is a sip and puff device, which kind of works like a switch device. There's even braille input and braille display. The braille display is really interesting. It's like there are switches which kind of either create depressions or go up, kind of like making a braille symbol. So yeah, there are many devices. And it's really important to be supporting all of them to make your websites inclusive. And just like accessibility needs, there are vary from person to person. There are various privacy needs as well, which vary from again user to user depending on their security requirements, depending on their chat model. So everyone has a different chat model. What I mean by chat model is everyone is trying to protect their themselves, their assets, their computer from different kind of attackers, right? So a journalist's chat model or an activist's chat model will be very different from my chat model. And based on that chat model, their security needs differ. And based on the security needs, obviously their privacy needs differ. And not everyone. So we can't just deny people who need privacy needs like, okay, they are just some users and they are probably already like tech savvy people. So they can just figure it out. No, it's most of the times the users who need a lot of security, they are not really tech savvy. And so they use tools like VPNs. They use tools like door browser. They use tools like NoScript. So it's really important that our websites, our products also support them and make it privacy first and then add all the things that fancy things that we want, but yeah, it's really important to do that. So now coming to the ideas and methodologies, the very first thing I would like to talk about today is progressive enhancement. Now progressive enhancement is a term that is often used for development when writing codes and things like that. But I think it's really important for designers to understand progressive enhancement as well. Because once designers understand progressive enhancement and I will get into how it works, it allows to provide better UI and UX in all the steps of the enhancement. So what do I mean? How to do progressive enhancement? So in code ways, what we do is, and I'm taking an example of making a website progressive and like progressively enhanced, but it can be, the steps will be kind of similar. The languages will change, but it will be similar for Android or OS development or stuff. So the first thing that we do is write the very basic HTML or any markup that you need for your Android app or anything. So write the very basic HTML. And then what we do is we add the basic CSS. Now what happens here is, why these are two different steps is when you write the basic HTML, you're just thinking about the structure. You're just thinking about, see the design and you're just thinking about, okay, the heading probably comes first. Okay, then there is a navigation with few links here. Then there is this particular section. Then there is this particular section. In this section, there are four articles. So when you think like this, it also helps to write better HTML. It also helps to write semantic HTML, but we'll get to that later. And then we add basic CSS to kind of position things. So just to position, it doesn't need to, it covers things like font sizes, colors, what layout you're putting it, whether it comes before or after. And it's really important. Why I say really important is like, for example, the heading hierarchy. So you should ensure that your HTML has a proper heading hierarchy and H2 always follows an H1. And then H3 always follows an H2, irrespective of the style. The style you can add using CSS. Even if the H3 design aesthetically looks bigger than H2, the markup should still be H2 before H3 because think of the heading architecture like a content of a book, right? And then we add modern CSS to enhance. Now why I say these two different steps is in the third step, what you try to do is try to implement as many of the features using just CSS. And CSS has made like massive, massive new features have come out over the last few years. So almost everything can be made with CSS. Of course, it's important to test with everyone that it still works for all the users, but yeah, try to use modern CSS to write as many of the features and then add JavaScript to kind of improve the interactions. Now what this does is, why we are using this progressive enhancement is when you write just HTML. So many times if your website is very JavaScript focused, you start writing from the JavaScript itself and the HTML gets lost somewhere and it becomes just divs and spans. So when you start from writing HTML, what it does is it already starts making your website much more accessible than if you started writing from JavaScript. The reason is when a screen reader user for example is browsing through the website, they really can't see interactions as such or they really can't see the design of the website. What they're trying to consume is the content. So HTML does exactly that. It structures properly and then gives the content. And then you use JavaScript to enhance. Similarly, if you write modern CSS and try to like implement most of the features, then what it does is if some people who have higher security needs and for their privacy, they need to disable JavaScript. So they're using some tool like NoScript or they're using Tor browser in the Cephas settings. It still works for them. It's not like, okay, JavaScript is available and then they get a blank page which sadly happens for many famous websites as well. So it's really important to provide all those features as well. And while we are talking about that, the next point is no JavaScript alternatives. So it's really important to provide no JavaScript alternatives because I have nothing against the language. I love JavaScript, but it's a very powerful tool and it can be exploited really well. So it's important to have a no JavaScript alternative. And why I am saying this in a designer conference is when we are talking about the alternative, many times developers will be like, okay, we will provide a no JavaScript alternative but the alternative will be really bad because the design for that was never provided. So I feel like that's important that designers also know that there is a need something like that. So providing all the alternatives that are needed in the progressive enhancement and like providing a no JavaScript alternative. Let's take an example. So auto filter, auto filter I think is something that we always face while we are browsing through the web whether it be an e-commerce website, whether you are trying to book a flight. So there will always be this filter on the left side or some somewhere on the page. And most of the filters what they do is when you click on a particular filter, it will filter your search results and update it. While that's a great UX because it obviously reduces a lot of the clicks and gives instant feedback to the users. But at the same time that feature is very, very JavaScript dependent. So the thing is when someone is using that same website and using the auto filter, let's say in Tor browser and they have no JavaScript enabled, they actually can't even apply any auto filter because there is no submit button, right? It always works on the click. And since there is no JavaScript, the search results are not getting filtered at all. So it's important that if there is no JavaScript, just provide that apply button. That's it. Like it's as easy a solution as that. But that's why there should be two designs, I feel. One is like, okay, this is the submit button and this is where the submit button should be. But if they have JavaScript enabled, then you don't need this. This will be the layout. So providing those two design alternatives really have already make your website a lot more privacy friendly and everyone can use your website. And the next point here is design translation. So like I was saying, one of the things that often happens which we see in teams is the design is first made. And what we do is once the design is made, we give it to the developers and the development team starts writing the code. I think this is a really bad practice and this should not be done. There should be an interaction from the very beginning. When the design is started, even from the prototyping stage, it's really important that both the people communicate because there might be user testing that the designers did that the developers are not really aware of. And because they're not really aware of, they haven't really thought that, okay, changing it this way will affect our users. But also there might be privacy and accessibility concerns with the design that is needed to be fixed. So it's really important that the interaction happens from the very beginning so that you can get the edge cases very quickly and really think like sometimes probably if a developer goes back to a designer and says, hey, this solution is not really accessibility friendly, maybe let's try something else. And I've worked with designers and they love to provide a separate solution once they know it. So it's really important that the interaction happens a lot, right? So yeah, doing the interaction is important. One of the things that I like to do is called accessibility blue lines. It can be used to do, I guess, privacy blue lines as well. But what this means is I go through the design and then it helps me and it helps the designer and helps others as well to make decisions is you go to the design and you start leaving comments. So you start leaving comments like, okay, this particular design, this particular page, this will be inside let's say a navigation tag, this particular will be articles, this will be the heading one, this will be heading to, this will be heading three. And you will find that there are many like features or code that you need to write which might not be there in the design at the very first. So for example, in accessibility, we always say that if you have a lot of navigations, you should provide a skip to content link. Now the skip to content link is not visible from the design just like that. It gets visible only when you press tab on the first, like just when you have opened the page and you press tab, the skip to content button should appear and then you press enter and it goes to the content. But many times that skip to content button is never designed because it doesn't appear in the website like that. So just writing, okay, there we will have a skip to content button and then making that design also helps. Learn HTML, yeah, it's really important to understand that HTML is not just div and span and I know again, this is a design conference but I feel like it's important that designers, you don't need to write HTML but it's good to have an understanding of how HTML works because it's a language that I feel like is often neglected and misunderstood because it has a very simple syntax. The syntax of HTML is very simple and probably anyone can learn in a DA at max but it's not in the syntax, the language, the beauty of the language is in the semantics. So understanding the semantics is very important. HTML has a lot of tags and all those tags have specific meanings. User testing and audits part a little bit. Yeah, it's really important that you user test your applications, you use a test your websites from the very early stage when you have little bit designs, prototypes ready, any kind of implementation done, start user testing and then use a varied group of users, people with different threat models, people with different assistive technology needs and that will give you a lot of feedback and after that it's really important that you do pride security audits and accessibility audits as well. The other point is don't rely on permissions always give alternatives. So for example, there will be softwares or websites which will depend on let's say the location permission and if you don't allow the location permission then it just doesn't know what to do. So let's say for example, there should be a place in the website where it also allows you to manually select your location. And now when that part comes in, the designers need to get involved because they need to provide like the input field where should it come in the website and things like that. So again, for providing alternatives to permissions it's also important that a design is made for that particular alternative and not just some scrappy bandaid way of doing it. And the last and the most important thing that I want to leave everyone with today is it's not a technical debt. Please don't treat accessibility and security and privacy as a technical debt. It happens almost everywhere. Everyone thinks of making the MVP first or like the product first and then we will think maybe we will make some accessibility changes afterwards. Please don't because that what happens is then there will be like the alternatives will just be bad. It's like because it didn't start thinking from the very beginning. All the alternatives that you provide are very bad. And many I have heard this argument a lot that, hey, I have seen and there are no users for our website who use assistive technology. So it's fine. But also there's this question that maybe there are no users of your website using assistive technology because your website is not accessible. So yeah, please don't treat it as a technical debt. It really doesn't hurt to make your website accessible and privacy centric. It actually makes your website good for everyone. So don't treat it as technical debt. Start discussing about accessibility and security and privacy from the very first day, from the very first decisions that you make while making the designs. Thanks, that's all from me. These are some of the links to my website and master done. You can also find me on IRC, my nickname is Saptakas in liberal.ch. Thank you. Thank you so much for that wonderful presentation. Oh my gosh, we have quite a few questions. I guess I'll get started and take some notes. So the first one is, how can open source communities work together to make their communities, tools, websites more accessible? Are there groups, communities working on this now? Okay, yeah. So a lot of the accessibility, like almost all accessibility standards are maintained by W3C and all of them actually happens in the open. So just now WCAG 2.2 became a candidate recommendation. So it's just a standards thing. But when that happens, even the text changes that happen in the standards actually happen through some, they have the GitHub repos and all the discussions happen there. So even if you have feedbacks for the standards, you can actually provide them because everything happens open source. Most of the, I won't say all, but a lot of the assistive technologies and accessibility projects are also open source. They might not have a huge community, but there are many open source projects. For example, the project I was talking about that I work on is called the Ally project. I will actually add, I think this HackMD link is being shared by everyone, to everyone, right? Yes. So after the talk at the session, I'll add some links as well to this question for GitHub repos and things like that. But yeah, there are projects like the Ally project, which is completely open source and it targets, it tries to make it much more simpler for users to make their products accessible, writing blogs and articles to make people aware. We also have a checklist for that that you can use. So yes, it's, most of the community is open source. I feel like often the gap is the open source projects need to have a communication. So there is often a communication gap or it's a single man project where that person themselves might not be an accessibility expert. So I guess, like doing communication, asking around in the community is a good way of starting. And most of the accessibility folks and the privacy folks do everything in open. Everything is open source. So they will be like more than happy to answer things. Yeah. Great. So our next question is rare, if any, is the middle ground between having a website that is thinking about privacy while collecting enough data to have feedback on how it's working for them to have metrics and are there other options to explore that are not based on tracking? Yeah, so what I said, and that's the entire idea of progressive enhancement, I guess, is giving options to the users. So yes, if you want to track certain things, firstly is I would always say that if you don't need to track a particular information about users, don't track it. Like really take that decision as a security decision for your website, like kind of getting hacked similar to that. So think of it from that perspective and really take that decision that, okay, do we really need that information from the user? If we don't, maybe we don't use it, but also giving options. It's okay that people who are totally fine with giving. So I have met many users who are also fine with having ads on the websites, right? Because they're like the ads, if they are tracking my activity, I'm getting better ads. So that really helps me. So I want to do that. And there are users they might not have a very big security threat model and maybe that's fine for them. So if you're building for them, it's okay, but build it progressively enhanced so that if someone decides to not give you that permission, they should still be able to use the website. They should still be able to consume your content, do the actual thing that they came to do and apart from the tracking. So providing that option, the alternative is very important. It would be kind of silly if you couldn't use the website just because of that one permission. Yeah, and I have seen that. Like there are websites which are like, okay, you don't give me location permission. I just don't show you anything. And that's just sad. Yeah. So then we have what are good accessibility projects that more people should be aware of? Yes. This is also, I think, something I can share. So usually in accessibility, what I try to do is, so firstly is, of course, WCAG standards. The standards are sometimes a little bit difficult to read, but they do have a understanding, a particular rule pages. So those kind of give examples and show you what they're really trying to do. So that is really important to follow that because even if you're following accessibility because of laws, most laws will ask you to follow a WCAG 2.1 AA or AA standard. So these are some standards. So it's really good to be aware of them. So obviously follow that. And secondly, because I feel that project is pretty good and I'm also maintainers, I'm going to plug it in here is the Ally project. I will again leave all the links in the notes. The Ally project is also an open source project. We write articles about accessibility. We also have a page with resources so that I feel is in itself a good resource which has a list of resources. So you can go through those resources that has everything from conferences to books to people to follow who are doing great works in accessibility. And we also have a checklist which explains this WCAG standard. It's not necessarily the WCAG standard correspondingly but also explains the things that you need to have in your website that makes your website accessible. So yeah, that's very important. And third is go through that resource list in the website and follow the folks working in accessibility. The folks working in accessibility write a lot of blogs and you can learn a lot from them. So yeah, I feel those three are the things that I always keep in touch of and that should be good enough to have an idea of the entire thing happen. Totally, and this is our last question. But what accessibility blind spots do you see in the average Linux distro? Interesting, so one of the things that I feel is it's not always the blind spot in the distro itself but sometimes it happens that they might not have user tested it with assistive technology users because Linux, all the distros don't really come with the assistive technology. For example, let's say a MacBook or Windows does have a screen reader tool built in it. So there are much more users of screen readers in MacBooks and Windows than in Linux. I'm not saying there is none. There's definitely a lot of them. But it's not as prevalent, I guess. So oftentimes I feel like oftentimes it's like there is not much user testing which is why I said when you are doing user testing it's really important to find those users who are using assistive technology and then try to because I've seen often the assistive technology in the assistive technology in itself is very buggy. Or sometimes it's not buggy but it's not in the same line as the other assistive technology. So when you're making websites it's really difficult to support both of them. So I think more user testing helps. One other thing and there has been some research articles around it which is a lot of the Linux users are terminal users and the accessibility of terminals is not really great because the outputs that we have on a terminal are not really markups. So let's say a lot of us, command line interface, tool builders love to give this ASCII art because that really looks cool but all the screen reader user here is adder it, adder it, adder it, dash, quotation, adder it, adder it. So they don't even get what the image is but they hear a lot of characters being spoken out for no real reason. So that again is like provide an alternative maybe, provide an alternative to your command line interface saying minus, minus, no ASCII art so that a screen reader user doesn't have to go through that hell. But yeah, the command line interface accessibility is not great. I have seen a lot of research articles or research papers being published on that and people are working on it. So I'm hoping it will get better. William, thank you so much for all of the wonderful answers and going into this presentation. I think it's a really, really important topic. So thank you so much. Yeah, thank you for having me.