The Cake Is a Lie... And So Is Your Login’s Accessibility

Hello, everyone, and welcome to my talk here at React Advanced this year. I'm so happy to have you here, but first things first, I need to disappoint you. I don't have cake with you. Obviously, there's logistical issues, but also as a former test engineer, I cannot pass you a cake which doesn't fulfill my own quality requirements, so I cannot do that to you. But let's try to have accessibility not be that cake, like this not available or even cake as a lie.

And in a in-person setting, I would like to ask you if there's anyone in the room who knows this quote, cake as a lie? Well, you shouldn't be surprised, but if not, no worries, I will keep you with me on the journey like the best companion cube ever. I will not leave you behind, no worries, I don't like the source of this quote, but I digress. It doesn't matter if you know or don't know about the quote, I want you to join me in this following situation.

Let's say, you wake up, you don't have any memory why you are not inside of your home, inside of your own bed, and that makes you scared, that makes you confused, but well, first things first, taking a look around. You see, this small room here, it's not really comfy, right? So there's lots of glass, it looks pretty clinical, if I can say so. It's basically the room you wake up in. There's not that much, it's the bed you woke up in, there's a radio playing a catchy music, and after a few seconds a computer voice will start to talk.

The voice will welcome you, it sounds female if I can say so, so I'll address it as a she right now, but it's a computer voice. But this computer voice, even though it gives you a so-called warm welcome, you still feel confused because this voice is not helpful at all, because it will start citing security information, which you assume is important, right? But when it gets to the point, or seemingly gets to the point, it either blacks out or uses Spanish or any language you don't understand, so you cannot understand those key information on your own security. And even if you would be able to understand this language, you cannot make any sense of it, right? Because it says something along the lines as please refrain from any fail because of area of banks. Obviously, all of this doesn't help you with the confusion, with the feeling of being lost, without any clue on what to do here, why you're here, how to get out. And this is a situation, a metaphor, where some people might find yourself in a weird And we'll get to the reason why later.

But the first and foremost reason why I use this metaphor, this room, is because this can be the same feeling if you use an inaccessible app while having a disability. So this is why I choose this depiction of the coinbuck confusing room to begin with. And as I already hinted at, maybe some of you recognize that it's not just a random room I was drawing and talking about. It's a certain start scenario, starting environment of a certain game, which I really like. This game is called Portal. It's by Valve. And it was published in 27, so it's almost 20 years old, I know I feel, but let's get not into that. So this is basically a puzzle platformer game series. There's two main installments and I guess lots of Steam Workshop stuff. And it's a series of puzzles inside of those games.

So the levels are in rooms called test chambers and every room contains a puzzle. And those puzzles need to be solved by teleporting either the player's characters, so yourself, or simple objects. And you put those teleport features in place by spawning portals, which are basically like entry and exit doors to these different places. And you try to transfer one object or yourself from this entry object portal to the exit portal. Yes. And while doing this, you are a first person player, so you have a first person view. And this computer voice, which welcomed you at the start, will keep challenging and haunting you. The AI is trying to start using that voice, it's called Gladys. And it's taunting you with a promise of receiving cake when all puzzles are completed. So yes, seemingly you'll get cake, right? And yes, we are in a weird room in this clinical room, in this science scenario portal. And I like to call this starting room like zero.

Test chamber number zero, to start. And if we move the science scenario back to the reality, I want the challenge of this room to be to zoom on the situation at hand. So how does accessibility look like in the real world right now? And this image is often quoted when it comes to defining accessibility and defining disability. To know, okay, to which people do we need to pay attention to? Which need to be taken care of? And there it's really important to be aware that disability is not only being blind, being deaf or missing a hand or an arm. It's a spectrum, more than just permanent.

My favorite example is a temporary one, because you can see here I wear glasses and I guess at least statistically speaking, half of you people outside will have glasses as well. So you need to go to checkup sometimes to the doctor to check up on your eyes. And sometimes you will get eye drops pretty often. And those basically widen your pupils. I hope that's proper English. And they make you very sensitive to light. This is especially worse in summer and I got it in my mind in July. So being very sensitive to light, you cannot read any screens because they emit light as well. So, yes, in this case, I'm temporarily blind, right? Because I cannot read screens.

Other examples are broken arms, for example, or a situational one. If you ride a car, I hope you have your eyes basically locked on the traffic and not on your phone, right? Or if you are on a conference, in a loud environment, you are not able to hear properly. So yes, there will be a situation where you have been temporarily or situational disabled. So yes, you don't want to be that person locking out all of those people from your application, right? Because you didn't have accessibility inside of your mind when building your login. You don't want to be that person.

So yes, accessibility means for me that websites, applications, projects, programs, all the things we are building are usable and accessible for everyone. All those people we talked about. And many people claim to be accessible, especially with the European Accessibility Act being in place since June, so there's a law. But they aren't quite there yet or only do the things written inside of the law to fulfill it.

Now, this makes the cake, which is basically the reward if you play the game, a lie. As in the game, the cake was always promised, but let's put it like that, it's not quite the cake we expected. And it's the same for our projects as well. Oftentimes we're not that far yet. So yes, we need to get that. And well, you were listening to my talk, you were watching my slides. I guess you are either here to prove me wrong that your accessibility is already top notch or to learn how your project is not a lie when it comes to accessibility.

And in any case, I love you and have you here. But let's take a look at one bad example. Because I wrote a small sample application, I kept it simple on purpose. So it's built in Simple React and Vite. And there you can find all the examples of my talk. We want to be at the state of the main branch later on. So there's all the correct solutions. And I will start from the don't branch. And yes, as the name already implies, please don't. So yes, take a look at that one. And then we progress to the first test chamber of Portal, the first test chamber of accessibility.

And it's about semantics. So take a look at this don't version of the login form. You can see I'm using placeholders as labels. And that's not a good practice at all. They are for examples or additional info. But not for labeling an input field. So this is a bad idea to do that because it's basically not using placeholders the way it should be. Instead, use a label for the input fields instead of a placeholder. Use only placeholders to provide additional information or examples what to type. So let's stick to labels.

So a screen reader, we'll get to that later, will be able to read those out. And it looks like this. It looks pretty cool, right? So yeah, we cleared our first pitfall, our first test chamber, and we go to the next level, which is about colors. Well, coloring stuff, it couldn't be that difficult, right? But take a look at this version of the login form. Depending on your screen setup, it will be okay for you. But for example, if I give this talk on a right screen or on a presenter, it might not be the case that the contrast of the input field border will be a good one.

Sometimes, if you are not able to see 100%, it's difficult to spot this input field. So yes, always mind the contrast. Choosing a darker color might be a good idea. Or checking back with the Chrome's DevTools, for example, which will provide you some ratios and tools to help you to get a good contrast. Same with Lighthouse. Lighthouse audits take care of the selection of colors as well. So mind the contrast, take a look at it, use it. So your login form would look like this. It's way more obvious where the input field is located and your eyes will not be feeling exhaustion to put it like that. So next pitfall, next test chamber cleared. Alright, let's go to the third one. It's on keyboard navigation.

So I, myself, I am an avid user of my keyboard because I like it, because it's more efficient, it's more fast. But if you're non-visual, for example, you might get into trouble if you cannot use like, you cannot just point your mouse at the elements, you need to tap through it. Or if you have not complete blindness but just sensitivity to light or other things making the view a little more difficult, you might be super interested to see how FocusState could help us. So here, the username is in focus. So basically I'm typing a username, but it's hard to see, right? Because the focus indication deactivates the narrative outline and only changes the border color and focus. And if we go further to the lock-in button, it has no focus indication at all.

So how can we make it even better to make it more obvious that it's focus indication? Well, we should use the outline property a little differently. Let's use some additional offset to increase the visibility and it looks like this. So just like two pixels of offset can lead you to having a way clearer focus indication. So here with the username, it's super obvious to see that the input field for the username is in focus and with the lock-in button, it is the same. Like, we can see that we're about to click it because we tapped into it. Well, next test chamber is on error handling. And right now we will focus a little more on the, I don't want to call it non-technical, but when it comes to the content of the error messages, we will get to a more technical aspect in the fifth test chamber.

So stay tuned. But, well, I guess we can take a look at both of them together inside of one demo because it's easy to combine them. So let's get to the fifth test chamber real quick. And there, we will take care of our wonderful companion. Just to give you some game context, we will have a companion cube in Porto, which helps us with some of the challenges being objects to guide us. But the companion cube in real world is a screen reader. And unlike in the game, so I want to make that super clear, we will keep our screen reader, we will keep our companion cube, we will not toss it away, we will not leave it behind, we will treat it fairly well.

Right? So, yes, our screen reader is our companion cube. It's accompanying us and helping us. And as this is a MacBook which I'm using right now, we will use the voiceover functionality, but Windows and Linux will have screen reader tools as well, and they all function pretty much the same.

So it will basically describe aloud and read aloud what appears on your computer screen. It speaks the text that's in Documents and Windows. And to turn it on, as we will see in a bit in my demo, you just need to press Command F5.

This is my demo. If you are comfortable with it, I would like you to close your eyes and listen to the things I am about to do in a little bit when starting the screen reader and triggering an error. Entering login accessibility web content. I will enter nothing. Username edit text blank. Main. Saving password. You are currently on a text field. To enter text in this field, type. Nope. Password secure edit text. I saw not. Forgot password. Login button. You are currently on a button. To click this button, press control option space. I have pressed this, yeah now. Hmm. Hmm. Head into the fields. Forgot password. This field should not be blank. Password secure edit text. You are currently on a selectable text.

Username edit text blank. You log in error. Image. You are currently on an image. To begin interacting with the contents of this image, press control. Login accessibility web content. Voice over off.

All right, you can open your eyes again. And if you're confused right now and didn't know what I did, fine, because this is exactly what I wanted to show you with the drone branch, because this is how you should not do it. So let's quickly sum up all the problems we have here. Like the user is not informed when there is an error in the login form. The user is also not informed which fields are required, even if it seems obvious to us being visual, so to say.

And selecting the input field, so like I did tabbing back to those input fields. We have no indication that they're invalid. The error message underneath the input field has no relationship to the actual input field, so we cannot just see that it's the password or username missing. It's just static text. And the icon is read as an image, which is confusing.

So lots of things to fix, and lots of opportunity to make it more obvious for a non-visual user that there was a problem with the login form.

The first thing I would like to do is the general error handling. We will add a rule alert to the alert message component to ensure proper screen reader reading.

Next, we need to address required handling by adding aria-required tags to the input fields. Additionally, the aria-invalid tag will mark fields as invalid when there's an error. Lastly, the aria-describe-by tag will connect error messages to input fields for better user guidance.

So we will need to add an aria-required tag to the input fields, so the screen reader will read the field as required. Next up, another aria tag which I would like to use is the aria-invalid one, which will make the screen reader read the field as invalid if there's an error.

And last but not least, the describe by one. So this one is something which I would show you in a little bit. Let me quickly check. Yeah, so the aria-describe-by tag would connect the input field to the ... let me quickly get back.

And so, okay, I will need to get Visual Studio Code in it. I guess you can see it, right? So yes, there's the input field here, and there you have aria-describe-by. So this one will connect the error message to the input field, and I made it depending on the error message.

So if there's an error message, I assume that there's a problem. If not, we have a problem, and then I will connect it to the ID of the input field. So when we get back to the slide, I will show you how that might look like.

So yes, let's go into it. And again, if you're comfortable with it, please close your eyes and see if you can Now we'll get more clearly at what it is about. Log in, button. You are unable to log in. Please fill in all required fields.

We have an error message. Link forgot. Please enter your password. Password. Please enter your password. Required invalid data. Secure edit text. Password. Please enter your username. Username. Please enter your username. Required invalid data. Edit text. Username. Description. Please enter your username. Required. Edit text. Login accessibility. Web content. Voice over off.

So yeah, now it is much more better, which means we did directly get the error message ping, so we know that we are not logged in. And when we tap to the fields I've had, which are invalid, the screen will correctly read out that they're required, that they're invalid because there's obviously no information in it, and it will recognize which error message belongs to which input field. I did a small other fix, which I want to point out. So I went for the error message unable to log in. Please fill in all the required fields. Same with the field names. So please enter your username for your username field. So I want to be specific about what went wrong here, and I want to give instruction on how to solve the problem. However, you will need to be a little careful when it comes to providing too much information because if you overshare, an attacker might use this information to their advantage. For example, if you say, username's wrong, they know that the password was right. So please be really careful, and there's a delicate balance to strike in between showing enough information to guide the user or overshare and invite the attacker.

And yes, for the next test chamber, to clear this screen reader one, I want to share a little bit more light on the authentication specifics because fortunately there's a project or a guide helping us. It's the Web Content Accessibility Guidelines, so WCAG. They are in the second version right now. However, I want to zoom in on a certain one, which is the Success Criterion 3.38 revolving around accessible authentication. And it gives us wonderful advice, and I want to start with the first one, which is annoying in the best case or locking people out in the worst. Because me, as a normal user, I just love to use password managers. But if you have cognitive or motoric disabilities, you rely on copy-paste. So never ever disable paste functionality in password fields. And I know there has been a click-checking attack making use of paste functionality from password managers. But even one password themselves say you should keep it enabled because it's not only more secure to keep it enabled, but also more accessible. So you don't need to be scared to leave it enabled just because of that. You could think about using passwordless options like a Magic Link, which is an on-time, one-time link sent to the user's mail that locks them in directly. I remember it's like doing that, but you can find it in other places.

So I go for WebAuthn, so the standard for passkeys. And passkeys are super cool when it comes to that. Not only pretty secure because they are pretty phishing-resistant, because they make use of the device-native capabilities, maybe biometric authentication, like Face ID, fingerprints. Just always try to leverage device capabilities. And I know they are not perfect as well. For example, I'm wearing a mask sometimes on events.

Or if you have a face with bruises or a disability, which might cause your eyes losing pigment. But if you provide alternatives and not just only one passwordless option, those are a wonderful start to start. Well, I guess you were instantly annoyed seeing the screenshot, right? Yeah. So the WCAG touches upon captures as well. And this one is basically talking from the I am not a robot game. You should check it out. Please let me know how far you got because they let you fulfill captures, which are increasingly more annoying. I made it to 15. Well, I digress.

WCAG touches on avoiding or basically trying to not do two things. One is image recognition, where a user must choose which image they provided or answer a question like, select all the things which being a vegetable. I guess not everyone is aware that a tomato is not a vegetable. So yes, you might lock out people. Or you should avoid personal content identification. Think about where a user must identify specific content they have previously uploaded, such as select the picture you uploaded that contains a dog. So yes, be careful when it comes to captures. And if you need to use something like this, like where you need to recognize something, where you do a memory test, try to keep it simple. For example, select all the images with a car and make sure that the pictures in it are simple enough for a screen reader to work with and having out text.

I wanted to touch upon MFA, multi-factor authentication as well, because I love it. You should provide it, you should implement it. But you should keep accessibility in mind as well, because multi-factor authentication could raise cognitive loads. For example, seeing time limits. If you have OTP, one-time passwords from authenticator app or SMS, ensure that the time limit is generous enough so users with cognitive or motor disabilities have enough time and a chance to read and enter the code. I don't know if you already noticed, but sometimes your phone or keyboard will already suggest the OTP, the passcode you were sent by SMS, before you need to leave the app. So yes, try to use auto-copy-paste functionality of your phone in case you can, because this way you will avoid context switching. Of course, some context switches are often unavoidable for MFA. For example, if you're using authenticator apps for your codes. But try to minimize the need to jump between different devices or apps. Another user interface tip I want to lift for you is having a clear previous indication. So if your MFA is multi-step, have step one or three or something.

So that reduces cognitive load. And last but not least, keep accessibility of QR codes in mind. If you need to use a QR code for an authenticator app, always provide the text-based secret key as an alternative for users who cannot scan the QR code directly. So if you don't want to build it completely by yourself, think about going for a UI component library such as our very own 1.0.

So you don't need to build it all on your own. No matter what path you chose, if you want to build it on your own, if you want to use a library, it doesn't matter to me because no matter what path you choose, you will make sure that the cake is not a lie, your accessibility is not a lie. That means that accessibility is truly meant and implemented and not just a label.

So that the web will become an accessible place for everyone, especially important in things like workflows such as authentication. Because we don't want to literally lock people out of our application, right? So this way, I'm happy to see that accessibility is truly meant and not just for the law. My name is Ramona Schwering. I'm working as a developer advocate at Auth0. And well, there's not that much left to say, then thank you so much for helping us, helping you help us all make the world a better place, the web a better place, more accessible and don't leave anyone behind and especially not your companion cube. Thank you so much. See you soon.