 You were sat at your desk and then a real engineer stood behind you and held your hands. Maybe like the scene from Ghost now. Yeah, there's a special pair of gloves that has two, you put the gloves on, they put their hands on the top and they're tied for like, Rob, this counts as you doing it, this is, look, you're writing C++, look at you go, look at you go. I don't know how you feel about existential crises, but who are you and why? Hi, I'm Rob Dodson. I'm a developer advocate on the Chrome team and why I mainly work on accessibility and trying to sort of teach developers how to build accessible applications, make sure it's part of their daily habit when they're doing their work. I think the first one who just glosses over the why and just turns into a job description, we've gotten very weird. It's DevRel training, right? Yeah, I just reverted back to my training and it just sort of kicked in. I imagined I was on a stage and it was going badly and I just started saying my job title. We just sort of activated you there. Or bring them back to humanity. So you've been doing an edge rotation recently. I have, yeah. So what's that, like you stand in the spot and spin around with a computer? Yeah, with the other edge. It's like a spinning class. Yeah. So what I've been doing the previous quarter was actually working on Chromium, so working in C++. It's dreadful. It was, because I didn't know C++ when I started. So I learned enough C++ to be bad at it and then I started shipping code in the browser. And having other people review your code until you were... Yeah, so basically the way that works is like I put up a patch and someone goes, it's horrible. They're like down there, move it over there and I'm like here and they're like there and I'm like here and they're like yes. The funny thing was it wasn't even an engineer I knew, it was an engineer from a different browser who was just so annoyed by my bad code that they just showed up from like another continent and were like stop, do it this way. That's a long way to run. Yes. So another continent, they're at their desk, they see your code and they stand up and go no. From where? From Oslo. From Oslo. That's a long run. Yeah. That's impressive. Yeah, but it was really cool. I got to learn a lot about how Chrome actually works under the hood. So that was really interesting. I'd actually encourage like anyone who is really interested in the browser, like you can learn enough C++ to kind of get in there. And the nice thing is, this is a tip I got from another person on the team. If the code around you is written well, you can kind of like figure it out. You can kind of like muddle along and so that's the case, right? I found something that was similar to what I wanted to do and kind of just like... Copy paste. Yeah. Yeah. Let's say it's copy paste. But I find the same with web standards actually. I kind of sometimes like I'll submit a patch and the feedback would be like, why on earth have you written like this? And I was like, well, I copied and pasted it from two lines that way. So well, it's wrong. Well, I mean, how can I help being wrong in this situation? You're like, I'm new. And so like, so yeah, I was very wrong pretty much all the time. But it was pretty gratifying, like getting something behind a flag in Chrome. I mean, you're not the owner of a flag in Chrome, right? That's the thing you wrote. Yeah. The experimental web platform features flags, which is kind of like a bucket, like everything goes in there. But yeah, I'm like the owner of like a pseudo class in CSS now. That's cool. So what have you actually been implementing? So it's a CSS pseudo class called focus visible. And the way it works is it matches when focus matches and then using kind of like an internal heuristic in the browser, we determine that it would be useful for the user to see some sort of focus indicator. So typically that means like, depending on if they're using a mouse versus a keyboard to navigate the page, if you're using a mouse depending on the control, maybe you don't need to see one of like if you're clicking on a button or something like that. Right. I've had that problem before. And I feel like I've been like making things not accessible because I don't want when the user clicks with a mouse it to have that same focus style. Right. You end up like doing weird hacks like, oh, if it was if there's a mouse down at a class somewhere or something that will hide the focus styles or something. So it's now I think I can start to star focus visible focus ring and then outline. Well, there's no, I mean, you just use outline. Outline. Right. For your focus indicator. Yeah. That's outline. But isn't the focus visible used to be called focus ring. Actually. That's the same thing. Yeah. So can I do because by default the outline is like kind of blurred whether it fades out. Yeah. Can I do that? Yeah. So someone was telling me if you just do outline auto it should revert to that. But that actual sort of the blue thing that you see there is in the user agent style sheet. You can literally it's kind of cool if you just open up what is it cs.chromium.org and type in html.css. Like that is the user. That's like all the styles in the browser is that file. And it's like that's the kind of thing that I kind of got to discover on the intro rotation is you can just go in there and you'd be like, I can just change this if I want. Like you will see interesting units like the QEMs the croaky EMs. Yeah. Yeah. Weird stuff. So when you're saying it's heuristics based how did you get that through a standard? So that's actually we're still working on that. That was some of the feedback that we got which was like we want to know more about the conformance for this thing. So we're working on a patch right now to really like explain when we think it's beneficial. And so typically it's like, you know for anything kind of like where you know the user is going to be providing some keyboard input like a text field or something like that you probably always want to show it then. Whereas for something where the only action is literally like click a thing, like a button or like a slider knob or something you maybe don't want it in those cases. So it kind of depends on the intent of the interaction and everything. But in the end it's going to be left to the UI to the side. Yeah. Ultimately like so there'll be some conformance criteria that we're going to kind of recommend and hopefully everyone would follow that because yeah you would want it to be consistent because otherwise it ends up with just yet another kind of broken focus experience. Yeah, that makes sense. So you're speaking about accessibility, right? Is that focus ring or are you covering other stuff as well? Yeah, so I'm going to talk about what's new in DevTools. So there's some cool accessibility stuff that we've added there. Talk about focus visible. And then the other thing we're going to talk about in the second half, Dominic Mazzoni who is an engineer on the blink team is going to come up and talk about accessibility AOM depending on how you AOM depending on the camp that you fall in. So yeah, that's actually a way to just create your own virtual accessibility tree listen for accessibility. Let's stop there because what even is an accessibility tree? Oh, okay, yeah. So that's actually a good question. So this is something I didn't really understand for a long time. I was like, how does the browser make a screen reader say the things that it says? And it was always just kind of a mystery to me. But basically it's like you've got your HTML. Which is a tree. Right, that gets turned into DOM which developers are familiar with that. But then the browser does this one extra step where it takes the DOM and it sort of prunes out all the parts that are not semantically interesting. So if you've got a bunch of divs just for positioning things on screen, it just sort of throws us away. It builds this sparse tree of just the semantic goodies. And that's the accessibility tree and that's what actually gets handed off to assistive technology. So if I do something like area hidden then that's my instruction to say pruning out a whole chunk of the DOM from the accessibility tree. It kind of sounds similar coming from the CSS like display none which removes something from the rendering tree. It also removes it from the accessibility tree. It's so many trees. So we're actually getting access to this tree. Yeah, what you'll be able to do there's kind of a few things. You'll be able to listen to certain events that previously were only available through accessibility technology. And the other thing you can do is you want to think of it that way. That's probably really relevant for, for example, Canvas, right? Indeed, yes. Canvas. If you're building WebGL, maybe some kind of SVG that's hard to make accessible. Or maybe even just a regular DOM component. Like for the longest time it's been really, really difficult in some situations where you have something and it's almost like in Canvas it's almost like a black box. With DOM it could be just a really elaborate thing for something presentational. But now you can just hook in there and you can just say, you know what? Well, weird and elaborate, but here's the actual thing I want to be represented in the accessibility tree. Is that like a pure JavaScript API? Or are we going to be markup as well? It'll be pure JavaScript. At least initially. Okay, sure. Yeah, so it'll be all JavaScript. So one of the struggles, I think, with accessibility is getting developers to care about it. And I felt like performance is in that bucket as well. It's slightly difficult to get budget for that, even though I would say well, I think accessibility is a lot of people who get real value from it and with performance as well. With performance I feel like AMP has done a really good job of kind of taking that to businesses and saying performance is important. Making it the default, right? Yeah, what can we do for accessibility to achieve the same? Yeah, so it's tough because accessibility, because the area is really broad, some of the things fall into user experience and design, so color contrast and stuff like that, people tend to kind of like pick that up and incorporate it into their design process a little bit better. You get into other areas, though, like screen reader support in ARIA and a lot of people are like, well, that's not my problem, right? It's sort of out of sight, out of mind. If it's not something that's directly affecting the developer, they kind of just don't care about it. So I think what has been really successful for a lot of teams has been doing a more inclusive design approach, so making sure that you're bringing in people who may have disabilities or impairments into the design phase, into the product testing phase, and, you know, even like also making sure that those people that, like, you're employing those folks on your team even, that engineers on your team, like, might have disabilities and things like that, because it doesn't work for literally the engineer on the team, like, it's not going to ship, right? And so we need to just, like, I think in general do a better job of, like, including more people in our design practice. And as a result, hopefully it just becomes something that everyone just does as part of their kind of their daily habit. Well, thank you so much for joining us. Good luck with your talk. And... Something? You can't do that. You can't really look at me and just say, you don't finish this. I think I totally messed you up. I was like, thank you for having me. That's fine. That's fine. Do you want to try that again? No, we're just going to leave this. It's the ending now. We're going to keep dragging out, like, into the rings. So many endings. When is your talk? It's soon, right? So we're just going to go straight... This ending is going to last straight into the talk. Okay, that's good. All right.