Lifting Privacy and Accessibility Up

Rate this content

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.

25 min
21 Jun, 2022


Sign in or register to post your comment.

AI Generated Video Summary

In this talk, the speaker discusses the creation of a component library that prioritizes accessibility and privacy. They highlight the importance of building applications that cater to users' devices and network limitations. The speaker shares their experience of solving performance issues with a YouTube iframe and introduces Light YouTube, a performance-focused web component. They emphasize the need to prioritize accessibility and privacy in applications and provide insights on how to address common problems. The talk concludes with a call to prioritize accessibility and create sensible defaults in libraries to improve user experiences.

1. Introduction

Short description:

In this talk, I will discuss how I created a component library that prioritizes accessibility and privacy. Being part of the React Summit Committee and the global community allows us to exchange ideas and deliver better user experiences.

♪♪♪ 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.

2. Introduction to CDK

Short description:

I am Ibran Cesar, an AWS community builder and an explicit fan of TypeScript. CDK, a way to write infrastructure as code, has the potential to be as impactful as jQuery was for front-end developers.

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.

3. Creating the Library

Short description:

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, where they emphasized the importance of building applications that cater to users' devices and network limitations. This resonated with me, as in Brazil, we often have to develop for low-end smartphones and limited connectivity. I realized the need to prioritize accessibility and performance, which led me to create the library.

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.

4. Solving Performance Issues with YouTube Iframe

Short description:

I was solving the performance issues of a website with multiple components, including a YouTube iframe. I initially thought the problem was my fault, but it turned out that the YouTube iframe had a huge payload, slowing down the website. At an event, I learned about Light YouTube, a performance-focused web component that loads the iframe only when the user interacts with it.

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.

5. Performance Optimization and Privacy Enhancement

Short description:

The iframe of YouTube has a huge payload, which slows down websites. Light YouTube is a performance-focused web component that loads the iframe only when the user interacts with it. I started porting it to React and enforcing best practices. A privacy enhancement mode was added, and it is now the default. Feedback from the community has helped improve the library and create better user experiences.

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.

6. Prioritizing Accessibility and Privacy

Short description:

We need to prioritize accessibility and privacy in our applications. By implementing checks in our TypeScript applications, we can address these issues effectively. Many common problems in our applications, such as low contrast, missing alternative text for images, and empty links, can be easily corrected. React and other frameworks may have more errors than we realize, highlighting the need to focus on user experiences and accessibility from the start. Reading the documentation and following the #A11y hashtag on Twitter can provide valuable insights and help us deliver better user experiences. Let's prioritize accessibility and create sensible defaults in our libraries to make the web a better place for everyone.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.

React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.
You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents
- The different kinds of React application tests, and where component tests fit in
- A mental model for thinking about the inputs and outputs of the components you test
- Options for selecting DOM elements to verify and interact with them
- The value of mocks and why they shouldn’t be avoided
- The challenges with asynchrony in RTL tests and how to handle them
- Familiarity with building applications with React
- Basic experience writing automated tests with Jest or another unit testing framework
- You do not need any experience with React Testing Library
- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
- Introduction
- Prerequisites for the workshop
- Fetching strategies: fundamentals
- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)
- Test your build and serve it on Vercel
- Future: Server components VS Client components
- Workshop easter egg (unrelated to the topic, calling out accessibility)
- Wrapping up
React Summit 2022React Summit 2022
160 min
React at Scale with Nx
The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.
We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries.