Stop Using Divs for Everything! Master Semantic HTML, Custom Attributes, and Accessibility
58:48 Share

This episode is sponsored by Magic Mind and Wix Studio. When is the last time you listened to a podcast about web development, web design, and small business? Didn't fall asleep.

Yes, we cover web development, web design, and small business, but like actual human beings with personalities. If you're a beginner, we're not going to talk over your head. It's more like asking your buddy for help. We have guests, we have fun, and let me tell you, these two can get off on a tangent. Ladies and gentlemen, welcome to HTML All the Things Podcast. This is Matt Lawrence and Mike Coran.

That's it, everybody. We are back. This is the HTML All Things Podcast. This episode is working title at the moment, The Importance of Good HTML. So HTML, really, you know, kind of a simple thing, or at least we think it is, but we're going to kind of get into the nitty gritty, which includes semantic HTML and why that matters.

We're also going to be talking about custom attributes and how you properly create them and use them. We're going to be talking about HTML's role in accessibility and ultimately just sort of like some best practices with some examples that I'll try to convey in an audio show. And I have like some literally written some code examples that will be in the show notes as well. Basically, the idea for this episode, if you just kind of want like a single paragraph, I guess, is that it came from, I realized that

myself and others, of course, are using divs too much. And we hear that all the time, but it just starts getting silly where it's like div, div, div, div, nest this, nest that, too much. So before we start, are we going fully into the meta of our podcast is only about HTML? Like, should we just lean into it and make a weekly podcast directly and only about HTML? I can't tell you how many times I've had people ask me, like,

how do you how do we do that and I'm like because it's not that they're like well what do you why why do you call yourself HTML all the things we're like it's just like a web development term and no there's like there's legitimately a significant portion of the audience or like general people that have heard that of us thinking that our podcast is solely about HTML so I feel like this is the perfect time to announce that we are officially changing into an HTML only podcast

So expect a weekly episode where we're going to be covering a whole, every week, a new HTML element. We're going to run it. Today is one element each. I got like eight in just the first section of the show notes here. I'll be like, how else can we do it? How else can we do a weekly episode about HTML? We'll bring on a different person each week that will argue over whether HTML is a coding language.

And my answer to this date is I don't care. I need to use it. So I use it sometimes. Like, that's it. That's no, that's no, you have to have a, you have to have a stance. You're not taking the stance is gatekeeping people from being able to use HTML as a coding language. My gates open. It's like, dude, tell me all about how it's, how it is. Tell me about how it isn't.

Refer to the spec sheet, maybe. Here's the thing. How dare you? We're developers. We're developing. Skip the programming part of being a developer. We are developing websites. Kind of like a house developer. They have to buy the land, put the utilities in, all that stuff. They're developing that land, and it's not just like...

Home builders like it's a bunch of stuff roads everything HTML is a part of developing a website We got to like get the server space and all the other stuff but the HTML together the CSS and that what's tragic about you mentioned? Only is I was actually gonna say that I want to do a three like three episodes in a row for my episode so like you write every other week and I write every other week on alternate alternating weeks and

So I was going to do like an HTML episode, a CSS episodes and a JS episode, kind of getting into the meta, talking about semantics and the importance of that, organizing things, things like that. That's my plan anyway. Like maybe one won't be big enough, but then it was just like, nah, man, HTML. So like, okay, just, just as like a brief example before we kick it off here, header is one of these things. So the header defines the top section of a page. Usually they'll have nav, like a nav bar in there.

What else do we talk about in the episode? Like, I'm sure there's more we could. Obviously, I'm just kind of like reading a point. But like, how much can you talk about the header tag? Like, the header tag is written with an H, an E, an A, D, E, R. Like, is it going to become ASMR? Yeah, is it going to have to slow it down? Like, what are we going to do? Well, we do the history of the header. Like, when it was introduced, who introduced it. We bring on the person that introduced the header.

If they're, if they're deceased, which is possible at this point, we bring on a kin of that person and ask them deep questions that they have no idea about and really probe them hard about like why their ancestor developed the header tag. Well, I think that would be a very entertaining podcast right in the HTML, everything on Twitter at HTML, the things on Instagram and threads and all that. And I'm curious, do people want us to switch to just an HTML only podcast? I've,

If the audience wants it, Matt, we're doing it. This is how it's going. If we get 100,000 write-ins, people wanting to hear HTML and only HTML on the HTML and Things podcast, I will do it. So 100,000 people...

I'm putting the challenge out there. It's like we would have sponsors come in, they'd be like Wix Studio, and they'd be like, "Wix Studio, sometimes you work with HTML." And that would be the ad. We can't talk about the CSS, can't talk about the no-code parts, like whatever, it doesn't have to be Wix Studio, it could be anything.

Our website would only be in HTML. No JavaScript, no CSS, just structure. Using Marquee. I remember using that in high school. Yeah, it would just have Marquees everywhere. If they still work, probably. Why not? Yeah. As a meme, it would be awesome. Yeah, so then we have to make a separate podcast for each fucking HTML, CSS, JavaScript, Node, like whatever. Like, man.

Hate it. But anyway, if this, you know, the importance of good HTML, Samantha HTML, sounds interesting to you, and you want to support the show, you can go check us out on that Patreon, leave a review rating on your podcast app. Join us in our Discord server or share this with your friends. And now I have concocted an introduction that I'd like to share with all you fine people in ASMR. No, I wouldn't. To crank my mic up and be like, HTML is often viewed as the simplest component of a website.

Mike. I hate ASMR. It just drives me nuts. Don't make me burp into the mic, Mike. I can't do it. I can't do it to you good people out there. I'm so sorry that Matt is crushing your ears. I mean, some people love ASMR. Mike, you're my Mike. Oh. And that's weird. Sorry to get weird, like, because you're my microphone, you know? Anyway, that made me feel weird. Ahem. Okay. We're talking about HTML here.

HTML is often viewed as the simplest component of a website, leading some developers to prioritize CSS or JavaScript or other tools instead. However, HTML serves as the foundational structure of every web page, making it a crucial component for creating accessible and maintainable web experiences. HTML acts as the skeleton of a web page. It is the foundation on which every website or web app starts its rendering journey.

foundations may not be the most exciting part. So in a house, you just think most foundations are going to be like concrete or something like that. However,

The interior design needs, the interior design, the paint, all those fancy parts of a house need that foundation in order to keep standing, in order for it to be there. And so HTML, where it may not be the flashiest thing, is absolutely very, very important. So in this episode, we're going to cover the use of semantic HTML and try to avoid overusing div tags.

to improve readability, SEO, and accessibility. We're going to also talk about creating custom attributes and how to do that properly so that your HTML is valid, you have a clean looking bit of code, there's going to be some dynamic web development talked about in there like CMS is coming in there and changing things.

And then we're also going to be talking about accessibility. So HTML does play a big role in web accessibility. And so there's going to be some key practices and tools, like a screen reader will use your HTML. So if your HTML is not good, then the accessibility of your website isn't going to be great. So that's going to be basically what we talk about in this episode. All right, back to ASMR. No. So the first thing, and this was really the inspiration for this episode,

is why semantic HTML matters. So semantic HTML as a definition is basically our HTML tags,

they need to convey meaning about the content inside them. So you're using tags that convey meaning more than just a div. So I mentioned that HTML is a skeleton. Well, think about it if we took like a human skeleton and you, you know, we know what a femur is, like it's the top of your leg or whatever, right? We know what the pelvis is. It's like your hips and whatever else, right? We know those things. But what if I just said bone for everything?

Bone for the skull, bone for your femur, bone for your pelvis. Like, yeah, it's valid, right? They are bones, but it's really confusing. And so things like

search engine crawlers as well as screen readers will be like bone, bone, bone, bone, and they don't know what the heck is going on. So our semantic HTML, we need our tags to convey meaning about what's inside of them. So I have a list here of a few of the common ones. The first one is going to be one that is near the top of your HTML, which is going to be a header tag, literally written just as header, and it defines the top section of a page.

This top section of the page often contains things like navigational links or introductory content. So think about this. A lot of the time we'll do like a div class header, right? And we'll leave that sort of classification of header to our CSS. That's not great because a screen reader or anything that like looks at the HTML specifically is going to be like,

It might be smart enough to see that it's called header, but that's not a standard, right? Like this is a standardized tag that we should be using. Header is a standardized tag and we should define the top of our page. Next one here is going to be big for blog posts or news writers, which is going to be, there is an article tag. So literally just written as article in your tags, right? You're less than and you're greater than symbol.

These are used to self-contain content that could stand alone. So things like a news article or a blog post, the way I think of this, and this is not necessarily perfect, but the way I think of this is something that if I were to print out the webpage, I may cut out all the other stuff. So print out a webpage, you got your, you know, your header, you got your footer, and then you have your article in between. Well, you might not care in that printout about the header and the footer. You could actually literally cut that, those parts off the page.

And that article itself stands alone. You could give that to the newspaper and the newspaper could print that. It's something that stands by itself. So that's how I roughly define that in my head when I try to put article tags around things.

And then I already mentioned what this other one, which is footer, literally written just as footer. And it marks the end of a section of a page or a content section, typically for copyright, copyright, legal contact information, all those type of things. Usually we'll SEO it a bit. So we'll have a, not a site map, but we'll have like some key links like, Hey, you know, we have a blog, but we also have a help section. We also have documentation section. So we'll have links to sort of some key pages in there as well. Social media links, things like that.

Then we also have the navigation. Now, this is not written as navigation. It's written as nav, just N-A-V. And this represents a set of navigational links on a website. And your nav, as we already mentioned, would typically go inside of your header, right? Go inside of your header tags. We also have a section.

So if there is a bit of content that has a common theme or purpose, it makes sense to put it in a section. The tag is literally written as section, and it allows us to group that content. And it tells screen readers and site crawlers for SEO like, hey, this is a bit of something. This is a bit of something. So for example, you might have a section...

that's your call to action section you may have another section that is your fun facts if you have like some fun facts on the sidebar or something like that you have a little fun fact section things like that and i mentioned sidebars there's something for that as well and it's called aside literally written as a side in the for the tag itself and it contains tangentially related information so things like sidebar sidebars pull quotes so for example you might be writing a blog post

And sometimes blog posts will have those little like quote sections where, you know, it'll like quote either the article itself or it'll quote like a famous person that's talking about something that's already in the content. Sometimes people want those to be on the sidebar. And so they'll put those there. Fun facts. Sometimes they'll be dynamic. I've seen a couple of times where as you're scrolling through, it's like a sticky sidebar that stays on the left side or right side.

usually the right side in my experience. And basically it'll dynamically change sometimes. So it'll be like, oh, you're like, you know, you're scrolling through and you've hit this, like the section that's about like whales. So then maybe we'll have like a, like a few fun facts about whales that goes to the, you know, the whatever animal planet or whatever you learn about animals, things like that. So that's kind of cool. And these, so these semantic tags, you know, and there's going to be more of them as well, but these semantic tags provide structure and meaning to,

And they take away from that sort of generic feel of div elements. And I want to be clear here, like, I'm guilty of the div. Like, I go, you know, div, div, div, div, div. We're nesting divs inside of divs, and then we're just putting classes on them and things like that. It really is, not only is it a bad habit, but it's also a...

I guess it's part of the habit, but it's also part of like building quickly for me. Like I just go quickly. It's like, okay, I need a div. I need another group, another, another group, another grouping, another grouping, another grouping. And then I just think, oh, I, you know, I put a class on it. It's good enough, but I really do want to start thinking about these semantic HTML tags because it is going to help not only those with disabilities, but it's also going to help people or not people, but crawlers actually kind of crawl your content a little bit better because maybe the crawler is

does not care about your nav bar, but it does care about your blog post. Well, if it's in an article tag, it might help, right? The crawler might go, whoop, I don't want to see all this other garbage. I want to read the meat and potatoes of this page.

So, oh, sorry, go ahead, Mike. Yeah, I think like the ones you mentioned are really good and really common semantic tags that provide just structure to a page. But I did want to bring up a few that are more functional and structure and like readability. So there are some HTML tags, especially in the more modern HTML era that actually can save you from writing JavaScript. For example, there's a details tag that can be combined with a summary tag.

which will allow you to essentially create an automatic collapsible container. So if you use the details tag and then you have the summary tag inside of it,

the summary is actually going to be like your uncollapsed content. So like your, your, your summary before, before you actually expand. And then anything you put other than that, like a P tag with a paragraph will be auto collapsed initially. And then you can press, like it'll automatically generate the whole click container for you, everything to be able to go press it. And then it'll automatically expand that other content that's outside the summary. So it's,

That's just one example of a really functional HTML tag combination, right? There's like, if you're talking forms, forms are another like very high functioning HTML structure that allows you not only to,

create like, you know, forms that you would send information to a server, but also to be able to do some basic math and provide an output for that map. There's like, inside of a form, you can also have an output tag, which could be tied to actually like

You have to do a little bit of JavaScript here, but it will automatically place the output of a particular form for calculation inside of an output tagged properly ID element. All automatically, you don't have to do any get elements by IDs. You don't have to create elements or you don't have to do that. It's all built into HTML with a tiny bit of JS to actually do that to whatever calculation or whatever formatting you need to do. Like you might just be doing like a capitalization formatting or something. There's plenty that you can do with just HTML. There's like

a loading bar kind of situation with a meter, right? Like there's a meter HTML tag that if you put in a range and then you put in a value, it'll kind of show you what kind of a loading bar or like a bar with depending on what range and value you put in where that thing is. So

There's some really cool side, very underutilized HTML elements that I think we don't particularly rely on as much as we should. Like for me, for instance, when I create a, you know, an FAQ section, I don't really rely too much too heavily on the details and summary side of things where I probably should because it's already handled for me. I bundle less, less JavaScript in the browser and

It's much easier for a screen reader to understand what this is. Like as soon as it sees details and summary, it knows that we're talking about collapsible, expandable content, right? Like there's a lot of really cool built-in functions that I feel like people don't use because they rely not only just on divs all the time, but also on all the other languages like JavaScript and CSS too much when HTML actually has functionality built in.

One of the big things actually to build off your thing, Mike, is absolutely in forms, specifically for me, the date picker, where the date picker does vary from browser to browser. However, just being able to effectively have that initialized in HTML, you basically just say, yo, I need a date picker in here in HTML. And then sort of the browser and the user can kind of show and hide that and do whatever it needs to do. That's super helpful, especially if you're just quickly trying to set up a form. Because sure, you could have a custom one, but that's big, right? It's annoying. It's like a lot of...

squares, literally of a calendar and things like that in there, unless you want to have someone type it out. So just being able to like quickly have a date picker, which is honestly very serviceable too. Like I know a lot of people will like not like to use the default of things, but honestly, like it's very serviceable. Like no one's going to click on a date picker field, at least I don't think, and

And then be like, man, this is crazy that they don't have a custom one. It's like, well, the other one doesn't look too bad. And like, are we going to, you know, put in a bunch of dev hours or have to pull in another JavaScript library or something to have a custom date picker? Like, you know, it's better sometimes to use the HTML version because oftentimes the HTML is sort of like, I'll call it the vanilla version slash the browser version.

Is usually the most accessible. Like it's very accessible. It's been like kind of boiled down to this point because the browser doesn't want to make something super fancy. Right. And screen readers don't have like, well, they're able to look through fancy stuff, but the more clutter on a page, obviously the harder it's going to be to like convey your point to something like a screen reader. Right.

And that's actually some of the benefits here that I'm going to list. Like the benefits of semantic HTML, we've touched on them, but I'll touch on them again, which is enhances SEO, right? It's giving search engines a look at context, right? And so one of the things I've been teaching my clients when they ask what SEO is, is

SEO to me, and this might be completely wrong, I'm not an SEO expert, but this is how I've been doing it and this is how I've been getting success. I'm not going to go super into SEO, but the way I tell them is I tell them, think of it as a person, like as if you're talking to a person, right? In a regular conversation, if I'm trying to sell Mike on Magic Mind, for example,

I might mention the word magic mind a few times. That's my keyword. I might mention the word magic mind a few times, but I'm not going to be like magic mind, you know, Mike, you're magic mind. Hey, Mike, do your HTML magic mind. You know what I mean? It's ridiculous, right? Talk about it like a regular person. And there's some technical stuff around a technical SEO. Again, I'm just doing a really brief summary. But what I, what I always tell them is assume that the, the, the crawler is actually a person that's not informed. So make sure you're very clear.

Make sure it's very obvious what you're talking about. Don't stuff it with stuff. Don't make it awkward for the bot, right? And then there's a bunch of other stuff like keyword research and which ones are competitive and not. But the biggest questions I always get is like, how do I structure my content? This and that. Make sure your headings are good. And that's HTML. H1s through H6s, right? Make sure it's clear, like maybe wrap it in an article tag if it's a standalone piece, right? Something that could stand on by itself.

And make sure things are in proper paragraphs. You have links. If the links are non-descriptive, excuse me, descriptive links. If the links are non-descriptive, you can add things called like ARIA labels as well. Like things like that. Like just make it so as if like, if Mike has never been to a website before and he goes to your website, he's not like in the room saying,

And actually, you know, it's a better way to describe it. You know, like when you're on like X and any other or any other social media network and people are talking like as if you've been informed about a topic for like three weeks and you're like, I didn't know this was a story that had been happening for three weeks. These people are talking at such an informed and such a high level to me that I have no idea what they're talking about.

Right. You don't want to make the bot do the work because guess what? It's probably not going to do it. It's probably not going to figure out the context. So SEO helps a lot or excuse me, HTML helps SEO a lot by giving that context and then you have to complement it with good content.

Another thing that is a benefit of semantic HTML is it provides a better user experience for assistive technologies like screen readers, which we will do a little bit of a deeper dive into later in the episode, which we've already mentioned to death. But that context is really helpful to screen readers. It also improves website structure and readability for developers.

That's something that we don't talk enough about. And we've talked about it, but we have talked about it a few times on this show, which is developer UX. Like somebody does not want to go in and have like 15 nested divs and be like, what is this? And like your classes, especially if you're using like a, like a CMS that has some page building built in.

There might be classes like L is column dash 26489 and like these crazy class names and they're all divs. Like what is going on here? Right? So having things like this is the article. This is the aside. This is the header. It's like, okay,

I need to fix the blog post. Something's wrong with the blog post. I won't look at any of these other pieces. I'm going to look inside of the article tags and figure this out. I need to fix the sidebar. I'm looking for the aside tags. Nice and easily readable, and it's helpful in that way.

So common misuses of div, I have an example here. I'll try to articulate it in a visual way or in an audio way, but I have it visually as well. That'll be at htmlallthethings.com in the show notes. But there is a very common, and I do this, overuse of div. So if you have a header and you literally just want a title inside of it, a classic is you have div class header and inside of there, nested in there, you have div class title and you write your title in there.

HTML's got this for you. You don't even need to bring in the classes for CSS in here.

The actual proper way to do this if you're trying to use semantic HTML is you literally have a header tag and inside of it you have a h1 tag because we are assuming this is the first header or your main header of this page. And then you write your content. So not only is there that less characters, but also it's very obvious, oh, this is a header and it's a big important title. You can tell right away. That div class title, was it a big title? Is it a little title? Is it important? Not important? What is it?

And a bot, which we assume, again, is not informed, is going to be like, what is this? Like, what are you trying to show me here? Like, maybe it'll understand it's a title because it sees the class, but how important is it? Like, what is this, right? So give it as much context as possible because Google's not going to do heavy lifting on your website. And screen readers are trying to give the user context.

the best experience possible as quick as possible. It's not going to be like, give me 15, 20 minutes to read this, you know, use an AI to figure out if this is an important title. Like, it's not going to do that. So just give it the proper structure and the rest will fall into place. I do want to mention one other kind of misuse, and this is kind of a forced misuse of HTML because HTML is,

has its disadvantages sometimes, like if you like specifically semantic HTML, for example, you need to do a drop down that has some custom functionality in it, right? Like you have to, you know, multi select drop down a drop down that has maybe some auto input, some sort of more complicated drop down that what HTML gives you out of the box.

A lot of times that forces a misuse of HTML because what people realize is to create that really custom dropdown, they can't just, you know, jank together the actual HTML elements, the dropdown, the select element, I should be clear, for HTML.

to make it exactly what they want. So they will eventually create their own using divs, like, you know, without using the semantics and they can make it look and work the right way. But again, when it comes to screen readers, that's an issue. So there is now this in between and there's all these new packages and really awesome UI libraries coming out that I've mentioned quite a few times that kind of handle this for you in a way that

It'll still use the base, you know, select element from HTML, but it'll create a facade on top of it that will have the functionality and the looks that you need. And you can edit that facade in any way, shape or form. Those those facades can be in any HTML, even like, you know, a misuse of divs and stuff like that. That's fine in a facade because the underlying element, they're tied together using some JavaScript.

The underlying element is still on the page and is still readable for a screen reader, right? So the forced misuse of HTML has been a problem for a long, long time. Like Matt said with the date and time picker, great element, can't customize it. Now with a facade, you can customize it. And now you have kind of the best of both worlds where you have the semantics.

and you have the full customization. So there's ways around it. Not an easy thing. Like if you try to build a facade yourself, you'll always come. There's always these edge cases that you're going to run into that are like, damn it. I wish I caught that. I wish I caught this. So using these like libraries like Shad, CN, Radix, the ones that handle the facades for you, you're going to have a better time and preserve the semantic HTML side of things as well.

It's often like there's a reason to like if somebody wants something a little more custom and they won't use a date picker, they'll often just have you fill in the date, but then it'll help like autofill. So it'll like basically your form validation will force them to write the right, the correct date or at least a valid date. I've seen that. Although like I still even then, like I still feel as though like you should be using the date picker because like to someone who's

Like on a screen reader, like it would be a pain to be like, oh, like this is just a text field, but it's actually for the date and it's trying to correct me. Like it just feels like it wouldn't be good. I've never tried it. I might be wrong, but you're right. Like doing having a facade is great, although it's challenging to get accessible using other tools like you mentioned, Chad, CNN, et cetera. Absolutely helps with that because I mean, like again, like this is quote unquote just HTML that we're talking about here.

And it's important. Like, it's quite literally like, could you imagine being like, yeah, man, my house is built up on like sand that I really packed down hard. It's like that might work in some places because I know some sand does get super hard or whatever. But I know for sure that here in Canada, like our most of our

foundations are like cinder block or they're concrete or like, you know, a mix of that type of thing, like a hard rock that's been like human formed, right? Like concrete that's been dried or whatever. And that's probably because of the climate and different building codes and things like that. I've never seen a house where it's like, yeah, man, I just packed down some sand and like it worked for like a year, but now it's cracking. What do we do? Right? You don't want those foundations to crack. You don't want the users accessible, like using accessibility tools or not. You don't want them to fall through the cracks.

Now, I do have something to share here that's a little bit bittersweet. It is the end of our Magic Mind. Well, this specific Magic Mind sort of run with them. So I've been very grateful to them for providing me with Magic Mind and helping me through this journey. And we've been going through sort of my anti, I guess, caffeine or reduction of caffeine journey. But you've been hearing from me a whole bunch. And I'd like to talk a little bit about some other people. So I've pulled up a few videos.

almost said editorials, I pulled up a few testimonials here, and one of them is web dev related. So it's actually Matt Mullenweg, founder of WordPress. His testimonial reads here, incorporating MagicMind into my daily routine has become a ritual that fuels my productivity and creativity. And honestly, I feel the same way in that way, in which I have a MagicMind, I enter in like a nice sort of like, I'm energized, I'm doing great, I'm in a productive state, and I'm just...

I'm able to just crush my to-do list. I'm able to rip through it. And that's also what, and I apologize if I mess up any names here. This is a New York Times bestselling author. Alex Snodgrass said the same thing about conquering her to-do list. After drinking magic, my brain fog lifts and I'm able to conquer my to-do list with less distraction. That's her testimonial on that. And it's the same thing with me. Instead of me

constantly drinking coffee and getting all amped up. And then I sit down and I'm like, my to-do list is big. And I'm like, worried about that. I'll have one coffee at max to have a magic mind. Then I'm like, okay, my to-do list is big. Better, better knock one or two of these tasks off today. Better get this done. Let's crush. Let's actually like crush this to-do list. Let's get something done. And I'll read a final one here. So Pete Holmes, he's an actor and comedian.

He said, for years now, Magic Mind has been like my own personal magical mythical beast that I set loose to destroy my procrastination, lethargy, and brain fog. But unlike a mythical beast, it tastes really good too. And I'm at that point too where I enjoy the taste. Like I'm not, it's a green juice, right? And you might think like, oh man, you know, I don't want to,

It feels like I'm doing like a juice cleanse or something like that. And you're kind of like worried about the taste because it's like the classic in a movie. Someone blends up, you know, like a healthy shake and then someone takes a sip of it. It's like some green slop and you're like, oh, that's not the case here. Like it's a green juice, but it tastes great. I never cringe about it. I'm never worried about the taste. I'm never skipping it because of the taste. And that's really, really important.

And so I just kind of want to reflect on my time with Magic Mind. It has helped my daily routine. It has helped me through very busy times. We've talked about that, where I'll have this little mental performance shot just in my bag. I'm out golfing. I'm running around. I don't have time to stop for coffee. I don't have time to stop to rest. Sometimes I'll just take this, boom, have my Magic Mind. Now I'm being energized. I've entered that sort of flow state where it's like, okay,

okay, we need to cut through this. We need to get through all this. With the holiday season, it's even crazier now. So, you know, running around to stores, buying things for relatives, helping people out. We're in Canada, so shoveling snow, dealing with ice. It's a lot of extra work

time spent doing things, meeting with friends, all kinds of stuff. And sometimes you just do not have time to stop by the side of the road, grab a coffee, stop at home and do that. And so Magic Minds, a quick little shot that kind of boosts my productivity and gets me through those busy days. And if you want to experience all the things I just described, you can do so.

at magicmind.com slash htmlpod20. You'll get it up to 20% off. And remember to use our code as well as that link. The code is htmlpod20. Link and the code will be in the show description as well as the show notes. And thanks to Magic Mind. Hopefully we'll work together in the future soon.

So now let's change gears a little bit. We're still talking about HTML, but we are talking about custom attributes. So we're changing gears from our semantic HTML chat, and we're going to talk about attributes. Now attributes are obviously part of HTML. We've already mentioned one, which is a class, right? So that div class header, a class is an attribute, but you can make your own attributes. So developers can define attributes, right?

They need to start with a data dash, literally the word data and then a dash or a hyphen, right, to store extra information in elements. And this approach keeps the HTML structure clean and allows easy access to data without relying on fragile class naming conventions or external scripts.

So, for example, you may have something like data user ID or data theme, right? And remember, there's dashes between. There's no spaces in between those words. And so it's something, this is another way that HTML can be extended. I want to mention something here.

You can actually go in and do a custom attribute name of your own name. Like you could put like Matt dash is dash cool and then equals true. That's actually it will function. The site in general will not crash unless there's like another tool that hates it and then crashes the site.

However, that's actually invalid HTML. If you want to do custom attributes, you got to do the prefix data dash and then your thing. That's how you keep it organized because there's ones that are pre-reserved, obviously, like class, for example. And let's just say, think about this way back in the day.

Let's just say there was no class attribute, but HTML wants at some point to add that attribute. But thousands of websites are using class because they're using like a third-party tool that uses the class attribute. Now we got a problem because the standard is going to change and all these sites are going to have problems.

So the data dash kind of gives you free reigns like data dash, okay, now I'll do what I want to do. Data dash, Matt is cool or whatever you want to put in there. And that's like way better. That's like a way better way to handle kind of future proofing. And also it keeps your HTML valid. So remember that data dash. So some best practices for custom attributes. Again, always start with that data dash, avoids conflicts with standard attributes.

Also, though, don't just have like data dash ASDF. Have a meaningful name. Have it be self-explanatory. We just talked about semantic HTML and things are becoming more self-explanatory under these various elements that like, you know, through semantic HTML is quite literally it's self-explanatory. And you do not want your website to have all this nice laid out data or nice laid out tags, right?

But then you have some custom attributes that are like data dash test one. It's like, what does that mean? Like, what are these, you know, what do these mean? So use meaningful names that are self-explanatory. The same goes with variables, of course, right? If you're into JavaScript or other programming languages, variables are obviously huge. Like you use them all the time and you really should make them things that are more than just like,

mic or hello if that's not what you're doing with that variable, right like you want to have a self-explanatory variable as much as possible and

Now you might think to yourself, wow, this is fantastic. I can have my own data attribute. I can store a little bit of information inside of these elements. I'm going to just start really pounding the data in there. Don't do that. So avoid overloading attributes with unnecessary or overly complex data. You don't want to have like a formula in there or like a crazy like data dash formula and then you have like 1, 2, 7, 8, 4, blah, blah, blah, blah, blah, all this stuff. And then you have like your JavaScript, read that and like reconstruct something.

Try to avoid that. I know that sometimes things are unavoidable, like, you know, sometimes things get complex or it's an edge case, things like that. But just as a best practice, just don't overload your attributes with unnecessary or overly complex data.

And so I have an example here. It's just a button. So it's a button attribute. And what we have is it's a delete button. So inside of the button, we have just the word delete straight up. But then we have two attributes that go along with it, which is data user ID. There's dashes between those words. And that's equal to one, two, three. And then data dash action, which is equal to delete. Right now, that one, two, three.

could be filled in manually by you, but obviously it's only going to ever delete user one, two, three. But, however, you

You can fill this in, right? So I know we're not talking about CSS and JavaScript, more specifically JavaScript at this time, but JavaScript is a great way to fill these bits of data in. So JavaScript may come into place where it fills in that user ID. Like, oh, I pull up, let's say Mike's profile and Mike's profile ID, his user ID is 123. JavaScript fills that data user ID attribute with a 123. Now when I press delete, it uses that 123 to know what to delete.

All right. And this is really, really common actually in things like e-commerce. So for example, you may have a div. So divs still, you know, don't avoid using divs. Divs are still totally valid and valuable. But you may have a div that surrounds a label that says like laptops, for example, right? So you may have, and this is an e-commerce website, you may have data dash category because you want to make sure that this section here that has your laptops,

You know it's the electronics category. And you also want to know how much stock there is. Data-stock. And you can have 25 laptops, 30 laptops, things like that. Using data attributes enable dynamic interactions without hard-coding values. It allows your JavaScript to come in, quickly throw something in there. However, you can hard-code things. If something never changes, like if something is quite literally like,

You need, like, you have a bunch of buttons and they're all the same class to keep the style the same, for example. But that, like, sometimes you want there to be an icon or something like that. You can make a data dash. So you could be like data dash icon true and then have like your JavaScript go in and be like, oh, like add a, you know, tack on this icon.

Tons of different ways to do it. That was just off the top of my head. That might not even be the best way to do that, probably a class or something else. But the point of the matter is you can hard code or you can also have your code dynamically change these attributes. And actually, as a side note, we mentioned we talked about interactive styling in CSS and if CSS could replace JavaScript in some ways. In a previous episode, I'll link it in the show notes. And one of the things we talk about is how CSS has a selector

for attributes and you can have a selector based on whether that attribute is present or if that attribute is present and set to a specific value. So if you literally have like a button again, and you literally have like a data dash seasonal on there, true, maybe at Christmas when that value is true,

It changes the color of the button to red and green to celebrate Christmas. But then, you know, your JavaScript, which is tracking the date will be like, oh, it's no longer December. It changes that true to false. And your CSS handles your CSS and your JS there handle the look of the button based on that. It's just a really simple way to do it. Little bit of JavaScript, little bit of HTML, little bit of CSS working together rather than like JavaScript doing all the heavy lifting for no reason, really.

Now, a really important thing, obviously, that's, you know, come not come to fruition, but that's like been on a lot of people's radar. I'd say in the last like five to seven years ish, a lot has been accessibility. Of course, it existed before then. But HTML has a big role in accessibility. I've already mentioned that a little bit. So, yeah.

Accessibility matters because obviously you want people with disabilities to still be able to use your website. You also may need to do this. So you may need to comply with certain legal standards like WCAG or W-C-A-G, which is an acronym. Right. And so, for example,

Screen readers like the non-visual desktop access, shortened to NVDA, and JAWS or job access with speech rely heavily on well-structured HTML to convey information to users effectively. So for example, a nav element helps these tools provide a clear outline of a website's main sections while proper use of headings allow users to navigate content more efficiently.

So just think of when you go into your webpage and you just like rapidly write some HTML and it's just a mess, like it's a mess of classes, it's just a bunch of divs. Like how are these screen readers gonna find your nav list? Like you might say, well, it'll be a list of div or it'll be a list of links. Well, how many? How big is your website?

How did you style your nav bar? Also, maybe your sidebar has a list of links too. How does it know where the nav is? You need to have that semantic HTML. And so therefore, HTML is playing a very crucial role when it comes to making things accessible.

Now, obviously, you can also do some other key practices as well. So, for example, in HTML, you can use the button element, which tells a screen reader, tells even SEO, right? Crawlers that, hey, this is a button. It's going to do something. It's either going to link me somewhere. It's going to take me do something, right? We don't know what the heck the button is, but we know it's like an interactable thing, right? But the thing is, is that you can use ARIA labels to sort of fix or to sort of

enhance that a little bit. So for example, let's just say you have a link, like a button somewhere. And for whatever reason, actually, this is really common. I'll have people just want an icon in the button and the icon is really not descriptive, right? So I can add the ARIA, I can add the ARIA label in there and say like, hey, like this button, this button is, you know, linking to the US site. This button is linking to

Another page wherever it's linking to this button links to the share page right where we list all our social media icons and things like that right there's another thing too is People will get attached to this Aria stuff and they'll use it too much. So there's gonna be inappropriate use of Aria roles so key key kind of thing is make sure you only use Aria's

when necessary, rely on native HTML elements first. So for example, you could have a button, meaning using your button tag, and you use the aria-role attribute and then say this is a button.

That's redundant, right? The HTML is already saying it's a button and now you're like button button like why right? So just use the native button element just have button and that's it This is also this is also like really really key when people I noticed this for whatever reason with links a lot where someone will use an anchor tag or an a tag They will I see aria-roll all the time where it's like aria-roll button aria-roll this aria-roll that I think it's a lot of the time it's like CMS is filling that in automatically and

Oftentimes it's redundant like you don't need to say this is a clickable thing. This is a clickable thing Which is effectively what you're doing right you don't want to you don't want to over inform

The screen reader, the way I look at it when I try to make things work with screen readers is I want to be straight to the point. The person is trying to navigate the page. When we're flipping through a page and we don't need a screen reader, we just flip right through it quickly load and like, oh, that's a share button. This, this, this, this, this. We don't even really like pick up on it anymore. Right. We're just familiar with websites and how they work. We want that quick scan experience.

to be as accessible to screen readers as possible. And then if they want to get into the meat and potatoes, like if they go, yo, read the article and the screen reader starts reading the article, we want them to be able to find the article and read it, right? We don't want them to, they don't want the screen reader to go like, I don't know where the article is. I don't know where the nav bar is, you know, big freaking mess. Also another thing too is forms. So with forms, one of the big things with accessibility is if you're inputting email, I mean, it's just an input.

It's just an input element. If you're inputting your name, it's just an input element. So try to actually label things. So for example, have your email full

or you're sorry, your email form input actually be labeled with like an input type email ID email. Right. And then you have a label label for email is, is your email that makes it really obvious. Like, Oh, this is a label for email. This is an input and we must input an email because it's type email. It makes sense. Right. Don't just have like your JavaScript validate that it's an email. Use the type email, like use the HTML to actually validate. And it helps again, it helps people be like, Oh, that,

That needs to be an email, right? And a big one that people talk about, often miss, and I do none of this perfectly, I wanna be clear. This one's big, image alt tags. Alt tags are important, right? These are descriptive alt text for images. So you'll have like, you know, your image tag, you have your source, which points to the actual image asset, but your alt tag needs to describe what's in there. Now, this is something that I do wanna touch on briefly, and maybe you can even chime in on this, Mike.

So with alt tags, this is the way I've been taught to do this. Some people disagree with this. Some people will write what is in the image to the letter, like, you know, beautiful sunset on a beach and like, you know, all this, like whatever. And then there's the alternative, which is like, it's just decorative, right? You can also label something as, hey, this is decorative. So a screen reader will largely or entirely skip over it.

that's usually done when a description is written elsewhere. So like say an example, you may have a travel blog and you write about this beautiful beach and you already describe it, right? You're like, this was an amazing sunset and all this. And then you have a picture of it. Well,

You don't want like you yourself as someone who does not use a screen reader. Like if you're a person that does not use a screen reader, you wouldn't want to read that paragraph and then see the image and then read that paragraph effectively again. You don't want to describe that image again. That image is decorative to what's already been said.

So I see that be made a mistake a lot as people are like, oh yeah, just write the alt just in case, just in case. Like, no, not just in case. Like if it's decorative, it's decorative. Right. And another thing really brief, and I'll let you chime in at this point, Mike, is I see people describe things in the alt really, really granularly. You know, oh, it's a purple sunset. It's 6 a.m. It's this and that. That is.

I think makes sense if the image is there for an artistic reason. If you want someone to actually interpret the art of the image, makes sense.

But if the image is there just to say, yo, there's sunsets and there's a couple palm trees, my alt text is going to read, a sunset fills the background of a beach scene with two palm trees. Because the point of the image being there is what I just wrote. Some people disagree with that. They go, no, like, you know, people with screen readers should be experiencing the whole image.

I was taught that that's actually incorrect. Like that's something that you should not do. Devs, this one's for you. I've got 30 seconds to tell you about Wix Studio, the web platform for agencies and enterprises. So here are a few things you can do in 30 seconds or less on Studio. Integrate, extend, and write custom scripts in a VS code-based IDE. Leverage zero setup dev, test, and production environments.

ship faster with an AI code assistant, and work with Wix headless APIs on any tech stack. Time's up, but the list keeps going. Step into Wix Studio and see for yourself. Link in the show description and in the show notes. What do you think, Mike? Yeah, I agree with you wholeheartedly on that. I will provide the minimum amount of information that would get the point across of why the image is there. A lot of times in web development, images are filler content.

that don't have any purpose other than to balance a page. And a lot of times in that case, the alt text will be filler content or skip or whatever, like because it's just not something that would enhance a user's experience using a screen reader. My thought, and I think the reason why this is the right practice and the standard practice is that when someone's using a screen reader, time is very important to them.

and filling up an image with a massive alt text just to describe it the same way that people are seeing it for no other reason other than that actually wastes the script like the person that's using the screen reader's time the reason that they're usually on your page is to get an action done so an image is there for the most part is going to be skipped by them and so like having a longer alt text

is only delaying them from getting to the next point and to the next part of the page that's probably much more important obviously this changes when the images become very paramount to the user's experience then you can provide as much details as required that you required for them to use the website in the proper way but overall I agree that like you provide the minimum amount of information for them to move on to the next thing that's actually more important

Yeah, at the end of the day, you're trying to fulfill the goal of the page, right? And like the way I see it is, like one of the main reasons why you would ever describe the absolute intricate details of an image, like the colors and their shades and all that, is if it's like an art gallery. And you're like, yo, like the point of being here, right, is that art. You want the person to experience that there was a fade and this and that. Because I saw somebody one time selling a controller on X and

And they wrote this like, oh, an explosion of like purple and there's a purple Xbox controller or whatever it was. PlayStation controller, I don't remember. But there's a purple controller in the middle. The controller has, you know, black analog sticks and has blue face buttons and this and that. And I'm thinking to myself like, maybe like I'm a little on the fence on that one because it's like,

I get it. Like, if someone is trying to buy the controller and you're selling an aesthetic variant, you would want them to see all that. But if...

Like, I just don't think it's appropriate for social media. Like to me, it's like, to me, it's like social media is like a scrollable thing. I would just be like, like a purple controller, you know, and it's compatible with Xbox or whatever it is. Right. And that would be mostly it. Maybe, maybe that's too little. I'm sure there's going to be debate and stuff like that about this. Like there's going to be people that handle this differently and things, but yeah, that sounds like you and I are on the same page.

Now, I do have a sort of a section here that I'm not going to say audio wise, like totally not. This is a real world example that combines sort of a lot of the best practices that we discussed. It's basically like an article. So it's like how you would lay out potentially, and there's different ways to do it, but how you would lay out an article with different like...

here's my article, it has a header, it has a section, it has these buttons, here's some custom attributes, things like that. Again, totally, there's a bunch of different ways to do this. This is just one example that I found. And so this is gonna be in the show notes. It's under number four, combining best practices with a real world example, of course.

I'm not going to read all this. I was going to say, like, maybe I'll... No, no. Because it's going to be like, okay, guys, button, data, action, like. That goes into the footer now. Don't forget your like label. This is what you do ASMR, Matt. This is the section of ASMR. HTML, ASMR, subscribe. I have a buddy when I... Because we'll stream games on them sometimes, and he'll, like, crank his microphone volume up, get real close, and just start whispering, like, I reloaded. Hmm.

My wife. Oh, I hate that. Oh. I'm under attack in sector 17. Jesus Christ. Some tapping on the mic and stuff. Yeah. It's crazy. I love it, though. Like, I love the fact that he just, like, has that ready.

He just turns it on in like a second. But anyway, that's going to be the end of this episode. I hope you enjoyed it. I don't know when this episode is going to come out. We're getting close to the holiday season. This episode is going to be out on December 17th. Man, we have a Christmas Eve episode if we stick to the Tuesday schedule. We have a December 24th episode. We... Man...

Man, there's a lot of freaking... We should record a Christmas Eve episode, like a Christmas... HTML things Christmas episode. That's... Technically, it's your week, so enjoy making that themed. Get the Christmas tree, but audio-wise. This might be a Christmas album. We might be doing caroling. Are we taking... Like, we're gonna get...

I don't know, some insights and some songs from Mr. Bublé that we're doing here? We get Mr. Bublé out every Christmas? Get your vocal cords ready, Matt, because we're going to get a Christmas album going for the Christmas episode, so stay tuned. Should I literally buy Bublé? I'm just joking. We're not going to be singing. I have a terrible voice, but it's fine. Like, should I literally buy Bublé? And I don't mean the person. I mean literally the drink. Yeah, Bublé. Yeah, get some Bublé in. Well, because there's Bublé, so...

Michael Bublé is the spokesperson for bubbly in Canada, which is like flavored water. It's like LaCroix in America. And there's every holiday for the last couple holidays. There's been one called literally Bublé because he's the thing. They like cross out the Y in bubbly and they put that E with an exante goo for Bublé. So like you can buy Bublé the drink to represent the Christmas season.

And I drink bubbly like religiously. The bubbly community in general is a very meme-able thing. And having Buble there is just even better. I love it. I love it. I'm not going to mention the memes here, but if you're interested, there's a good Reddit bubbly form subreddit that is pretty spicy.

Oh, and I remember that. I do remember that thing. But I do distinctly remember being at the Grey Cup and they had a lot of bubbly ads and it was all buble because it was near Christmas because it was the COVID Cup. So they did it later in the year. It was in December, I believe. And it was buble. I got all the buble I could ever need singing about the bublies being stacked in the formation of a tree, like a Christmas tree, because they're all different colors. And I also believe that might have been the first year of buble as well.

So anyway, I don't know what else to say now. It was kind of weird. We went from web development to Buble. I'm not really sure what to do now. Just stay tuned for a Christmas episode of some sorts on Christmas Eve. If you have nothing to do on Christmas Eve, please listen to our Christmas episode. That's all I have to say. There you go. Also, Mike, entertain the fine people. I accidentally closed my Patreon document instead of opening it.

Okay, so the Christmas episode is probably going to be a take on the Star Wars Christmas episode, except we're going to combine it with HTML. So there's probably going to be some Wookieing. I believe Matt can do a really good Wookiee.

So 90% of the episode will have no subtitles and just Matt doing the Wookiee. Isn't like Grandpa Wookiee like jerking off or something in that? Or he's watching like Wookiee porn or something weird? Probably. I mean, Matt, you're going to have to reenact that in audio form. I haven't seen this in like 20 years or something. And I don't even know if what I said is true or something like that. There's 50% of the episode that's just Wookiee sounds without any sort of like subtitles. It's fantastic.

So, yeah, that's what we're going to be doing. So keep an eye out for that. Anyway, if you want to support episodes like this and not that, remember that we are on Patreon. You want to support the show, that is patreon.com slash html all the things. And many thanks to our $3 tier patrons.

Tim from Webhacker on thewebhacker.com. Jason from Geek Life Radio via geekliferadio.com. Garrett Segal, Level of Financial Planning via www.leveloffinancialplanning.com. Magnus from YesWeb via yesweb.se. Syntaxify from the HTML All The Things Discord server and Stacy Mostler.

from swoonworthydesigns.com. And we'd like to give a shout out to Michael LaRocca, a contributing author on HTML All The Things website. He is the author of Self Taught, the extra generation blog at selftoughttxg.com. Feel free to leave a comment or a review in the platform that you are listening to this on. And we are signing off.

You've been listening to HTML, all the things podcast, web development, web design, and small business. We hope you've gotten some useful and practical information from this show. And we hope you appreciate that. We talk to you like human beings and we hope you had some fun.

We'll be back soon. But in the meantime, hit us up on social media on Facebook, Instagram and Patreon at HTML all the things and on Twitter at HTML everything. Until next time, this is HTML all the things signing off.