React Advanced

React Advanced Conference 2022

Alessandro Senese

React Day Berlin

React Day Berlin 2022

We want to learn about mobile accessibility to build an accessible mobile app, but where do we start? What does making an app accessible mean? What should we developers do? We will answer that by deep diving into the fundamentals of accessibility and assistive technologies. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

How to Start Your Journey Into Mobile Accessibility?

Hi, in this talk we're going to see how to get started with mobile accessibility. We're going to see what is accessibility, the different types of disabilities, assistive technologies, accessibility tools, and some resources. Before starting, I'm Alessandro Seneze, I'm a software engineer at Formidable. I started my journey in mobile accessibility about three years ago. In this slide, I'm going to share what I learned so far and what I'll give you some resources to use to get started. Okay, before starting, let's make one thing clear. Accessibility doesn't mean only make your app working with a screen reader. There is much more. So, what is accessibility? Accessibility is the practice of making your mobile app usable by as many people as possible. So, our goal is we want our app to be usable by as many people as possible. To do that, we need to also look what is a disability and how this can prevent people from using the app. So, disability is part of human being. This means that everybody is different and we have different skills and different way to access our surrounding area and mobile app. And almost everyone will temporarily or permanently experience accessibility at some point in their life. So, here we can see that everybody will have some kind of disability at some point in their life that can be temporary. Like, for example, broken arm or broken leg. Or also situational where you're holding something in your hand so you are less able to perform some movements. Also, we can see that over 1 billion people, about 15% of the global population has some form of disability. Here, we can see some numbers. So, we can see that actually a lot of people might have some kind of disability that could prevent them from using our app. That's why we need to be we need to understand these what is disabilities. Here are some other numbers found on the online. Here's specific for the Netherlands. And how Dutch people use accessibility, access technologies on the website. On the mobile app. Here is the Spectrum persona from Microsoft. Here we can see different kinds of disabilities and in different situations like permanent, temporary, or situational. So, disability, we can categorize disability in five big categories. Vision, hearing, mobility, cognitive, and speech. Here in these different categories, people will have different needs and different ways to access a mobile app. A visual impairment is a disability that can be corrected using glasses or contact lens. So, besides total blindness, there are also categories also like color blindness, central field loss, or peripheral field loss. For example, for color blindness, that's people can struggle to see, some colors. That's why maybe it's a better idea having only using only colors to give information on mobile app. And, you know, using a label with colors can be a better experience for this kind of users. Or for the other two examples, we can see that people can struggle to see or for the other two examples, they might be using magnifier on the accessibility settings or they might need to use a bigger text. So, you need to make sure that your app is rendered correctly with also using bigger fonts. Hearing impairment is when a person has a partial or total inability to hear. So, for example, hard of hearing or deafness. In this case, if we have a video, a good idea would be to provide a subtitle or a transcription so that these people can actually read what's going on. Mobility impairment, people that are affected by movement and for example, tremor, lack of coordination, paralysis, and others. This kind of person might be using other screen reader or might be using a voice assistant or for example, a switch or other assistive technologies. For cognitive impairment, when a person has trouble remembering, learning new things, concentrating, or making a decision that affects their everyday life. Some example, people with ADHD, autism, anxiety, delirium, dyslexia. Here, for example, some people might have epilepsy. So, if you have an image that flashes too much, it can cause a problem for them. For the dyslexia people, the font use and the way you use the font can actually make their experience with the app very bad. Another example can be if you have an input field and you don't have any label, people might struggle to actually remember what the field was for. So, you force them to like delete what they entered to see the hint and re-enter the information again. Or some people might be affected by movements in the animation. So, a good idea might be also disable the animation if the user asks that and so on. Another thing we need to understand is that disability is a spectrum, not a binary. In this case, this person was shared on social media and people were saying that she's a fake blind. The problem is they struggle to understand that she has some kind of low vision that still allows her to use the mobile phone. So, yeah, disability doesn't mean that you're completely disabled or you are not disabled. You can have some degrees of disability in any of the five categories we've seen. Also, another thing we need to understand is that people might have multiple disabilities. So, yeah, understanding disability is the first step in building accessible services. In our case, we want to build an accessible app. So, we really need to understand the need of these five categories and provide solutions for this person. So, when we talk about accessible technologies, we talk about keyboards, speech, braille, reader, voice control or screen reader. Some users might be using a keyboard, like with mobile phone, either iOS or Android. A screen reader, basically, is used to announce the element on the screen. A speech user uses one button control to access and to trigger elements on the screen. A braille reader or voice control if you want to control the phone with just using your voice. Usually, if you take care of a keyboard screen reader user, the other three categories should already work without much effort. Another thing provided by the mobile phones, like accessibility technologies are like an external software or external device the user can use on your mobile. But both Android and iOS provide additional accessibility settings, accessibility settings, like they are in general. For example, the user can choose to change the text size on the mobile phone. So, the app should make sure that whatever base font size you choose is going to get scaled according to that motion. As I said, some people can get nausea from motion or motion sickness. So, they might decide to just disable the animation on the device. So, if you have animation in your app, you should not animate any transition. You can still use opacity. It's more the transition any movements. Because probably to users. So, you should not use any movements in your app. Like other settings, color inversion, high contrast, bold text and dark mode. So, yes, your app should also support dark mode. Because, yeah, some people might find too sensitive reading text on a white screen. So, ideally, you should also consider supporting dark mode for your app. Another thing we need to take into consideration are the accessible principles or POR. And these are principles, fundamental principles by the W3 organization. And it's an acronym where P stands for perceivable, O for operable, U for understandable, and R for robust. Perceivable means that the interface information, user interface components must be presentable to the user in a way that they can perceive. In case, for example, yeah, text for non-text content, caption for videos, and the content, yeah, it needs to be easy to see and hear. Operable, using the user interface components and navigation must be operable. So, user should be able to operate the whatever content via external keyboard or screen reader. Screen reader. Also, you should give enough time to read, use the content to a user. So, for example, if you have any content that, like, disappear after a certain time, you should consider to extend the time if the user is using screen reader or on Android there is a setting called time to take action. You should use that time or stay instead of whatever time you decide to let the user be able to interact with the content that has, like, some expiration time. Yeah, content does not cause any seizure on physical reaction. Yeah, as we said before, if you have a flashing images that can cause problems with people with depression, so, you should prevent this type of content. And another principle is understandable. Information and the operation of user interface must be understandable. Yeah, text is readable and understandable. Content appears and operates in unpredictable ways. User are helped and correct mistakes. This, for example, applies to people with cognitive impairments. Where they use, like, too many jargons or text to default to understand, you are excluding this kind of people. Also, yeah, a good idea is to have a consistent behavior across the hub and across the components. They look the same. Robust content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. Yeah, this is, like, it is an example. You need to give a name, a role, or accessibility to a component. Okay. Now, we see we have an overview of what activity is and some principles. What we can do, this quite a lot to learn and to take in. So, what we can do, like, straight away to get started is we can use some linting. For example, for React Native, there's a plugin for Formidable called ES React Native Accessibility A11i. This will highlight at least the most basic issue, like missing accessibility role or missing accessibility label on your components. Also, you can use external tools. For example, on iOS, you can use the accessibility inspector, or on Android, you can use the accessibility scanner. There are also other external tools. Basically, those are external to your app. You need to run them manually. And, for example, on Android, the accessibility scanner will analyze your app, the web app you're using on your app. It will tell you which, like, missing label, missing role for components, or also highlight the lack of if the contrast is not enough. The other thing we need to understand is these other linting and testing tools, they are not perfect. They will only catch about 40% of accessibility issues. But it's still good enough to get started. While, you know, we practice and learn more about accessibility. For the resources, yeah, we can look at guidelines, articles, we can follow people, or look for communities, or books. This is one of the accessibility people you can follow on Twitter. He is doing currently a 365 activity where he everyday tweets about accessibility. A simple thing and how to solve the problem is, yeah, the tweet and his tweet and book are, also you can use his book, are for iOS only. But probably most of the patterns also do apply on Android. So, it's still a good resource. Another group, people on Twitter, is mobile ally. Yeah, shares a lot of resources, or retweets a lot of mobile specific. Other good resources, accessible mobile apps. They also have a mailing list where every month, no, sorry, every week, they do share articles or any kind of resources for both Android and iOS. Most of the time are native things, but we can still use, because, you know, what we want to learn how accessibility works, regardless of the underlying technology we want to use, we want to really understand how to make apps accessible. Also, some good community is, on Twitter, there's a community called, yeah, they have this new feature for communities. And this is about mobile accessibility, where you can actually ask questions. If you have any doubt about accessibility, you can ask a question, and someone will definitely reply to your answer in the best way people can. And accessible mobile, they also have a Slack channel with resources, or people that are happy to help for any query. Other resource, more mobile focus, one is React Native. React Native is a library we are building a formidable that will try to help you building an accessible app. You will have some component and some hook that help you with the purpose, meaning that some component, a hook, they're able to do some check at a time. So can tell you if there is a missing label, a missing accessible rule, or the contrast is not enough. Also, there are components like forms that already help the user to navigate using the keyboard and the next key to focus the next field. Another good resource is also, yeah, React Native also provides a guidelines. So for each components we implemented, we also tell you how is supposed to work in accessible way, and what you should be looking for when you implement some feature. Other good resource is the BBC, from the BBC. There is this one platform for app accessibility, and this is a very good resource. It's kind of new, and they also have a resource for React Native, apart Flutter and other native stuff. I think we can use Azure Ebook for developing accessible app for native Android and iOS. The reason is we might not be able to actually sometimes use the some accessibility API, because they are not available in React Native yet. But mainly what we are looking for are patterns. We really want to understand how accessibility should work, and maybe try to implement this in React Native as much as possible. The last thing I want to say is, yes, accessibility is a nice task, will take you probably time, a long time. But also it doesn't mean that it needs to be perfect. You can start right now, just use a linting tool or some accessibility tool, and add some basic accessibility, make sure that, yeah, the basics are covered, and also as long as you learn, most of you can make your app better and better and better. That's all from my talk. I hope I gave you enough resources, information to get started. If you have any questions, you can contact me on social media. I will be very happy to help you in any possible way. Thank you very much.


The most common misconceptions about accessibility are that it is time-consuming or can be easily left as the last thing to be added. But, of course, this is not the case. We’ll look at how easy and quick adopting accessibility as a First-Class Citizen and, on the contrary, how difficult and time-consuming it is to add accessibility to an existing project. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

How Time-Consuming Is It to Build an Accessible Mobile App?

Hi, is it really true that building an accessible app is time consuming and expensive? In order to answer that question, we're going to divide the agenda into two parts. The first part, we take an existing app and we try to make it accessible. The second part, we start an accessible app from scratch. Now, before starting, my name is Alessandro Senese and I'm a software engineer in Formidable. I started to work with accessibility about four years ago, where my first work with Realm Internet TV involved creating an accessible app for a bank. And so I started learning more and more about accessibility and I never stopped since then. So before we carry on, let's remind us what are we trying to do. Accessibility is the practice of making your mobile app usable by as many people as possible. So that's our target, we want to make sure that as many people as possible can use our app. So let's start. Now this accessibility issue to fix is actually a report we got from an Excel company, where they highlighted a serious and critical issue that we had to fix in our app. In my case, I did use React Native AMA to help me with these fixes. And the library is a React Native library I built after I joined Formidable. It does contain a set of components, hooks, they are designed to enforce minimum accessibility requirements. So first thing I did, I did install the library with Yard. I did import the provider provided by the library and wrapped around my application. So to fix roles, labels, states and hints, I did replace all the imports of the pressable from React Native to React Native AMA. And once I learned that I got around 200 TypeScript errors or missing roles and labels. And in the discussion, you can see how AMA works. Basically, AMA does some runtime check. But apart from the TypeScript typing, does a runtime check of some of the common accessibility issues and if it fails, it does highlight the component inside the UI and shows a banner. And also prints in the console which of the accessibility tests has failed. Now in my case, I had about 200 errors and the big problem I had, I could not assume that everything was a button. And inferred from the code, which a role to use was not always straightforward. So the only option I had was to actually navigate through on the screen to fix the problem. The same was with accessibility label. I had to make sure that the accessibility label was clear for the screen reader user. And also I had to check if it was enough because we had some cases like the one in the screenshot where the button did contain X information, in this case, five message, unread message. So I had to communicate this information to the screen reader user using accessible hint. Also because I haven't worked on all the parts of the app, I wasn't sure how many screens we actually had. So the only option I had was actually go through the entire app by myself and figure it out, all the information that was missing. For headers, it was easier. We just make sure that each screen had the header and everything that looked like a header was actually read, marked as a header for the screen reader. The forms, there was another problem we had. The bigger problem was the user was able to focus the form label and the form input as two different fields. The required option was not read and the message was not read as part of the field. Another problem was that by default React Native does show a keyboard with a return key, but that return key doesn't do anything. The right behavior was to allow the user to navigate through the fields using the next button if needed and allow to submit the form with return one. The last problem was if the form gets submitted and there is any error, the first field that does contain an error should gain the focus. This was not happening for us. So to fix this, I did use React Native Amma, especially the form field is a wrapper that handled the form submit. So if in this case handle submit fails, the form that contains a reference to all the inner field will try to focus the first field that we marked as that contains an error. And also, yeah, the form itself, it's used internally, but the text field and the use text field hook to figure out which keyboard button to show. For the text field, we had to share the components. So what I had to do was wrap, was to use the text input, use text input hook where the ref is used to allow focusing the field internally. See if the field had no validation, if had no errors, all the various attributes and pass that properties back to the text input. And also we have a form field like checkbox or combo. In this case, I had to wrap in the generic form dot field provided by Amma. And this field is able to actually get, receive a screen focus from the screen reader. For the bottom sheet, this show we had the one we were using did not did not get any focus. The user was still able to select anything underneath the overlay, the bottom sheet itself. So we had to replace that. In this case, I used one built in Amma that did address the accessibility issue. Also, this one has the benefit of disabling the animation, the sliding in and slide out animation if the user set the disable animation in the device. The time of the action, we had basically, if you in this case, if you add any time to the card, we show a message for a few seconds. And the report we had that they were supposed to behave more or less like a bottom sheet. It was supposed to gain the focus, allow the user enough time to actually interact with it. And the user was not supposed to select anything, be able to focus anything underneath. In this case, we did use the bottom sheet provided by React Native Amma. So we had all the focus feature and the focus feature. And we used in conjunction with the use them out action. This basically allows trigger the function we give according to the status of the screen reader and the device. For example, in iOS, if the screen reader is on, the timeout is never triggered. While on Android, we use the time to take action settings from the device. So that was the critical and the serious issue we fixed. So how long did it take? From the reset, it also had bug fixes because during the process, we had to replace some library with others that were accessible. So we introduced some bugs. Some of them we were not aware because, for example, the bottom sheet does use model, but React Native does not support opening multiple models unless they are nested. So we had to change a bit of logic around that to make it work in the app. And the whole process took more than five weeks to fix. So let's build an accessible app as first class citizen. How do we do that? How can we make sure that our app is accessible by day zero? The solution is easy. We can build shared components that are accessible by default. So whatever you have buttons with different states, with different hint, we just create a one or multiple shared components that handle all the required properties we need. The same we can do for a header. The same we can do for forms. We just make sure the fields are accessible already. Bottom sheet, overlay if needed, and carousel. In our case, we also had a carousel we had to make accessible. So whatever component we actually need in our app, we can create once and make it accessible. So what we're going to use is already accessible by default. We need a bit, just a bit extra time to make sure that everything works. Because yeah, accessible out of the box doesn't mean that your app is going to be full accessible. There are some checks that are needed to be done manually that we cannot automate. For example, we still need to make sure that whatever feature we build can be done with the screen reader. A screen reader user is able to do that feature. Also the focus is very important. We need to make sure that the elements get focused in the correct order. If a specific order is needed for any reason, we need to make sure that also screen reader user are able to do that order. UI changes are announced. UI change, if as consequence of some user action, we do update the UI or we show some toast elements, we need to make sure that those information is actually provided to the screen reader user. We can make it announced using one of the accessibility API provided by React Native. Or for example, if some elements appear, for example, some error, some validation, some error after an API fails, we make sure that this element gains the focus and so gets announced by the screen reader user. One thing very, very important is that we need to make sure that the appearance and the behavior and the appearance is consistent across the entire app. The app needs to be predictable. And if we have a Bluetooth buttons to the same thing, they need to look like the same. Another element is an important thing to keep in mind is group content if needed. Sometimes this can be part of the shared component we created, but we need to double check every time and make sure that's OK. In our case, we have a context here where we have a title, a header and the copy and the author and a button. The quote of the day, that's a header, can be focused separately. That's fine. But the content of the quote in our case is a quote from Walt Disney. The copy and the author should be focused as one thing. And to do that, usually you can just wrap the multiple text in an accessible view. This will force the screen reader to actually read the text as one. That's another example from our app where we have a subtotal and $20. We want to make sure that the user select the row subtotal $20 and read as one. We don't want the user to select subtotal first and $20 after. So whenever you have a release information that needs to be read together, just make sure that's the case. So here is a small table of quick cons of the link accessibility or build an accessible app from scratch. If you delete the accessibility, you don't get any benefit. Configure after the effort I had to put in, a config of a single benefit that gives you the link accessibility. It's actually very expensive. It requires a big effort. The time needed to address accessibility issue depends by the size of your app. So the bigger the worse. Most of the time and to find the problem and fix them, you need to navigate through the entire app. You can't just look at the code and guess how it's going to work. Also don't forget all the check needs to be done on both platform iOS and Android. So this means double work. You have a risk of introducing new bugs. Can happen if you need to replace some library with another or some of you need to modify the logic to make it work, to make it accessible. Well, if you start with accessible, it does require some effort to make a component accessible. But the thing is you do once. You only make accessible when you create it. Yeah, share the component will already handle most of the accessibility needs. Eventually you just need to put together. Before you do a test, we're going to use the need to test you only test what you actually building. You don't need to test the entire app. All the time from scratch, you just test what you build. So accessibility is expensive and time consuming only if you delete. That's the reality. If we can ignore it, if we know that our app needs to be accessible and we ignore it, we just going to hurt ourselves probably badly. At the end. Here I left some reference if you want to hear information about the React Native AMA and various guidelines you can refer to to know how to build an accessible mobile app. And that's all from me. Thank you very much.


We're bringing free articles, videos, courses, and tutorials to help you learn all about ReactJS, whether you're a beginner or a pro. Introduced in 2011, the framework has become essential for web and mobile developers alike, enabling modern apps by look and function. And while other JS tools have expanded or revised its original notions, React's popularity is still the one to beat.

React is a powerful JavaScript library for building user interfaces. Learn more about React with our comprehensive talks, workshops, tutorials and presentations. Our experts will help you understand the fundamentals of React, as well as advanced concepts such as state management, routing, performance optimization and more. With our resources, you’ll be able to create stunning web applications with React and take your development skills to the next level.

React Talks, Workshops, Tutorials and Presentations for JavaScript Developers

Building swift yet functional apps should be what all developers aspire to. And since you do, we put together a collection of talks and tutorials on application performance and made them available for free. Whether your challenge is on the front-end or the back-end, these talks and workshops will give your great tips and inspire you to try new solutions.

Performance is an essential skill for JavaScript developers. Our portal offers a range of talks, workshops, tutorials and presentations to help you become a better programmer and take your coding skills to the next level. Learn the latest techniques and strategies to improve the performance of your code, discover new tools to measure and track performance, and get tips on how to optimise your code for maximum efficiency. Whether youre looking to improve your existing skills or start from scratch, our comprehensive library of resources will provide you with all the information you need. Take your programming skills to the next level with our performance-focused talks, workshops, tutorials and presentations.

Maximising Performance with Talks, Workshops, Tutorials and Presentations for JavaScript Developers

Coding is like a piece of art — in its ideal state, it should be both functional and beautiful. But how to reach that point? Whether you’d like to make your JavaScript code cleaner or just discover how seasoned developers deal with debugging or building a product, the following tutorials will show you how to include best practices in your daily routine.

The page contains talks, workshops, tutorials and presentations about the best practices for JavaScript developers. Learn from experienced professionals about techniques and strategies to optimize your code, debug errors, and enhance your development skills. Get up-to-date information on the latest trends in the JavaScript ecosystem, such as frameworks, libraries, and tools. Discover the best practices for writing efficient, maintainable, and secure code. Take advantage of our interactive sessions and hands-on tutorials that will help you become a better JavaScript developer.

Best Practices in JavaScript Development: Talks, Workshops, Tutorials and Presentations

Did you know that TypeScript lets you write JavaScript the way you really want to? Explore the variety of Typescript courses we compiled from our speakers and collaborators and find out what you can do with this language and how it improves the development experience.

This page contains talks, workshops, tutorials and presentations about Typescript. Learn from experienced JavaScript developers how to get started with Typescript and how to use it in your projects. Get the latest tips and tricks for coding with Typescript and find out how to optimize your code for maximum performance. Discover how to create efficient and maintainable applications with Typescript and take your development skills to the next level.

Learn Typescript: Talks, Workshops, Tutorials & Presentations for JavaScript Developers

Feeling like boosting up your career? In this section, you'll find free JavaScript courses, tutorials, and coding lessons to help you stay up-to-date with the latest developments in the JS ecosystem and take you from basic to advanced. Dive into it, and you'll find out that the world's most popular programming language is easy to learn.

Welcome to the JavaScript Learning Portal! Here you will find a variety of talks, workshops, tutorials and presentations about JavaScript. Whether youre a beginner looking to learn the basics or an experienced developer looking to stay up-to-date on the latest trends in the language, this portal has something for everyone. We have organized our content into different categories so you can easily find what you need. Explore our selection of talks, workshops, tutorials and presentations today and start learning more about JavaScript!