Making Your JAMstack Site Accessible.

[amazonv]

Making Your JAMstack Site Accessible.

Type: Breakout

Track: Development

Let’s talk about the JAMstack. It’s cutting-edge. It’s performant. But what about accessibility? Answer: It’s as accessible as you make it. In this talk, we will explore the JAMstack ecosystem and introduce the tools that exist to ensure that your sites are accessible as can be.

 

Accessible Slides: https://axecon.latte.dog/

 

 

>> We have got some people chiming in saying they're very excited for this session. Well, I think we're ready to get started here. Hello, everyone. We're so excited you're here. My name is Brandy from Deque.

>> Hello everyone, we're so excited that you're here.

>> So sorry, everyone. Having just a little bit of technical difficulty. I think we're good now. We are going to go ahead and get started. As I was  saying, I'm Brandy from Deque, I'll be moderating the making your JAMstack accessible. First, today's session is being recorded and will be hosted on demand for registrants. Second, slides are available for today's session on the web page by clicking the link above the video session here. If you require live captions for today's session, you can also find those just below the video screen. Lastly, we'll save the last 10 minutes for Q&A so please post your questions in SLIDO's Q&A section located on the right-hand side of this video. No need to wait to post your questions until the end. You can post them during the presentation and give the other attendees the ability to up vote or like them. With that, I'm going to turn it over to Kyle.

>> Hello everyone!

Hello hello hello!

Thank you so much for coming!

I actually just got out of Maria la madder oh's talk from the last session. Oh my goodness!

It was so good. I seriously can't wait to go to work tomorrow and putting together these widgets that we talked about. Thank you so much for coming to this talk. Over quarantine I had a little of a domain purchase that I was really excited about. My puppy, his name is laity. And I found out that Leddy.dog was available. It was available available. No auction or anything. I looked around and I was like are you serious?

I purchased it. Now my dog has a vanity domain name. He's not like an actor or anything. This was purely for fun for me. I have been putting a lot of work into it. I got him a little home page and it's much more than just a landing page. There's a little biography written by me. A little blurb about his parents, myself and my partner Daniel. There's also a little bit of photos from this modeling shoot we did when we first got him. It's a little prize possession of mine. I know a lot of folks might be thinking,  okay, Kyle, what is the text that -- I have to say it's on the JAMstack. The JAMstack has been around for a few years now. It's fair if you haven't heard of it yet. I expect a lot of folks might have heard about it on the blog sphere or Twitter or have used it before. For those of you who might not be familiar with it. The JAM in JAMstack stand for JavaScript, APIs and markup. The whole idea is chances are you're using at least one of those tools. You're probably using JavaScript, API or some markup. But I like to think of JAMstack in terms of static and dynamic sites. I like to think of JAMstack as being a static site that's created dynamically. So to talk a little bit more about what this means, what does it mean to be a static site that's created dynamically, I want to dive into these different definitions of dynamic and  static. A dynamic site from like a big overview, a generalization of what a dynamic site is is when I make a request to an app server to one of the  websiteses that's so awesome about the 21st Century where the app server will do a lot. It can make calls to APIs and databases and maybe a content management system to know what text to return to the user. After it gets all these responses from all these external data points it will put together a very customized response and return it to the user. I think this is really cool. It's really personalized. You can give the user a highly flexible response but not only that, it's something that is going to take a little bit more time. There's a little bit more latency. There's more latency because these requests to content management systems, to databases, to APIs they are going to take a little bit of time. They are not instantaneous. There's the other side of the coin, static sites. Static sites are really cool because while they are not as dynamic as a dynamic site, when I request something like let's say the about page, what the static site host will do is say all right, let me find the static site, found it. This is me with my filing cabinet of HTML page. And it finds the page and returns it to the user. It's a lot simpler and a lot faster and a lot of times you can host them  serverlessly. What's cool about being serverless is you don't have to scale up or down your servers depending on an influx of traffic. Serverless websites a lot of times are cheaper. But there is the downside of static sites not being as flexible as a dynamic site. For example, I can't imagine a static site that's being driven by a content management system. What would that look like?

Well, this is where the JAMstack comes in. The JAMstack kind of combines these two ideas by bringing in something that we call the build. The build is going to look a little bit different depending what static site generator you use. There's quite a few of them, there's nex, inaction, Gatzby, 11ity and there is a ton. There's more coming every month. The main goal is to generate a static site but they all get there in a slightly different way. However, they all generally take the same steps I'm about to talk about. The first step in this build is that it collects external data from APIs, content management systems and databases. So these are the API calls that used to happen on the fly during run time for dynamic sites. On a JAMstack site these same API calls are made but they're pushed to the build. They're made ahead of time before a user even makes a request. What this ends up looking like a lot of times is the JAMstack site crawling the API. For example, if you give your JAMstack site a WordPress API, the JAMstack site during the build will crawl that API. If it's WordPress, it will grab all the blogs, all the posts, times, authors, tags, categories, all the metadata for your posts. It will grab everything that it can and stuff it locally in your local memory. And it will pass it to your JavaScript app. And it will use some sort of Central State management of some sort. A lot of times it's ravQL. At this point you have a massive massive JavaScript app and your static site generator is going to take that JavaScript app and chop it up into a bunch of static -- it's going to be a static website. At this point you're going to have a website that's created using external data or APIs or markup and at the end of the day you have a static website that you can upload to some sort of static web host, for example, S3, [Away from mic] is another popular one, verisell, you can upload your HTML files to some sort of static site. Now, I really find that cool. And that's what really excites me about the JAMstack, but the jack stack goes one step further and it gives us some really neat optimizations.

Here's what that looks like. One of the optimizations that we are going to talk about is the link optimizations, how we navigate through the website. So I want everyone to think for a second. What can we hypothesize if a user is using a keyboard, what if they hover or activate a link?

What can we hypothesize will happen?

They might click it. They might want to go to the next link. They might want to click through to the link. In order to render that next page, usually there's going to be more requests to be made. Maybe the images, the CSS, HTML, the text that needs to be loaded. What the JAMstack does is says okay if the user is hovering over a link, they might click it so why don't we pre-fetch these resources they will need before they click the link so when they do we already have the resources and all we do is a quick rerender instead of an entire page reload. Here's how that works. On my page we have a video, it doesn't have -- we are going to see when I hover over these links, the network tab is going to get requests. These are the pre-fetched resources.

Right now my cursor hearing officer over story, over family and over photos. Each time it hearing officer over a link, those resources are pre-fetched. Now this optimized navigation that is a part of many JAMstack sites is revolutionary. It takes what we know about routing and it turns it on its head. When navigating a JAMstack site we're no longer loading an entirely new page when clicking on a link but doing a rerender instead. This is awesome for performance and for SEO, but not so much for accessibility.

In this talk we are going to explore a couple of these truly awesome optimizations the JAMstack gives us but we are going to look at them critically with a keen focus on accessibility. We are going to question decisions that have improved important aspects of the web, such as performance, SEO, et cetera, but might have left accessibility behind in the process. most importantly we are going to explore how to overcome these accessibility issues and how we as developers can fix them without compromising any parts of the website. So I want to welcome everyone to accessibility and the JAMstack. I'm Kyle Boss and I live in Hollywood, California, with my puppy late who you already met and my partner Daniel. We met on  Tinder which also happens to be where I work. We have a bunch of -- we have one for swipe night which is our inapp choose your own adventure series. Equally as important, maybe not as exciting, but is the policies page, our policies page is also on a JAMstack site. And last but not least, probably my favorite project that Tinder has worked on is the interracial emoji couple. We couldn't represent interracial couples because we had to choose one skin tone. Tinder decided they wanted to see this changed so we created the interracial emoji project and put a petition out. You can find it at emoji.tinder.com. A quick shame less plug, if throughout this talk you see a project you want to work on and if you find yourself wanting to work for Tinder, from a 9 to 5 for a day job, I would love to hear from you. We're always looking for awesome great people to work on our team and we're always hiring. Please feel free to reach out. My email I'll post at the end and also my -- the Twitter handle is posted at the bottom of the slide. This is a good point to mention too. I want to mention that I myself am not an accessibility expert nor do I pretend to be. I myself am learning more and more every day because I think it's important to make this web a beautiful place that's more open and inclusive and accessible to everyone. So I'm giving this talk here today because the more we ensure that new technologies are accessible, hopefully more people joining in on this mission to help us make this web an accessible place for everyone.

Where were we?

Accessible navigation. I mentioned that the JAMstack has amazing optimizations. A lot of times you'll get link optimizations depending on your static site generator that you'll use. But sometimes this might lead to navigation issues when it comes to accessibility. And here's what I mean. Here in this video you're going to see me go to a link. We are going to do a link navigation with my voiceover screen reader turned on. I want everyone to observe what happens.

(Video playing).

>> Oh, no!

So we changed the links. I clicked on the family link and I was on the home page and we changed URLs, we changed pages, but there was no announcement. I want to do this one more time. Let's play it one more time and see if you can notice that.

That's not good. So folks who are navigating our website who might be sighted will be able to see this feedback. They will be able to see we've changed  pages, right?

However, folks who might be visiting our website who have low vision or visual impairments might not get that same exact feedback that the page has  changed. A link was clicked but we are not getting that feedback that we're on a new page. So this is a big issue. Assistive technologies don't notify a user of a page change mainly because the browser itself doesn't know that the page has changed. Remember, we're doing a rerender, not an entire page reload, so the browser isn't going to alert assistive technologies that we're on a new page. This is a big problem. And how can we fix it?

Well, we are going to fix it using something that I like to call a route announcer. And we are going to be introducing this route announcer react component. And we are going to go through this code really  slowly. We are going to go attribute by attribute. And we are going to pair a program together and if you're anything like me when I go to a talk and I see a lot of code, I get a little anxious because I feel like I have to understand the code and listen to the presenter. So we are going to go through this attribute by attribute and hopefully make sure that we don't run into this. Let's do this. The first thing that I want to show everyone is the base of the route announcer. We are going to be using a P tag, a paragraph tag. And inside of that paragraph tab is the page name component prop. The whole goal is whenever the page name changes, we want that page name to be announced to the screen reader or other assistive technologies. We want the screen reader to announce the page change whenever the page changes. We are going to do that with ARIA attributes. They stand for accessibility rich internet applications and I like to think of ARIA as a way that we as developers or PMs or designers can let assistive technologies know exactly what certain parts of our website represent. We're the developers, we're the PMs the designers and we know what this website does and we want to make sure that we can allow assistive technologies to also be able to know the content of things, what certain API elements or -- we are going to go through  few. ARIA live will get us about -- what ARIA live does is communicates updates. It will communicate anything that changes within that HTML element. Alerts, progress bars, timers, and we are going to use one of the values that it accepts. There's three values. The first one is  off. ARIA live equals off. That will turn off updates from the ARIA live region. This is usually  temporarily. But honestly our ARIA live route announcer is announcing anything right now so we probably don't want that one. The next ARIA live attribute that we can use is ARIA live polite. ARIA live polite communicates updates but it does it politely. Here's what I mean. Let's add it to our route announcer. I'm typing into the paragraph tag, ARIA live equals polite. When I put that into  late.dog, let's observe what happens. When I clicked on family, we got to the family page and the route announcer announced some things. It announced family, link, list four items and lattey's family. Lattey's family is the -- I do see things I want to change. The first is if you can see there's latte's family rendered in the top corner of our page. We don't want our route announcer rendered. I don't have too much of an issue about that but just in case we do, we want to hide that from being rendered. Also we have family link list four items being announced before latte's family. What's happening here, it's really subtle but family link four items, that's describing the button on the previous page that I clicked. What the screen reader is doing is announcing everything that it's going to announce and then it tax on latte's family at the end. This might seem subtle now but if it was reading a paragraph before, it might be a lot of time before it actually receives our new route so we want this feedback to be a little bit more immediate. Here's how we can do that. There's that third value, ARIA live equals assertive. ARIA live equals assertive will communicate that update immediately. It will tell the screen reader hey, stop what you're doing, we need this to be announced right now.

So I want to give that a try and I have a hunch that will fix this issue.

So I'm going to change ARIA polite in our route announcer to ARIA live equals assertive. And let's see what happens.

So I'm going to click on family and let's  observe. Latte's family. Yay!

That's so exciting!

That's exactly what we wanted to happen. We wanted latte's family to be announced immediately because that page has changed and we don't want to keep giving feedback about the previous page. Now I mentioned that ARIA live is great for announcing a few things such as timers, progress bars, alerts. It's always helpful to be able to let assistive technologies know exactly what this element  represents. For example, if we're using a P tag right now, which there's nothing wrong with that. The P tag is amazing but we're doing so much more here than just a P tag. The role is going to be slightly different. Is it an alert?

Is it a progress bar?

Is it a marquis?

And to give our screen reader and other assistive technologies this context, we are going to be using another ARIA attribute called role. And role's main job is to communicate the UI element that a node represents. There's quite a few roles for ARIA live attribute for ARIA live that I've seen. The first is marquis. This indicates scrolling text. While marquis has been deprecated in HTML five there's still times scrolling text is used. Stock tickers, news tickers and that is a perfect opportunity for using role equals marquis. ARIA value min, value max and value now if you're using progress bar. Also there's role equals timer for count down and clocks. And also I have seen role equals log quite a bit. This is great for things like chat messages. And usually role equals log is used politely. It's not usually a message that needs to be announced immediately. It's something that can wait so I see it a lot with ARIA live equals polite. Very similarly is role equals status. I see that a lot with non-urgent posts or status updates. Very similar to log I see it paired with ARIA live equals polite quite a bit. None of those really scream to me what a route announcer represents or what it feels like. But this next role I think really fits the bill.

Role equals alert. So an alert role communicates that this is an element that's like a flashing error message or maybe a pop-up or something that just needs to be announced right away, now, that it's super urgent, the user should not move on before they understand what this alert says. So a lot of times we see this paired with ARIA live equals assertive just because it's so important. I think the route announcer is a good candidate for role equals alert so I'm going to add it in to give our assistive technologies a little bit more context.

All right. So we are almost done here. I want to remind everyone of one of other issues that we mentioned. The route was rendered in the top left hand corner of our page. And we would like to hide this. So I'm going to add a style here display none directly into the P tag. So we have style equals display none as an inline style. Let's see what happens here.

I'm going to click on family.

Oh no!

Nothing happened!

I navigated to latte's family and no alert was given. I also don't see the route being rendered anymore but that announcement we were getting earlier completely stopped. Let's try one more time.

Yeah, that's not good. Okay. So I want everyone to hypothesize why this might be. I'm going to take a drink of tea really quickly.

So what does display none represent?

It means at least from what I gather, what I usually use it for, the user shouldn't know this element exists. It's hidden. And if it's hidden, the screen reader and other assistive technologies aren't going to want to interact with it either because it's not rendered, it's not shown to the end user, so why should assistive technologies give feedback that it exists?

Why should it be interacting with it because it's display none?

The same thing for capacity zero, because it's hidden, assistive technologies are not going to interact with it or give feedback to the user that it exists.

Now we're in a very interesting case here though. We're in a case where we don't want this text to be rendered, however, we do want assistive technologies to be able to interact with it and let the user know that it exists. So we are going to do something that I do quite often here. We are going to add a visually hidden class to this P tag. Now, the goal of this visually hidden class is to hide the text visually but still allow assistive technologies to be able to interact with the text. Now, if you stare at the CSS long enough if you haven't seen it before, you might be able to convince yourself this will hide the text. You just copy and paste it with every project I work on. I carry it with me in my toolbox and I use it whenever I want a screen reader to be able to interact with something that's hidden. You also might see a lot of people use SR/only, or screen reader only. Let's replace that display none style with this visually hidden class on our route announcer. On our route announcer we have ARIA live assertive, role equals alert, style display none. And I'm going to remove style display none and add class name equals visually hidden. And let's see what happens with the route announcer now that we have this visually hidden class.

>> Latte's story.

>> I clicked on the story link and latte's story was announced. Yay!

We did it!

This is awesome!

Not only was it announced, but it wasn't rendered on the home page. This is great. Everything worked out fine. And I want to pause here and let's take a look back at everything we did to make this route announcer a reality.

So the first thing we did was we added ARIA live. And ARIA live took us really far. It announced the page name whenever the page name changed. Also, we added ARIA live equals polite, but if you remember, what that ended up doing was announcing the route name but it did it much later in the process. The screen reader was like ARIA I'm reading everything off now that's already in my queue and I will push this new message on to that cue. We changed that. We said ARIA live equals assertive and what that does is tell the screen reader stop, stop what you're doing, if page name changes, please, please please announce the page name.

So that's why we have our ARIA live equals assertive. Role equals alert was to give a little bit more context to assistive technologies that this is, yes, a P tag, but it's so much more. It should represent an alert. And then finally, our route was rendered on the front-end and this was no bun oh, so what we wanted to do was remove it. We wanted to not have it rendered but at the same time allow assistive technologies to be able to interact with it. We tried display none first but that took it away for everyone, screen readers and the browser was not rendering it. So we added a class, visually hidden, that had some styles that would hide this element to this route announcer from being rendered, but at the same time it's not the screen readers and assistive technologies are still going to be able to interact with it.

So I want to pause here and I want to give some big big kudos. This route announcer was inspired by the works of two very important people in both the accessibility world and the JAMstack world. Marcy Sutton and Madeline Rose. Marcy Sutton -- several issues with a lot of JAMstack sites and also gave some recommendations. And ARIA live regions and route announcements was one of the problems that bubbled up from there. Also, Madeline Rose made a very, very impactful PR into the Gatzby core. That included this route announcer. This was a simplified version of Madeline Rose's work inside of this very, very important PR. Kudos where kudos is due. Huge shout out to these two and everyone else who's been working on accessibility in the JAMstack.

I want to move on to the next optimization that the JAMstack makes, which is equally cool in my opinion. Images. So when the JAMstack does its build, it's going to take your images and optimize them. It's going to make different versions of them so if you have a user on a mobile device, they are going to get a mobile version of the image. Also as you scroll down your page, these images are going to be lazy loaded. You get this lazy loading for free, which is really, really cool. I think that's really important because when you're loading the page, you want your time for the person to interact to be as fast as possible. Here we have the network panel open. What I'm going to do is scroll down latte's photo page and as photos are about to enter the view port, you're going to see requests for these new images being made. This is the lazy loading happening in action. Take a look. So I'm scrolling down and more photos are entering the view port. And as every photo enters the view port we get new network calls and these network calls are images coming in. I'm going to share that one more time. As we load we see these images. Take a look at this. We see the width and the quality. We see these different URL prams that are given to us too. How do we get the images to work?

Do we get them for free?

The one tradeoff you have to do is use a higher order component called image. Or it might be capital  IMG. Also it's important to note that some static site generators might not do [Away from mic]. It depends on the SSG you're using. A lot of them use a certain higher order component that wraps an HTML 5 image element. A good example looks like this. This is one way to use -- using it with source tag, takes usually the same props that the image attribute, the image tag does. So we are going to the source here and it will output a lazy loaded optimized image. Now, what accessibility issue does this introduce, Kyle?

Very good question. It actually doesn't introduce any issue, however, I really, really like this higher order component pattern that we're using here and I think we can use it to solve a big issue that we see on all websites. And that is what happens when no alt tag is put on an image. Take a look. So here's what happens when a screen reader focuses on an image that doesn't have an alt tag. Oh no!

Not only does the user not get helpful descriptive information about what this image represents, it actually provides quite a jarring experience. Assistive technologies announce an image's file name if no alt is produced. That means that a file name is going to be announced and it's quite jarring and it's very unhelpful, especially nowadays when we have a cache tag appended to file names with a whole bunch of random letters. We don't want this to be announced if there's no alt tag. A great way to overcome this is by of course always always adding an alt tag. Sometimes, as we mentioned, these sites are created dynamically. If we're pulling from a blog CMS like WordPress and maybe the content creator didn't add an alt, we should add a back up. We should add an empty string if no alt tag is able to be produced. What empty string will do is skip that image. Yes,  sadly the user is not going to get descriptive information about this image but they are not going to get that jarring experience of the file name being read which potentially could be many, many characters long. Here's how I propose we fix this issue.

I want to create my own higher order component for my JAMstack website that puts in an alt tag that's an empty string if no alt tag is provided. Here is the code. We're importing that static site generator  image, that higher order component that the static site generator gives us, and we're wrapping it in our own component.

And I want basically to take in the alt tag and set a default for it. Let's just pass this alt tag from our props and pass it into our static site generator's image. And of course, we want to default it to an empty string. If one of them exists, let's pass to an empty string. If no alt tag is given, at the very least it will give the alt -- won't be read the file name at this point. There's more attributes to be passed in. Let's grab the rest of the attributes and pass them down to the static site generator component. I'm going to call it rest of props and I'm using this flat to grab the rest of them. I'm going to -- into our static site generator's image component. Now we have a higher order component wrapping a higher order component that will output an HTML image. Kind of wild having it chained to higher order components. Let's observe what happens when we use this element, this image that we just created, on latte's website with photos that don't have an alt tag.

I'm highlighted on family.

There's an image under family, latte's family and below it there's another header called Kyle. The goal is when we go to the next element, Kyle will be read off and the file name of this image will not be read off. Everyone ready?

I'm crossing my fingers.

>> Kyle.

>> Hey!

It announced Kyle!

This is exactly what we wanted. We did not want this image file name to be read off. I think it's important to mention too that this paradigm is also used for images that are designs. Images that are used more for design purposes, that probably shouldn't be read off by the screen reader. So if you have maybe like an image that's a horizontal bar that divides two paragraphs, for example, you could also add an empty string as the alt tag. That's a good trick I like to use. I want to give kudos by the way to everyone who joined. Thank you so much for being such great pair programming partners with me and navigating through some of the improvements that we can make on all of our JAMstack sites. Again, certain site generators will give -- some will not give you accessibility issues, some will. If you do run into them, it's totally fine, it's nothing we can't fix. It's only not fine if we don't fix it, right?

Before we go, I do want to share a quick little story if that's okay with everyone. Tea time.

So on ru Paul's drag race, every few episodes the drag queens are asked to create their own wardrobe based on a certain theme. Ru Paul will be like category is summer swar a. These queens are amazing. They go into a work room, a room with a whole bunch of fabric and supplies and they grab as much fabric as they can that they think will make the look they're going for. It's so impressive because they take these fabrics and put them into a sewing machine and make the thing in their head a reality. And kudos to them because I don't know how to use a sewing machine. Also some of these queens -- you can tell sometimes when they take out the glue gun and start gluing fabrics together and sometimes even gluing the garment on themselves. What I think when I see that is that is so brilliant, good for them, they're using the resources the best of their ability. Sometimes the judges say that look is crafty and they use the word crafty in the way we say hacky. But again I say at least it works. Sometimes in the accessibility world what I've noticed is that the solutions aren't always going to be elegant. We might have problems that we might need to be a little bit crafty for. And you know what?

That is okay. We saw that visually hidden class, right?

We didn't use the CSS style for it. We had to do a whole bunch of CSS styles, some might call it  crafty, some might call it hacky. You know what?

That is totally fine, at least your website is more accessible and making this world a more open place for everyone. That's what matters. Not the elegant code, not the elegant solutions. Just keep trying. If you find an accessibility issue and you have a solution, go for it. That's all, everyone. Thank you so much. I will be here for questions. Also, again, if Tinder seems like a place you would like to work, feel free to send me an email. Also, I'm always open for questions. My DM, my in-box is always open. Feel free to send me a DM. My email is always open. Send me an email. I'm here too for everyone here live. Thank you everyone. Take it away, Brandy.

>> That was so awesome, Kyle!

Thank you so much for such a good session. Looking at the chat here it looks like everybody else really enjoyed it. We had some people chatting in and liking saying this was so well presented. This was such a great demo and that they always love a Kyle Boss presentation. Amazing job!

Everyone seems to love it. We do have a couple questions. The most up voted question is wondering if latte can make an appearance.

>> Yeah, he's right here.

Here he is.

>> Oh my goodness!

That honestly is one of the cutest puppies I've ever seen.

>> Thank you. He's such a sweetheart.

>> He made the attendees super happy. That was up voted 10 times. Thank you for bringing latte in.

>> absolutely.

>> Another popular question was asked what technologies do you recommend for a good JAMstack, what static site generator and what did you use for latte.dog.

>> For latte.dog I used nex JS. They're all different. The way they output static sites is unique to each individual one. They all have their pros and cons. All the ones that I mentioned, nex, inaction, Gatzby, 11ity and Redwood, those all have amazing Docs so it makes it really easy to adopt. But it really just depends. I know that's an answer that's not as satisfying. It just depends on your use case.

>> Great. Thank you.

>> Absolutely.

>> Another question just came in that said thank you for comparing crafty and hacky. What are common mistakes you see people make when overusing ARIA labels or what are some limits to The Crafty  solutions?

>> Absolutely. Thank you so much. I think I have been to a talk here at the conference and I forget who said it for the life of me. I'm so sorry I'm going to quote someone and not give them credit. Someone said that ARIA labels are great, but the best way to use ARIA attributes is to something along the lines of don't use them, use the HTML elements that are given to you. For example, of course we've heard of an example of people using a span with an on click and giving it the role equals button, why not use the button HTML element. That's the limit I would use. I'm sorry, there was a second part about limits. I forgot what the last part of the question was.

>> They asked or what are some limits to the crafty solutions?

>> Yeah, that's a good question. Whenever I introduce crafty solutions, you do want to make sure that you're not adding too much technical debt. Technical debt does add up over time. However, when it comes to accessibility, I don't think I've seen a time where a crafty solution is going to be turned down because at the end of the day being accessible is really important. Someone else at this conference said accessibility is a civil right and I totally agree with that. If you can do anything to make your site more accessible, go ahead and do it. I haven't seen a time yet where it was too crafty for me to say no.

>> Awesome. Another question, this one's a little more specific. They asked when you added the role equals alert to the route announcer component, did that HTML element then have two roles, alert and nav?

>> Did it have two roles, alert and nav?

It wasn't a nav. It was not a nav component. It was -- I'm sorry, nav element. It was a P element. Oh, can I ask back like is the idea like is it a nav role and a alert role?

I would say no. I would say that it's a single role and that role is alert because we're telling it, hey, this is an alert and screen readers will see that role equals alert and be like this is an alert. It's not going to mistake it for a nav. I hope I answered that accurately. If not, feel free to send me a DM and I'll try to clarify.

>> Awesome. I think we have time for one more. The original asker said exactly. So I think you answered it correctly.

>> Oh, perfect!

Thank you. Absolutely.

>> And then time for one more question.

>> Yeah.

>> This one says I worry about keeping my HTML semantic when creating small components since lots of static site generators wrap pieces or pages in DIVs. Any tips for ensuring your components are semantically written?

>> That is a very good question. It really depends on the static site generator because, yeah, like you mentioned, some of them are going to add  DIVs. They are going to wrap your whole site in a DIV with an ID. And I think your best bet would be to just download it, try it out and see if it introduces any accessibility issues because the answer is going to vary widely depending on what static site generator you're using.

>> Awesome. Well, we are just at time here. This will conclude our session for today. Thank you so  much, Kyle and for bringing in latte to join us. And thank you so much for everyone that has attended the session. I hope you all have a great night. Thank you so much!

>> Bye!