React Summit

React Summit 2022

In React, Lifting State Up is a core concept. The aim of this talk is address two very important concerns in our landscape: privacy and accessibility and how we can achieve it and built in right from the components. This talk will show my work with a little open source component ad its evolution to address privacy and accessibility with the help of community and how we as developers need to care and ship the best for our people using our tools down to the most simple component. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Lifting Privacy and Accessibility Up

Hello and welcome to this talk. Lifting Accessibility and Privacy is really great to be here, part of the React Summit community. This is a community story because I'll be talking about how I created years ago a component library that along the way, with the help of the community, we baked in accessibility but also privacy, turning this component library not only more accessible but with privacy by default. It's really great to be part of this global community where we can share and exchange ideas, code, and help deliver better user experience. I think this is part of the magic of the open source and the magic of conferences like that that enables us to view other stories, view new developments, and share what we know and see what other people are building out there. I am Ibrahim Cesar. Sometimes I call it just Ibra. I am AWS community builder. I am an explicit fan of TypeScript. It is my go-to tool for building anything. Because of that, I am really, really a fan of CDK. It's a way to write your infrastructure as a code in your language, like TypeScript in my case, but could be Python and others. I think it has the same potential of jQuery when it started because for me, jQuery was a tipping point in the web because it enabled so much the front-end developers, and I think CDK will play the same role in the cloud space. But enough of me and what I see or like for the web as a whole. I will start with a little story about why I created the library in the Flare space. In 2018, I was fortunate to be at the Chrome Web Summit. It was a really great experience where I was able to see and engage in the conference in San Francisco. One of the moments I was most surprised was how they were talking about start to look at how users really use our applications, then build for ourselves or computers with high power or less smartphones. For me, it was a little rough, this kind of discourse, because in Brazil, we always had to develop for this kind of equipment. People use really dumb phones or very start-of-the-line smartphones with limited capabilities. So seeing that only in 2018 they were paying attention to this was a little shocking for me because since then I always thought they are really looking into this. But anyway, it was a really great movement, I would say, and I saw with great care they were promoting this way to respect the user's hardware and network, both problems we face here in Brazil every day, to people access information, services, and things that enable them to be fully accessed to Internet. I was solving that and thinking about all the problems I had every day to build an application to deliver news for people here in Brazil. We had this really big website with a lot of components in the front page. We had more than 150 pieces of content ranging from images, text, titles, and things like that. And we had only one iFriend from YouTube. I was really going for the best car, lighthouse, and things like that. I was solving something that I was not really sure was my fault, and I was thinking to myself, I think the problem is the iFriend. But at the same time I was thinking, well, they are Google, right? They will not provide something that decreases my performances. It is obvious it's some kind of mistake on my part, but this is not what's really true. As pointed out in the same event, the iFriend of YouTube has a huge payload. They not only load the script for the video itself, but for the ad network, for trackings they needed, and other kind of tasks they had to run on the main thread, and just put a lot of heavy load on the single thread. And it slowed down the website completely, even the place we were putting in our homepage. And in the same event, they were presenting this web component they called Light YouTube. Light YouTube was a way to provide videos with a really focused on performance. It was more than 200 times faster than the load of the page with the use of this custom element. What is this? In fact, what it does is take the image for a video ID, because you can get statically the image for a video if you know the ID. And it only places the image and only loads the iFrame when the users want to interact with it, going with the mouse and the play. So when the user starts these actions, in the background, it starts to load the iFrame and presents the user the video they want to see. But all the URLs are loaded with the per load directive, which is way leaving the single thread free for your page to load faster. And because of that, since I got back to Brazil, I started porting to React, because for me was really a kind of thing was bugging me, and I think it would be really great to also share with other people this kind of work. That presentation from Paul Irish was really great for me and showed me the way to open source. Since then, I was only working on some minor issues from packages from other people. But since I published this little library, I started more and more creating my libraries and components. And why is it so important I am talking about? I think one of the things I since the beginning I placed in the library was to, you know, enforcing some kind of best practice. Like I had ID for get the ID for the video that uses both in the URL and the image, I had a reference, the path, and title, because to generate and to the image be more accessible, it needs to be an out test. So I made purposefully required to put not only the ID, but also the title, because I think when we put in place this kind of wide rails, we move a dent in the way that developers approach their implementations. Then some months after my first release, I got this pull request that one user put this option to use privacy enhancement mode. It was a no cook URL that, you know, YouTube provides to people decide if they wanted or not, you know, that they iframe is, you know, getting or no information from you in that place because, you know, you are in someone's website and some you don't want that, you know, Google keeps tracking of people there or the person that was in your website in that moment don't want to be tracked. It's an option that people should have, right? And I didn't know that even this kind of option existed before this pull request. But since I received that, I saw not only as a good option, but months later, we decided to put this not only as an option, but purposely defined as a privacy by default, because there's this book that talks about, you know, how people react in a React conference is funny thing to say, but it talks about, you know, how little defaults can help people take better choice for, you know, the community as a whole. Like if people donate blood by default or their organs for that matter, in fact, they the country will have more donors because, you know, if people had to practically say I want to be an organ donator, they will not do that and they will less do I don't want to be a donor. So only people that are really strong about not be an organ donor will be able to have this option. But since the defaults, nudging people to better decisions for the whole is the purpose of, you know, create this kind of guardrails. Then another thing was an issue that a user opened that, you know, he found an SSH error in the library that I was using a JV when I needed to use a button is a very common problem and I always use the right element and I have to, you know, put something in place to, you know, the div container was not interactable. And for me, it was really great to see the feedback from the community after fixed issue because, you know, not only people not only one people was, you know, complaining about and how can with little effort sometimes we can make a huge difference in someone's experience. And for me to show how this phrase is really great to think about every decision we make in our components, in our applications, and how we can start to think in better ways to provide better user experience from the ground up. Straight from our components. Like in the library. Good intentions never work. You need good mechanism to make anything happen. I think this is a great quote by Jeff Bezos because, you know, he talks about, you know, we all have good intentions, right? I didn't create my library thinking I will just use JV because whatever I don't want to be, you know, accessible for people. No, I just don't know better at the time. And we need mechanism to make something of this happen. I think if I bake it in my component, the developers using it will benefit from this kind of decisions baked in. So, for this, the applications will be a little more accessible and will raise more conscience to the fact. And I think things like that, like, you know, the accessibility extension is great, but what if we had this kind of check in our, you know, TypeScript applications, like in the case of the component, that we really should to perform the accessibility and privacy related issues. It would be a mechanism, not just, you know, relying on our good intentions that I'm sure we all have. And when you take, you know, the statistics for the top 1 million pages, you can see that a lot of the main problems in our applications are easily correctable. Like, you know, low contrast between tests and colors. Missing alternative for this for image that I think is easily we can, you know, find ways to avoid this empty links, missing for input labels, empty buttons, missing document language. I think if we put a little more effort in our components, in our libraries, we can really provide a better user experience. And if you see the same report, show it to us that React itself is not, you know, like has almost the same kind of problems that, you know, every other page has. You can see that Angular is in the same average number of errors. But you can see that some libraries we think has, you know, better performance, like React has much more errors in relevance to React or comparing, you know, with other kind of frameworks, like WordPress and Larvel. I think this can show that sometimes we focus so much in one part of our application that we lose sight that user experience is not one thing. It's not just fast interactions. It's not just one thing. When you talk about user experience, we had to talk in plural. We had to talk about user experiences and to reach more people, we have to have, you know, accessibility from the start on. Because, you know, when you get the numbers for, you know, people that, you know, have some kind of issues and this can span even people, you know, reading in very low end devices that, you know, the font is needs better contrast, you will see that it's not, you know, a problem that affects a little percent of your users. And I would say read the docs. The docs are really great. We'll see, you know, that, you know, when you use div and use roles, in fact, if you use the right HTML elements, you get everything by default. We'll see the correct ways to, you know, use section and things like that. Sometimes people think just use section instead of div solves the problem and it's not exactly that. And, you know, if you read the Db3 documents, you see it's a lot friendly reading. I think it's very friendly and we'll learn a lot. And follow the hashtag A11y in the Twitter for accessibility that, you know, we will see several users and tweets about this issue and ways that will help you not only create better code, but deliver better user experience and make no mistakes. Much of the accessibility issues are also semantic issues with your code. And I would leave with the message. It's up to you, it's up to us to give users a better user a better experience using our applications. And if we from the start when creating our libraries, for as small our library is, I think if we think about and create sensible defaults, create mechanisms for people to deliver, you know, accessible and privacy by default experiences, I think we make a better web. And we'll make a better a better experience for everyone in web and in our React applications. I want to say thank you for React Summit for having me and create a better web, everyone. Bye. Bye now.
