Lifting Privacy and Accessibility Up

♪♪♪ Olá and hello and welcome to this talk, Lifting Accessibility in Privacy App. It's really great to be here, part of the React Summit Committee. 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 is 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 Ibran Cesar. Sometimes I call it just Ibra. I am an AWS community builder. I am an explicit fan of TypeScript. It is my go-to tool for building anything. And 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. And 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. And one of the moments I was most surprised was how they were talking about start to look at how users really use our applications than, you know, build for ourselves or, you know, computers with high power or less smartphones. And 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 that they are really looking into this. But anyway, it was a really great movement, I would say. And I saw with great care that they promoted this way to respect the users' hardware and network, both problems we faced 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 iframe from YouTube. I was really going for the best score in Lighthouse and things like that and 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 iframe, but at the same time I was thinking, well, they are Google, right, they will not provide something that will, you know, decreases my performances. So, it is obvious it is some kind of mistake on my part, but this is not what is really true.

As pointed out in the same event, the iframe of YouTube has a huge payload, they not only load the scripts for the video itself, but for the ad network, for the tracking they needed, and other kind of tasks they had to run on the main thread and this puts a lot of heavy load on the single thread and slows down the website completely, even the place we were putting in our homepage.

And in the same event they were presenting these web components they called Light YouTube. Light YouTube was a way to provide videos with 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 it does? 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 to the user the video they want to see. But all the URIs are loaded with the Per-Load directive, which is way leaving the single thread free for your page 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 that 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, you know, 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 it's so important I'm 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, you know, I had id for get the id for the video that uses both in the and the image reference, the path, and title, because to generate and to the image be more more accessible, it needs to be an outtest. 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.

Some months after my first release, I got this pull request that one user put this option to use a privacy enhancement mode. It uses a no-cook ROI that, YouTube provides, to people decide if they wanted or not, that their iFrame is getting or no information from you in that place because you are in someone's website and you don't want that, you know, Google skip tracking of people there or the person that was in our 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 is this book, Noti, that talks about how people react in a React conference. It's a funny thing to say. But Noti talks about how little defaults can help people take a better choice for the community as a whole. Like, if people donate blood by default, or their organs, for that matter, in fact, the country will have more donors because, if people had to practically say, I want to be an organ donator, they will not do that and they will less say, I don't want to be a donor. So only people that are really strong about not being an organ donor will be able to have this option. But, nudge people to make better decisions for the whole, is the purpose of creating this kind of guardrails.

And another thing, was an issue that a user opened that, you know, he found an SSS bleach error in the library that I was using a GV 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 container was not interactable and for me it was really great to see the feedback from the community after fixed issue, because 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, from straight from our components, like in TIS library. Good intentions never work. You need good mechanism to make anything happen. I think this is a great quote by Jeff Bezos, because it talks about we all have good intentions, right? I didn't create my library thinking I will just use Jib because whatever, I don't want to be 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. 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 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 will 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 image that I think is easily we can, you know, find ways to avoid empty links, missing 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 as, you know, better performant, like React, has much more errors in relevance to, you know, React or comparing, you know, with, you know, other kind of frameworks like WordPress and Laravel. 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 accessibility from the start on, because when you get the numbers for people that have some kind of issues, and this can spend even people reading in very low-end devices, that the phone needs better contrast, you will see that it's not a problem that affects a little percent of your users.

And I would say read the docs, the docs are really great, you will see that when you use jiv and use roles, in fact if you use the right HTML elements, you get everything by default, you see the correct ways to use sections and things like that, sometimes people think just using sections instead of jiv solves the problem and it's not exactly like that, if you read the Db3 documents you see it's a lot friendly reading, I think it is very friendly and you will learn a lot and follow the hashtag A11y in twitter for accessibility, 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 experience using our applications. And if we, from the start, when creating our libraries, for as small as our library is, I think if we think about and create sensible defaults, create mechanisms for people to deliver accessible and private by default experiences, I think we'll make a better web and we'll make 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.