Coding with Jon: Let's Build a Website! | episode 7

Sam.

Sorry, I didn't catch that. The countdown ended. Hello world. Happy Friday. I'm John McLaren. I've traded the Top Gun Maverick costume for a HubSpot developer shirt again this week. I'm excited because today I'm joined by AJ Laporte, who will be speaking at Inbound this year. Congrats. Also, happy 5 year HubSpot aversary. AJ and I competed for the same job, had lunch together after our interviews, and went, man, it'd be so cool if we could work together. Magic happened and they found a way to hire us both. You may also recognize another friendly face. You might know her from past videos on the HubSpot developer YouTube channel. Tanya Scales is the tech lead on our CMS developer tooling team. Tanya's been around HubSpot just about as long as AJ and I and has been a powerhouse behind efforts to make Hubs HubSpot default modules accessible, make the boilerplate accessible, help design, module and theme fields so it's easy for developers to maintain accessibility and a whole lot more not related to accessibility. I highlighted her accessibility efforts because Tanya's IAAP CPA CC was and CPWA C certified. That Alphabet soup basically means anytime we're talking web accessibility, Tanya knows way more than AJ and I. I think we.

Can also add goat. Right?

Goat.

Is that. Is that. Is that what?

Correct? Indeed. So we thought it would be fun and likely a little enlightening to have Tanya join us today. We're going to talk about website accessibility as we go over the new developers homepage. As always, this is unscripted. We may encounter bugs. That's okay because we'll squash them together and if we can't, we'll get blame them on Anton. He did contribute code to the site after all. I'm just kidding. Anton, again, thank you so much for contributing the Morse code part of the site. It's one of my favorite features. With that said, I thought maybe. Maybe we'll start this off by talking a little bit about what tools exist for testing accessibility or what our process might be. So feel free to chime in. Tanya, My go to that I start with first personally is I tend to use voiceover on my Mac as I'm actively developing and then when I'm towards the end of building a project, I run through it again. But there's also tools like acts. What. What other steps do you usually think about?

Yeah, I think voiceover is good, especially if you're on a Mac. The I would say it's a good tool if you're using a Mac. What's unfortunate about it is it's not the most widely used screen reader software. So you kind of are at a disadvantage. Every screen reader software just to kind of. We're just like diving into a topic here. Every screen reader software there are little nuances in the way that they actually describe anything on the page to users. So you kind of miss out on maybe like a larger market of users if you're just testing in. Voiceover however, it is a very good tool to get started and just make sure you're like getting some of those fundamentals right. So Voiceover I do like and I do use during development I use apps for sure because I do think it gives you very good and detailed insight into what the problems are, why they're a problem and maybe how to fix it. And then one other one that I like to mention just because I think it's interesting and it kind of gives you like a almost like a like the experience that you would need. Kind of like if you're just like an able bodied person and you don't have any disabilities, you might not understand what people are experiencing as they view your website. So one of the other ones I like is, it's called, it's a chrome extension. It's called Web Disability Simulator. And what's interesting about it is you can simulate disabilities with it site disabilities. There's like mobility like Parkinson's has. You can simulate dyslexia and then just like there's also one for like concentration issues and you can kind of just see like if your, if your page is really busy and somebody has like you know, autism or ADHD or something like that kind of use your screen. You can kind of just like get a feel for what's going on. So I like that one just because I think it's like a cool way to like try to understand and empathize with folks who like are experiencing websites a little differently.

That's awesome. You kind of reminded me that web Accessibility Simulator 1 reminded me. I'm attempt to quickly find a bookmark that I have. I didn't think about using this ahead of time so one moment, I will try to run this on. I actually don't know if ARC supports bookmarklets so. One second. Styles I'm going to pull up while you're doing that.

John, let me ask this question. Tanya, I'd love to love to hear what your opinion is on this. There's a lot of softwares out there that are like put this embed widget on your site and get free accessibility on it now. I mean personally I've seen it go great and I've seen it go horribly wrong. Like what, what's your opinion on that? Like do you think it's like, do you think it's better to just build with accessibility in mind when you're building or just, you know, if you're in a bind, just go ahead, slap one of those tools and you're good to go.

You're gonna, you just ask like the, the spiciest question for me, like the first thing I'm gonna get hot here. So no, I, I personally and I think a lot of the community who is really passionate about accessibility will say that they don't really agree with or like those kinds of tools because obviously you definitely should think about accessibility as you're building initially. And I know it's super understandable why those tools look really enticing because you can, you can slap it on there and it'll do certain things. And so I want to like grain of salt this in the sense that if you have, if you have zero accessibility going on on your website, if it's just not even existent, putting that on there is, is going to help. So like there it has its place and it certainly can help folks who are like, are going to struggle on your website if you just do nothing. But it is not to me it is just not the best way to make sure that you're actually like thinking about that from the get go and that you're thinking about all experiences. Some of those, you know, depending on which tools you're using, some of them are good, some of them are not that great. And, and I think like, just from like a holistic standpoint, it's almost like I want to say like separating out folks who have like different abilities. Like if you're, you know, if you're differently able, you, you know, you have to use this tool. Like we're not going to like think about that. You know, you go ahead and use the tool and it'll help you out. So like, like separate, kind of separate but equal is like what comes to mind. And so like we like, we just want to get rid of that, right? So like just starting from the get go, starting with accessibility in mind and coding that way is going to create such a better experience not only in like the code and the output to like a screen reader or things like that, but it really does affect like the overall UX and, and like user flow. It really helps like when you start thinking about accessibility just in general. And so I just think like, it's just a much better path to go that way than to slap a tool on there. So I think that's my. I'll cut it there. Because I could go on. I'll cut it there. But that's my, my opinion on that.

No, I fully agree.

I 100% agree. I also, I don't know if you might have. Also I signed up. There's a website about this specific topic and there's a list of industry folks who have basically signed to say like, hey, we all consistently agree on like, these are the cons here. Here's what we'd rather see kind of a thing.

Yeah, I should find that link and put that up because it's a good, it's a good read and it kind of gets everybody's thoughts together. It's like why you shouldn't depend on that as your long term solution. So I'll look that up while we keep talking.

Awesome. I will bring up, because you had brought up the disability simulator I've enabled on the developer site, this is a bookmarklet that I've used. Now this isn't perfect. This is, this is not the experience that everyone has, but it gives helps, helps for folks who do not have specifically dyslexia to at least get a somewhat approximation of what the feeling of dyslexia can give you. So as you can see, like it feels like the letters are jumbling around. It's still the right letters, they're just in the wrong places. That's not a true translation. It's really hard to simulate what dyslexia actually looks like for a person. But what it does let you do is it lets you identify situations where say if you're using really big words and you're not using icons, then you'll notice that things become really hard to read. So we've got some big words at the top. Like creatively, brilliantly and thankfully we have this little globe here. But even the word English for our language dropdown can be a bit hard to understand. So it's again, this is not a perfect simulation. It's just something that can help you to be like identify. Here's some probable areas where we could improve them and some improvements that, that specifically help with dyslexia is using things like colors, using, using icons and, and watching your font sizing and the word choice that you actually use. So just wanted to throw that one out there because I like it. There's, there's also built Into Chrome itself. There are some accessibility tools. Let me move this. I might already have them showing. Let me click here. I'm drawing a blank on it at the moment, but that's all right. There are accessibility tools built into Chrome and basically they let you, you know, what it might show here now. There we go. So they have some things like enabling you to see the accessibility Tree. I find that the accessibility tree is helpful, but it's not. If you don't know what you're looking at, it can be a little bit confusing. And so I still try to use like Voiceover or, or a screen reader to identify the things that it's talking about so I can understand it better. But also built into like Lighthouse is some very basic accessibility tools. I do want to caution something very important with using LightHouse or Google PageSpeed or using Web.Dev. the automated tests that are done for accessibility are extremely simple ones. They're not as complicated as what Axe can do. And there's also some accessibility tests that you can't automated. You can't solve in an automated fashion. You can't identify them in an automated fashion.

Yeah, definitely. Yeah. Even with Axe, which is like a little better at doing some automation. And they've really worked hard to continually add to their automation and try to, you know, cover even more surface area. Manual testing is just an absolute necessity. If you're actually looking for some kind of level of wcag, like double A. A lot of the automated testing covers level A issues generally. Maybe you'll get, especially with Axe, you probably get some like level two, maybe even level three, like issues out of it. But it's, it's definitely not a full coverage tool. So, yeah, using voiceover or something else, some manifesting or some folks find, you know, running through screen readers themselves and doing that is kind of a, like a burden in the sense, like, of learning the tool. How do you navigate around? How do you understand. Do you understand how to use it in the same way that an actual screen reader user is going through a website? It is a little bit. Take some time to kind of get used to doing that. And again, you're kind of, you know, if you're using voiceover, you're kind of like in one market of a screen reader. So if you work for a company or you have the budget, there's definitely services out there where you can go and have folks who have disabilities who have, who use a screen reader that primarily will test your website or your pages or whatever you need. And so you can kind of get that Manual testing. That way if doing it yourself is not possible.

100% agree. One more thing that I do want to call out as another thing that. Another way of testing. It's not, it's not necessarily drastically better or worse, but then using a tool like voiceover, etc. But it's something that I like to learning, I enjoy learning how to use. And also I think it helps you to see the differences between the different text to speech type utilities that exist. So there's Voiceover on Mac, but on Android for example, there's something called Talkback and I will temporarily enable it and I will show my screen up there. Talk back on live demo and I will pull down.

Double tap and hold to long press.

We can put that up. I will. This is not the best way of showing this. Obviously had I thought this through better I'd have found a way to screen share it. But what you can do is basically experiences with powerful tools and special gestures for controlling your phone without needing to look at the screen. And these are for people, they're mostly for people who have vision impairments or are fully blind. And it does the same thing as something like Voiceover. However, it can give you a different angle on the experience. If for example you tested your entire website, like your menu, navigation and everything on desktop, it works great. Then you go to mobile and then you completely forgot to optimize your menu for accessibility. As soon as you run this test you're going to be like oh, this is embarrassing and, but otherwise there's. I, I'm drawing a blank on his name right now, unfortunately. Let me turn that off for now. Sorry. So there are adjusters that, that you can learn to navigate and work your entire phone without needing to see the screen. But I learned about that in kind of a funny way through. There is a YouTuber. I'm drawing a blank on his name right now unfortunately. But is one of his YouTube channels he has multiple. One is called the Blind Film Critic. Uh, he's a, he's a very joyous, uh, like infectiously joyous person. And his channel, his YouTube channel there is about literally reviewing modern movies as someone who is blind and going to the theater. And so he has interesting and sometimes humorous perspectives on scenes and everything. But the. Just as he explained one time that he was on a bus and he was using his phone, obviously he doesn't need to see the screen. So one of the accessibility features is if you are using Talkback or the iOS equivalent, you can make it so that your screen is completely black. And you can have the audio go through your earbuds. And so he was sitting there swiping and double tapping on his phone to control his phone. And somebody on the bus got very confused and offered to try to help him use his phone because they thought that it was broken. They thought he didn't know what he was doing. That funny story. And that ended up interesting me because I was like, that'd be kind of fun to learn how to do that anyways. But anyway, if you're not trying to do that and you're trying to do serious work, like do some accessibility testing, it's good to get familiar with more than just one voice to text or text to. Yeah, voice assistance tools. Anyhow, I think maybe it would be a good idea to give a slight taste of what it looks like to test the homepage using voiceover and then we can check out Axe as well and identify some problems. So this is going to be a little interesting for you, Tanya, have you ever. Have you ever done drop down menus in a website and made sure that the site was accessible without using JavaScript?

I think so. Because you can, you can use just pure CSS to get there, can't you? Like, I saw you some of your code markup for popover now. Yeah.

Yeah. Okay, so you're aware of it. All right. I don't get to surprise you, but I don't.

I don't want to be caught off guard on the live stream here. So. Yeah, I like that.

So, yes, the gist is that previously, if you did a pure CSS menu, one of the cons was that, yes, the tab order when you're tabbing. So I will turn on Voiceover for a moment and I will pause it because it will get annoying for us. Hopefully you guys can hear that. Are you able to hear that?

No, I don't think your audio is coming through.

Oh, okay. Let me attempt to.

So while you're working to fix that, Tanya, going back real quick, you said something that I think definitely would help people understand. So you mentioned like, oh, level one, level two, there's, you know, there's double A, there's aaa. Can you quickly run through what those levels mean? Because from what, from my understanding, like, double A is pretty much like the baseline that everybody should try and get to. And then like government and things like that need aaa. But if you could just quickly give a quick overview of the different levels, I think that would help anybody who's listening who's probably not aware that there are actually different levels. Of accessibility that you can meet.

Yeah, hard question right off the bat, there's.

Oh, I just, I like it because it's like, oh, but you know, how many directions can I take this in? Okay, so I don't know the experience level of the audience with accessibility and general accessibility knowledge. So let's like, we'll bring it all the way back down. So accessibility. There is a. There's a group called the W3C who has made guidelines. Basically, it's basically an international standard at this point that has all these very, very technical, like documents. It's called the wcag, in order to explain how elements of a website should. Should work for keyboard screen readers and just in general for folks with disabilities. So they kind of spell this out. It's very technical. And there's different levels inside of that, those guidelines that you could comply with. And so there's level A, double A, triple A. So they're really, really the levels are, I would say, just kind of a, like a threshold of accessibility compliance and like how, like how good you're doing and like actually offering some kind of accessibility features inside your website. So. So a really takes care of very, I would say like very foundational items on a website. Color contrast, making sure that you're like, link text, like, or your links have text really like, you know, we go back to like where there are links that maybe just wrap around the word like here, right? So you like click here, right? And so like, there's no good indication as to where that's going. So like, things like that, very basic, like, you can correct this. That's like level A. The reason why AA gets talked about a lot is because it is now basically accepted as the threshold of accessibility compliance for a lot of like, legal matters. So I think this is probably still the case, but I think a lot of folks and companies, especially larger companies, start finding their way into accessibility because, you know, they're. They're possibly getting like sued or there's some kind of legal implication. And so they start looking into this. And double A is generally the measure at which a website or app is, is graded against in order to make sure that they are in compliance. And then AAA is like a. It's just kind of like, I would say it's a very high bar for accessibility. It does require a lot of very detailed technical work to make sure that you're meeting it. And so. And it doesn't. There are certain things that like, don't apply to maybe everybody's website. So. And I can find some AAA I discussed in a while since I've done looked at the AAA level in terms of like what little items are on there.

Thank you.

Let's see.

Because I remember we did where I used to work, we had a client who was getting sued and they were a financial institution and it was like AAA is what we needed to hit. And I just remember that was a lot of work that we did and it paid off for sure. Like it was, it was worth it in the end. But I learned so much after having done that where it was things that I never would have thought about.

Yeah, it gets really, really deep and yeah. So if you're like a financial institution sometimes health care, things like that they like they require or they want a triple A level compliance just because of the nature of the business. And so yeah, it can, it can depend on what. And that's. I think that's why generally most websites, most companies are you know, covered under the. The double A requirements. And then sometimes you might find yourself in a AAA scenario. So.

100%. And something that I like to highlight is like your motivation for making your site should not just be trying to meet the minimum legal requirements. It should be to simply provide a good user experience for everyone. Because the, the experience that you provide, like if you're adding ARIA text, aria labels, etc. If you are making it so that a page can be keyboard navigable. So for example this site is keyboard navigable. You can open the dropdowns, etc. Even the like the language picker, etc. This is arc being fun was doing that. But having that sort of experience means that even power users will get some benefit out of it. So I don't have a form on the homepage right now, but forms are space where folks who are not relying on keyboard navigation normally might use it heavily. Like I use tab to jump between every form field and it just is faster than using my mouse. And certain things these might be AAA sort of experience. I'm not sure but for example adding convenience things to make it so that people can skip annoying or possibly annoying functionality in your page. Like. Like we have a slider here that if you're using keyboard navigation, you'll be given the option to skip the slider carousel. And I. I'm going to try and do voiceover again. I don't know if it's going to work. We will see if the audio comes through. Are you able to hear that? Nope. No. All right. It was a nice attempt. I can at least make the make the thing appear and I will just be the only one listening to it, I guess. Let's see. I will share my screen one more time, and you should be able to, once I do this, to see the. All right. Now, if I do it, it'll be annoying for me, but can you see? Yep. It looks like you can see it.

Yes.

So I apologize if I pause while I'm. While I'm talking about this, just because in my ears, I'm hearing everything you see here, like, vocally said to me. But, for example, and now it's not doing it. So a con that I've found with. With some screen readers, like voiceover, is sometimes they will get outside of a browser tab and they will. It'll be really hard to get yourself back into it. So maybe if I just.

I would try closing Inspector. I know when I've done it in the past, the Inspector being open for some reason has just caused it to go haywire for me.

While John's navigating. A.J. i just want to let you know, for whatever reason, I can't sign into the actual chat area, but I put a couple comments into private chat for us of the links from earlier, if you want to push those over.

Absolutely.

Thank you.

All right, well, it appears I'm not going to be able to demo that like I wanted to, which is unfortunate. And now my screen's being wonky. Great. All right, here, let me pull it up on Chrome because maybe that will make it work. Oops, wrong button. Don't.

Don't tell Dennis that you're doing that. Okay.

Yeah, Dennis is very much a arc fan. All right, let me try one more time. There we go. Now it's working. All right, so while trying to demo this, I just found a problem in our website. We have this grid. Sorry, it's really hard to try and talk over the voiceover thing in my ear because it's also very loud. We have this horizontal grid thing of. Of these different community places, and we have these Learn more links. So learn more is. And read more links. If you ever see them, it is a wonderful idea to look at them and make sure that you are providing some descriptive text. So you can have it visually show Learn more, but you can make it so that there is a screen reader only addition to that text. So it is coded into this module, but it's not set as my default values for the module we have if I inspect. Okay, I have to turn that off because hearing code read out aloud is a lot. What you can see inside of these anchors and just so you can see the Learn more link on screen. We have a hidden span here. There's actually a field inside of our module where you can specify what text should be added after the word Learn more. So learn more about something. So in this case we might actually not even use Learn more because the word is forum. So the text might be something like go to the forums for the screen reader only text. And I don't know what the visible text would be for it. But here's a better example. We have these videos, we have this content here, so we have some academy lessons, so we know what the title of the lesson is. But when you are tabbing through here and you get down to here, this is the link. But then when you get to start here, all that's read aloud to the user is Start here. That's kind of useless because if you have four start heres, how does the user know what they're getting at? Thankfully, in this case, they are seeing this other link ahead of time, but this is still not a great experience. So you can use that same trick of doing some screen reader only text inside of your links and then just put the title of whatever the content was. So it could be like start. And then we could remove the word here. We could have it just say start and then learning about developing scalable HubSpot solutions, for example. And this also kind of ties into one of my biggest pet peeves. We've actually already implemented this here. So I'll show you a good working solution. Because we knew what the titles would be for the blog, the screen reader text automatically gets populated. So we've got the Read more link that everyone can see. And then it adds after that text, screen reader text, which goes about the. And then it's the title of what the post is. And then we add the word change so that it actually makes like it makes sense as someone would read it out to you. So that's one positive way of implementing it. And this also gets into one of my biggest pet peeves ever, which is Click here Text wrote a lengthy section about that in our accessibility doc. If you've never seen this doc, you should come here for sure. Both Tanya and I have contributed a lot to it, and there's also links to our past content on accessibility as well. But let's see. Click here. I specifically had some content in here. The basic gist is if you've ever got a link that says click here, you should rewrite it completely. That's my hot take. But basically, if you are tabbing through your site and you have the screen reader on and you hear click here. There's a few things that are weird with that. What if you did that on your cell phone? Your click here, it should be tap probably. But the other part is, what am I clicking? I don't know what I'm going to. Why do I want to go to this link? All I know is click here. So change it to be something that's usually like my. My trick for. For figuring out what this text should be is I try to think of the action the person is taking. What am I clicking? I don't know what I'm going to. Why do I want to go to this link? All I know is click, click here. So change it to be something that's usually like. My trick for figuring out what this text should be is I try to think of the action the person is taking. So going to a page about accessibility or if it's a link to something in our app, for example, open X screen in HubSpot, for example, doing things that are more descriptive of what the user's intent is rather than just simply click here. It's also better for SEO because, I mean, if a search engine sees click here, all they got out of you was the URL, not the context that you're using it in. Just.

Yeah, I was gonna say, I can see by the way that the language is written on this particular item how like frustrated you are by seeing that all the time. Don't do this, please. I think I want to add one thing which is like, so some. A question might come up, like, okay, clearly the link, like, if you're having. If you like an article, like maybe the title, there's like a link and then underneath it says read more. And so the thought might be, well, they just heard the title of this article, so correlate the two. Isn't that something that could naturally happen? And yes, I'm sure it could be. I think especially Screen Reader users, when they encounter a site that isn't accessible, there's adaptability there where they can see patterns that have happened previously. But one of the things that I wanted to call out is that the way that a user with Screen Reader navigates a website is not top to bottom all the time. They might, they might scan through it that way just to kind of get some context. But a lot of like, power users will use what's called the rotor inside of a screen reader, and it allows you to jump around a page by heading, by links, by images, by articles, so like, there's a lot of different ways they could touch that link. And in the context of the rotor, if you look at a list of links, it'll just say, you know, the title of those links. And so, you know, you can start going through a site and it's like actual link contact. Right. Something that makes sense, makes sense, makes sense. And then all of a sudden you click here, click here, click here, click here, and there's just nothing, there's just nothing they can do with that. So I just think understanding how a screen reader user navigates is also helpful to like understand why this is always such an issue. For as like one of the baseline, again, this is like a level A, I think technique in order to like get gain compliance is, is link text and making sure that it is coherent. It describes the purpose of the link. And then I think like one other minor like call out is indicating a link. So like we're talking about folks maybe are visually impaired or fully blind using a screen reader. But even folks who have a visual impairment, but they still actually view the screen and look through it, it can be hard sometimes to discern. If you don't have, let's say like an underline, you're not actually visually indicating a link. It can be hard for them to peel that out of a page too. So I think like, there's a text aspect to it and there is also a visual aspect to it. And again, if you go into WCAG and you look at like the link text or link purpose technique, you can kind of see like they do spell out like the visual aspects that should be complied with as well. So.

I've always been a big proponent of underlines should be specifically held for links unless it's like large decorative texts in like heading banners or something like that. But like, if you, if you're in body text, I would always recommend, like, don't just underline things because like you see like those not to call them out, but like those promotional landing pages that people make that are like, buy this, it's free 100 this. Like you're not doing any service to anybody by just underlining a bunch of text on a page because you are going to visually confuse people. Even people without disabilities, like, will be like, well, what do I click here? Everything looks like a link. So I've always been under that impression too of underlines should always apply to links within text.

Yeah. As you're starting to code out a website, obviously there's a very common technique to use a reset. Resets the styles of all the browser things. I haven't used a CSS reset in a little bit, I'll be honest. But if this is still a problem before when you use a reset, it would always remove the underline that was standard. Just remove underlines from links and make it very like, just like a color indication. So I think you want to be careful if you're using resets, you know, make sure you're adding like those underlines back in for the visual indication.

That's a good call up. I, I do actually, because we are talking about visual visual stuff at the moment and I think that like I saw this particular item show up on, on this page as well as the one right up above it. So we, we did implement and I want an opinion this does not have to be fact. You do not have to worry about like, like the verdict being 100% correct here. I have a feeling the answer is that it's unfortunately a subjective thing anyways. So with that said, what I'm getting at is we did something for the homepage. We made it so that when you load this page there is a subtle. Hopefully you can see it on the screen. There is a subtle little animation to the Morse code. Now, it may already not be a huge deal, so. So the first requirement that we have on here is avoid animations that flash rapidly more than three times per second. We are definitely not, I would say that we are not meeting that we are only once going over each thing. We're not looping. And the other side of this being that it's kind of a subtle animation, it doesn't even show up sometimes when I screen share it. But something we are also doing is you have to, if you're going to do animations you should be using prefers reduced motion. This is a media query and I will pull up the code. Actually for that module, we went an entire almost 45ish minutes without ever looking at. Well, I guess we looked at code once, but.

I knew it.

So I'm okay with that. It was all good, good stuff. But let me close everything else. Close all. There we go. Okay, so we have. Okay, so this is something that I could be wrong. This is something I read and it could be wrong. But someone recently who I. I wish I remembered their name at the moment. I'm bad at that apparently. But. But they, they, they put out a blog post saying that prefers reduced motion should not mean no motion at all. And I thought that was an interesting take because every tutorial you ever see online about prefers Reduced motion. Most of the time people just go, nope, we're done. We're. We're just going to make it so that for anyone who has this preference, they don't get any kind of behavior like that. And so what I did with this was I made it so that if you do not have that preference of prefers reduced motion, you'll get the scaling effect. And if you do have that enabled, all you see is that the brightness changes on those dialogue dots. And I can trigger this by going like this and commenting this out. Save and then we'll reload the page. I do need to make sure that I have watch running because I don't actually remember. I don't. So I will quickly run that wrong one. Let's see if this one's got it. No. All right. It is NPM run Watch page. Hopefully I'm in the right folder. All right, all right. Now if I save source is not. Oh, I'm in the wrong directory. Cd like I said, we're doing it all live. There's no script to this.

No judgment.

Not what in the world.

Well, you figure that out, I'll start talking. I just look at this because I've actually not heard of perverse reduced motion. I think it's really interesting because it does say that it is to minimize the amount of essential motion. So it's not. I would agree that it is not to remove all motion on a page, but you want to minimize the amount of motion. And I think one thing that you have to do, again, as you're always doing accessibility work, try to understand the root cause of why that is. Why is it that we're reducing motion, inner ear conditions, vestibular motion disorders. So this is like, you know, somebody has an inner issue, might have a problem like a balance and things like that. If they see kind of this motion, maybe like a pulsating motion similar to this, like can cause problems for them when viewing a website. And so you know, if you reduce that motion or you change it like John is here to more of like a flash, which I. So, you know, you got to be careful about creating a flash, right? But create a gentle like motion will help those users for your website. And I think this just highlights how deep that you can go when you really start thinking about all the different users of your website and like who they are and what they are experiencing. And like this one little thing about like prefers reduced motion could be so huge for somebody trying to be your website. And like, you just don't even think about it. Because it's this cool little animation you're using in the Morse code. And like it doesn't look like wild, but you just don't know until you can like really understand. So I think like, it's just, it's important to kind of like read up, read up more about like that kind of stuff.

100 agree. Yeah, I, I thought that was an interesting take that, that they had and, and I was like, you know, I would rather like if, if that's the guidance that people have been giving in tutorials of just be like, okay, well you get a worse experience or a less joyful experience because you made this preference choice because you have some sort of vestibular condition or other condition that it would make it hard for you to work the websites and everything. It's like, well then every site you see is going to feel bland and not have this sort of little joyful touch to it. So when you do see something that's subtle and isn't interrupting you, then I feel like it would be a very positive feeling to be like, oh, look at that kind of thing. So anyways, thought that was a interesting little touch. Well, we are very close to time and I know that AJ's got a, a hard stop soon. I might get your thoughts on one more thing getting free work out of you and, and I probably should have brought it up before we did the stream so you could actually look into it more. I'm doing something unique with our footer here and it's okay if you don't know the answer, but so what I'm doing with our footer, it's easier to show mobile. So mobile's not totally finished, so don't complain about how it looks yet. There's some horizontal issues but. But it just is on mobile we have these drop downs and yes, I will put the little chevron thing. Actually, to be honest, I think the chevron's hiding off in the white space. So I got things to fix. But so the reason I'm bringing John. We're good. Yeah. That in it and of itself is an accessibility issue. So anyway, the way that these are implemented is using details and summary elements and I did that because I wanted to use as little JavaScript as I can. This is not the fastest way to get my keyboard navigation going down here. Focus. I mean. But anyways, I wanted to make sure that two things. When you're using a screen reader, you can hear that this is a group of links. You can. When I do enable the screen reader, you do hear what is the summary, which is our products in this case. And then you get given the set of links. This part is all accessible. It handles whether it's open and closed. Well, the question, though is not that I apologize if you're like, summary in details problems, Google search switch. The real issue is this. So the way that I did it is I was like, well, I don't want to make it so that on desktop, there's completely different code being used to display this. So here's what I did, and I'm hoping that this does not bite me. I. So first off, you can tab. You can. You can keyboard navigate through these. Except for the headings here. The headings are not links, but you can keyboard navigate through these. And the details elements are forced open. So I'll show what that actually looks like, like in the code. But okay, so literally I'm going, if you're on desktop, then we're making it so that all of the details elements are forced open and you can't close them. And this is. This is probably the most sketch part of this is I'm making it the tab index on the summary element, which is this becomes a negative one, so it gets ignored. That part's probably the part that's not ideal. But I'm wondering what your general opinion might be on how this works.

So my question is regarding the way, like a screen reader would read this is does it see that our products at all. Does it read that still for a screen reader? So because it is a details and summary, that. That's my first question, I think. And then tab index. I always get a little weary about tab index and changing a tab index. Unless, like, you're being very, like, it's very clear why you're doing it. And so, like, I worry about. I'm trying to, like, look at your code here. See tab index on the summary itself. No, you're good. I have it open on my own screen too, just to kind of poke around. Details open. Yeah, I guess I would wonder, like. So I would have to test. This is where I'm like, in my mind, I'm like, okay, I'm gonna test a bit. Because what I. What I would be worried about is I would want to make sure that the, like, the heading is for screen reader user, so that it does still give them that sense of like a grouping. So our products. And then it kind of goes into the links and they can dive into it. And then in terms of the way that the details and summary elements are read, your screen reader Is there any. I would, I would wonder if there's like any unique characteristics that are, are read out loud. So maybe, and maybe you know something? I don't want you to open voiceover because I know it's so hard. Oh, there you go.

Okay, I'll turn it, I'll turn it off then.

Okay. I just want us like, like, does it like, is there like, you know, sometimes when you use certain elements. So for example, like details and summary, you can say, you know, group our products, open summary our products links. 5. So I'm just curious like what is the language being used? And so I just like, I would want to read through that and make sure it makes like a coherent like sense. And then. Yeah, so that would be the only thing I'm worried. Obviously tab index is for keyboard users, but if a like a screen reader user isn't able to like tab like get themselves to that text in any way and it's kind of being read to them, but it's not like there. I don't know if that's like confusing. So that's like the interaction that I would be looking at and trying to see like how is this working out? So I won't like shame you. And I'm not gonna like be like, this is great. It's just kind of like those are the things I think that you might want to like, just test and just make sure.

John, how dare you.

No, I'm just kidding.

Details and summary. What is this? No, from what I can see, from.

What I was seeing and naturally, you know, grain of salt kind of stuff, like it's stack overflow. But you know, like from a quick Google search, it looks like it only means that the items only focusable programmatically. So according to this person's example, if somebody's using a screen reader navigating by H1 to H6, adding a tab index of negative one isn't going to make a difference as it's not really focusable anyways when tabbing through. But if you added like area hidden true, naturally that would just, it would completely ignore it altogether.

I think this may be a unique case in the sense that so technically these are not true headings. And the reason that it's not a true heading is because this was a kind of a mistake by the W3C initially when they came out with detailed summary. If you put a heading inside of a summary, it doesn't get treated as a heading, which I get why it's technically going to act as a button basically so that's why I chose not to do that. But it does still get read out in a in a way that makes sense to a screen reader user when they're on mobile. On desktop, what happens is it will currently skip the R products text and I have a possible solution to it that does not cause the summary to become focusable again and be something that someone can try to activate. It's not a great solution, but potentially what I could do is make it so that the unordered list element on desktop gets an aria label of what that text is so that they're still given the context and that that list is related to that heading. Basically that would be a workaround.

Yeah.

Yeah, that's. That's the cheating JavaScript and not making a not not recoding an element that already exists solution may not be the simplest way of doing it. But yeah, with that said, we are at time so I do want to encourage anyone who has not been to this page, the accessibility page in our docs to check it out. It is not a end all, be all for everything accessibility. As Tanya definitely knows, there is a whole lot deeper that you can get on accessibility. There are certifications out there, there are courses, etc. Our job with with this page is not to give you all of that all at once. The goal is to give you a good foundation to jump off into more deeper learning and also help you to build a more accessible site on top of HubSpot. So most accessibility things, just like with website performance, are not HubSpot specific. You can the same problems exist like the same things that you have to tackle exist on all web platforms as well as if you were to just manually write HTML, CSS and JavaScript. You have to think about all of these things. So with that said, I believe AJ's dropped the doc in the in the slack or not. Wow, I'm used to that.

John, do you want to. You want to call out the boilerplate and the accessibility that's built into the boilerplate?

Yep. So the HubSpot. Whoa. Lost my window. That is weird. Okay. All right. The HubSpot developer spoiler plate. I want to actually check something here. HubSpot. So we used to display on here. I don't remember if it was on this page. I think it's on the readme. So we, we do a. We have a greater score and a Lighthouse score. So you can see the page speed score as well as it's giving the Accessibility Score 3 through Google Lighthouse. So you know that you are starting from a Good foundation to start building from. Which means if there are any problems, like on in my case, where I've invented problems, here it is on you. You should test and make sure to solve them. Again, these are the resources that we were talking about. There's tons of great ones. There's the Web Disability simulator. There's also built into Google Chrome some different simulators and emulators for things like the different forms of colorblindness, which, if you didn't know, colorblindness does not mean just the folks generally just see black and white is way more a broader spectrum of color colorblindness than that. And you should be testing your color contrast and making sure that text is readable. So if there's anything else that you think is worth calling out Tanya or aj Absolutely, go for it.

No, I think that's a good start. Again, I think for folks that are just starting to even understand or want to understand more, I think there's a ton of good resources out there. I always love hyping up Deque de Q U E because they do a lot. They have a lot of resources, a lot of webinars. They have an accessibility conference they put on virtually every year. It's just a really amazing resource. So I would start. I think they do things in such a digestible way for folks that are starting. And then as you're really trying to implement, just go straight to wcag, the WCAG guidelines, and start reading some of that, I think is a good resource. And then I'll plug myself. I am on the HubSpot developer Slack, so if anybody has questions, I know there's an accessibility channel, please ping me. It's just my. My full name, Tanya Scales altogether as my username. So I'm on there. I do have notifications set up, so please, please chat with me if you have any questions.

Sweet. And. And do not expect Tanya to do all of your accessibility work for you. She is answering questions out of the goodness of her heart and because she loves and cares about accessibility. So just.

Yeah, I'll get sucked in. Don't take advantage of me, please. Yeah.

All right. A.J. anything from you or. No, no.

I mean, like we said, I was going to call out the developer Slack Accessibility Channel. Batan, you just nailed that one. 100%. I know for me, for people that use Mac, I use an app called Contrasty that is pretty awesome when it comes to, like color contrast checking and the fact that I can open up like 15 little swatches. It starts looking like a Home Depot. Eventually on my screen because I have so many of them open all at once. But it's pretty awesome, honestly. Definitely make use of your accessibility tools. And always, even though you may think your business isn't affected, like, definitely always try and work with accessibility in mind. Because, I mean, as we've said, there's many different types out there. It's not just visual, it's not just auditory, it's fine motor skills. It's things like that. I know back when I started with accessibility, I just immediately went to, oh, people that can't sit. And, you know, since being in the world of web and learning more and more, it's really become something that we're very passionate about. At least I know on the advocacy team, we're all about, every time we go to do something, we think of accessibility as one of the top things.

So, yeah, just chiming because you mentioned that one last thing. So something that I did at the beginning of this stream was I actually called out what I was wearing and that I was not wearing the same outfit as the previous time. And you might hear that from other talks. You might hear that at inbound, you might hear that in your day to day. Like any. Anything you watch or hear, you might hear someone do that. And what that person is doing is basically paying respect to folks who cannot visually see them. It's also great for, like, don't even think of it as something specific for someone who is blind, for example, because it is. Accessibility is not always about a disability. It is about enabling everybody to have a better experience. And so one positive experience that someone could have is, for example, if I listen to podcasts when I'm out mowing my lawn. And oftentimes they are actually in video form, but I'm not looking at the video, I'm just listening to it. And so getting some kind of reference like that is kind of nice. So, yeah, just thought I'd throw that in. With that said, thank you all for watching. I hope you learned something. I learned some things. I've got some work to do on this site. Happy Friday. Thank you, Tanya. Thank you, aj. Have a good weekend, everyone.

Thanks.