 Hey, everybody. What's up? It's Rob Dodson. Welcome back to the Alicast show. Today I want to talk about a question that I got on Twitter from a developer, Sarah Swaydan, who was asking, if you're rearranging content on screen visually, does that affect the behavior for keyboard and for screen reader? So that's a great question. It's definitely something that I've run afoul of a lot of times because there's some some gotchas to this. So what I wanted to do was walk through a little example. I'm going to create some form elements, rearrange them, and then we'll see how a screen reader and keyboard behaves when we do that. So follow me over here to my laptop. What I've implemented is pretty simple. I've got a little form here. I've got a few input controls. So basically, it's all the same ordering in the DOM for each of these. So it goes like label, followed by an input, followed by a button. Same for each of these three rows. And we'll swap over to Chrome. And this is what our form looks like. It's not going to win any beauty contest or anything like that, but it will help us illustrate this very important point. So let's look at what happens when I try tabbing through this experience. So I want to see the focusable controls and the order in which they receive focus. So I start tabbing, right? It goes input, submit, input, submit, input, submit, as we would expect. It goes left to right, left to right, and it goes sort of top to bottom. Cool. So again, that sort of follows the natural reading order of this page. And I think that's sort of what a user would expect as they're tabbing through this. Now let's use a little bit of CSS and kind of rearrange these things a little bit. So all these elements right now are positioned with Flexbox. So what I can do is drop in some styles that I wrote earlier. Okay. And I'm going to use Flexbox's order property to reorder those children. So if you're looking at code here, so on line two, I'm going to change the order. So it goes like button, input, label. And then on line three, I'll go label, button, input. And the order property just lets me say, you know, which of the Flex children, how they get displayed and what order, right? So go back here. This is what we're rendering now. So the first line I left as it originally was, the second line I went in, and the third line I went in, and now things are kind of jumbled. So let's try tabbing through this now with our keyboard and see what happens. So we'll go to the input and the submit button. And now of course the question is, where does focus go next? You might expect that it would go to that submit button down there, but it actually goes to this input, which is kind of like in the middle of the screen. Then it goes to the submit, and then we go to the next line, input, submit. You know, similarly we turn on our screen reader, right? Voice over on Chrome 127.0.0.1, first name, edit text, submit button, address. Address, edit text, submit button, favorite Pokemon, favorite Pokemon, edit, submit button. Voice over off. Right, so if you were not used to the way that this page was structured, it would just kind of feel like it was bouncing around all over the place. Now from a design perspective, who knows? Maybe this was the layout that you were going for, but for someone using a screen reader, it is almost certainly reading the page elements out of the order that you were intending. And so the reason why this happens is because with focus order, with screen reader focus as well, these elements or the focus order itself is following the layout of the elements in the DOM. So browser goes through, it looks at the HTML that you wrote, it generates an accessibility tree and hands that off to assistive technology. And then assistive technology is like, sweet, this is the DOM order, this is how we're flowing through things, right? And you know, this doesn't just apply to flex box either. So for instance, let's throw in some absolutely positioned children because I've seen this in a number of occasions as well. So I'll drop in like a fake newsletter type thing here. So I'm putting it high up in the DOM, right? Maybe I'm just not paying a lot of attention where I'm including this code, or maybe I'm using like a templating engine or something like that. And I'm like, well, that's cool. It's fine that it's there. Cause in CSS, I'm gonna render it later on, absolute. And I'm going to say, hey, make sure that it is absolute stuck to the bottom of the screen, right? So we go back and look at that. And I will, I'll shrink the browser window a little bit. So this all fits in the viewport okay. So you can see here now that I've got this like join our newsletter line down here. And I've got a little input field. And when I press tab, it might be a little hard to see but focus is like right here at the bottom of my screen. And now as I'm tabbing again, it like jumps back up to the top and now we're kind of reading the page in super weird order, right? So the takeaway from this is although you can reposition elements visually on screen using a CSS, when you do that, there's a very high potential that you will be throwing off the reading order of your document for folks who are using a screen reader or kind of throwing off the efficiency of the keyboarding experience for anyone who's relying primarily on a keyboard to get to the interactive controls. My sort of takeaway from this is, if you need to bring something earlier up or later in the document, you wanna position it visually different in that way, try moving it in the DOM, right? So actually go into your markup and say, okay, cool. Well, if this newsletter, if we want this to be the last thing that the user's gonna interact with, then we need to make sure that it's like the last thing in our DOM as well. I think if you follow this rule in general, you'll have an easier time. You won't end up in these situations where the keyboarding flow feels a little bit thrown off. And hopefully this is kind of a heuristic that you can just keep in your back pocket. If you want something later in the document, visually later in the document, put it later in the DOM, all right. So that is my takeaway here. Be careful reordering things. And Sarah, thank you so much for sending in that question on Twitter. If you out there, if you have any questions on Twitter, you can always ping me at atsignrob.son. That about comes out for today. So thank you all so much for watching and I'll see you next time.