(upbeat music) - Hi everybody, I hope you're enjoying today as much as I am, I am from Perth, I work with Patama which is great, it's awesome to have Perth people over here talking, Jason later as well, which is cool.
So just quickly there are some really amazing illustrations in my presentation, like this cool hand, I did not make these, I'm a developer, they're by Burnt Toast Creative, and they were super nice and let me use them in my presentation, so enjoy, they're beautiful.
Oh, I didn't turn my clicker on.
Okay I said before that I need to make sure I do it, because last time I didn't do it, and I just went and did it again.
Anyway, so moving on, why are we talking about HTML? Because obviously we heard yesterday there's a lot of amazing things to talk about, and I think HTML is pretty simple, do we need 45 minutes to talk about HTML, most of us have probably written HTML, and it allows us to get started really quickly, and get something out there with not a lot of effort, and it's very forgiving if we put an element in that doesn't exist, HTML is okay with that, it's gonna work with it anyway.
I think we make the mistake of thinking that because HTML is simple that it's not valuable. So today what I wanna talk about is why HTML is valuable, and even with all of the amazing things that we can do with JavaScript and CSS, HTML is still something that we need to invest time in. And I'm gonna tell you a little story about why I wrote this presentation, because it actually started here last year when I was talking at CODE about CSS, and I was on a panel, and I was here, on the chair, and I think John asked a question whether or not people hire anyone who just write HTML and CSS. And the response was that nobody did, and as a result of that, I went away, and I was like oh, Everyone's saying that CSS is really important, so I wrote an article, you may or may not have read it, it was called Is There Any Value in People Who Cannot Write JavaScript? (audience giggles) Yep.
So look, the title was a bit emotive I will admit, and thankfully the people that read the article before commenting found. (audience laughs) They found out that actually I do think there's value in people who can't write JavaScript, I think there's value in people who only write JavaScript, who only write HTML and CSS, and who do it like that and a whole bunch of things. But personally I think that HTML is extremely valuable, and it certainly feels like to me that it's becoming rare that people have a deep understanding of it, or at the very least are using it to its full potential. So I wrote that article and there were a lot of opinions. As I said some of them on just the title, but that's fine.
And there's been a heap of other discussions and tweets and forums and blog posts, all around the value and purpose of HTML and CSS in a world where JavaScript is king, everybody loves JavaScript, and that's what everyone wants to talk, because it's doing some really, really cool stuff these days.
But for me it's pretty simple, HTML is an important part of the web and it always has been. And we need to consider that the variety of people and technology that is consuming our HTML is vast, it's not just about the tech we have now like browsers and assistive technology like a screen reader, there's also search engines and reading apps and other tech that's going to take our code and do something with it, but there's also things that come next, so we have Google Home and Alexa, what happens when they read our websites for someone, how do they interpret our code, and will they be able to communicate in the way that we intended it to? So what I'm gonna do today is explore the way that different technologies interpret our HTML, and ways in which we can give our websites their best chance of being communicated the way that we want them to.
So that brings me to the title of my talk which is Functional HTML, and admittedly I'm clearly not very good at naming things, because when I named this I didn't even consider functional programming as a thing, and everyone was like you can't do functional HTML, and I was like, yeah, okay, that's right I didn't even consider that.
So the reason that I called it this, is totally unrelated to functional programming, I apologise, it's because of a quote I hear all the time from developers, and that's, "I'm just making it functional right now." And what that means is I've come to learn over the years, is that I'm writing the JavaScript, you know, the functional bits, and I'll make it pretty later.
And you know I can understand that, I totally get it, because JavaScript does a lot of really functional stuff for us, but the problem with relegating HTML and CSS in this case to just making things pretty, is that HTML plays a really important part in actually making our websites functional, because for something to be functional it has to be practical and useful and that has to work as we expect it to and not just for someone looking at it in a browser, but for people using all sorts of technologies to look at our site.
We have to consider a wide range of experiences, when we're developing our code.
However, given that the browser is the most common way that people consume our websites, I wanted to very quickly mention how the browser interprets HTML.
Now this could be a whole discussion in itself, so I'm gonna shrink it down into tiny little really simple way, it's clearly going to be way more complicated than this, but for the purposes of today, we write our code, like the cat in the GIF.
That's how I type, I'm sure you all do.
Then we have a sweet HTML file, and we're like here browser, whichever one you wanna use, this is my HTML, and the browser looks at it, and it doesn't just take it as is, what it gets is kind of like a big long string of text, and it has to go through that and start to build something that it can work with so it goes through the string and it starts to construct all of our HTML elements and create the parent and child relationships, until we get something that you're used to seeing when you inspect the code in Chrome or Firefox or whatever. And this is called the dom tree, or the Document Object Model.
And we use that to manipulate, edit and move things around. In order for it to display, there are some extra steps like the painting and compositing processes, I won't go into that, but why does it matter, how the browser interprets it? And I think it matters because the dom tree is constructed of what we give it, if we ask for it div it gives us a div, if we ask for an Element that says Mandy is amazing, it's gonna put that on the page for you, it will put your content in, it doesn't care what it is, it's just going to do what we've asked for. So at this point I wanna talk about TypeScript. I am gonna talk about TypeScript, so just stay with me, I have a point.
Has anyone used TypeScript or Flow? Cool, so quite a lot, that's awesome, so for those that haven't, TypeScript is a typed JavaScript language, it does everything that JavaScript does plus some extra things, and it makes use of static typing, so you can type your variables for example and when you write your code if you compile it and you try to pass a value in that doesn't match that type it'll throw an error and you can go and fix it. So if we create an interfacing TypeScript, this is a dog, it has a name which is a string, an age which is a number, is fluffy true or false, all dogs are cute but they're not all fluffy, so it can be false, my dog is fluffy and you will see a picture of him later. Now in TypeScript we define it and we assign a type to the data, and if I try and pass a number to name it will go now. No, we expected a string, you gave me a number, go and fix it, and you can.
And TypeScript, we're telling it what we expect our data or content to be, and it makes debugging, reading and writing and working with our code a lot easier, at least in my opinion, I'm sure some people disagree.
But basically we're being explicit about the shape of our data, and this is pretty much what we do in HTML. If we want a heading, we say we want a heading and we say what kind of heading it should be. If we want a list or a navigation item, or bold or italic or progress bars or video or images, HTML has a thing that we can use.
And there are a whole heap of elements that we can use to best represent our content. And we do this to define the shape of our content to make it easier to read, write and work with, and not just for us as developers, but for the technology that's going to read our HTML as well.
Now in TypeScript we have the concept of on any type, and when you assign a type of any it means the content can be anything.
This might be useful sometimes, but if everything in your interface is typed as any, then you use the benefits of the language.
You no longer get the type checking that TypeScript provides, and it starts to become pointless.
This is the same in HTML if you use divs everywhere, because you're not making the most of the language, it's really important that you actively choose what the right element is, and you don't just default to a div.
So if we take a look at a really simple example of a page about dogs, is called dogs are good.
That is my dog Jello, he is fluffy as you can see, and this only uses divs, even my links use divs, I used JavaScript to put an on click handler on there, and you can kind of see, I mean it looks like a webpage, but there's no real structure there, and the only meaning you get is from the white space that comes from it being a div and that being a block element.
Whereas if we look at a more semantic version, I've got links and lists and headings, and quotes, and you can already see that this is way more valuable than this, because there's meaning there, it's already more practical and useful, and you might think well sure, but I could just make that look like this with CSS, and you're right you absolutely could.
But first of all that's more work, and as Patama said, let's be lazy, but also not everything that consumes your HTML it's going to have access to your CSS and your JavaScript, it's going to evaluate the page based on the context of the HTML that you've provided. And it's easy to assume the way our HTML is going to be consumed is the same way that we as individuals interact with what we can see in the browser.
But there are so many technologies that try to use, read and consume our HTML that rely on us to use the language properly in order for it to make sense. Assistive text, search engines, apps, it's not just the browser and it's going to continue to be a variety of things the more we get into the future.
So I wanted to mention assistive tech first, because I think it's really important, but also it's a good way to, it's something that we're familiar with, and I think it's a good place to start, but basically using HTML as it's intended helps us to build webpages and applications that can be used by a wide range of people in a wide range of circumstances. And there are a bunch of different options for assistive technology, Google Home and Alexa are being used a lot more for accessibility purposes, screen readers, browser readers, switches, there's actually heaps of stuff out there.
What I'm gonna do is focus on screen readers, the main reason being it's the one I know how to use, badly, but I can use it, but also because it's voice and sound, I feel like it's similar-ish to how things like Google Chrome and Alexa will sort of sound when they try to read our content in the future. We will hear more about sound later from Jason so look out for that, it's gonna be exciting.
But anyway moving on, but first before we talk about the screen reader, I wanna mention the Accessibility Tree, because I find a lot of people don't actually know that it exists, And basically much like the browser creates the dom, it takes that dom tree and it modifies it to form something that's useful for assistive technologies.
And that's called the Accessibility Tree and it uses the native semantics to create an interface that's used for reading and navigating the page.
A screen reader for example is able to interpret the Accessibility Tree and reproduce the text and speech.
And some things they're stripped out of the Accessibility Tree, anything that isn't useful for someone who can't see the page, that's removed.
And other things are added in, so like form interactions, more information is added around the context needed for those interactions. So if we take my example from earlier, dogs are good, the div only version, if we were to listen to that in a screen reader, what does it sound like, what does a div only website sound like to a screen reader? To make it easier for I've used voice-over, there are captions, if you can read those, otherwise it will highlight every line that it reads so you can follow along, but remember that normally somebody is not going to be using this right, so if you wanna close your eyes and listen that's also fine. Okay are you ready? - [Screen Reader] Dogs are good, IDGA, web content.
You are currently on web content.
Dogs are good, IDGA, web content, home, good dogs, bad dog myths, dogs they are good, we are dedicated to educating the world on why dogs are good and how they can make your life good, and ow they can make your life good, by Mandy Michael, comma, August three, road, two, zero, one, eight. Why are dogs good? Dogs are loyal, intelligent devoted and affectionate, they are known to improve our physical and mental health, Michelangelo, also known as Jello, slash screen percent, two, zero, percent, two, zero, one, two, eight, zero.
- I won't make you listen to that okay.
(audience laughs) So first thing, that image thing was an accident, I took a screenshot from Instagram of Jello, his name is Michelangelo, but obviously the screen reader couldn't figure that one out but when I took the screenshot I didn't bother renaming the file, because I just totally forgot about it, and then when I recorded the thing I was like, oh yeah, there's no ALT tag, so rename your files, or use an ALT tag, because that was really annoying, there's a hundred characters in there, and it would have to read it all out, so don't do that.
But also, it sounds kinda like the other page, there wasn't really any structure, it didn't tell me that the first three things were links, so I had no idea what was going on there, and also I didn't really know what a heading was, it was pretty unclear, I found it a bit confusing when I was using it, I don't know about you.
Typically people using a screen reader, and when I tried to use them, I don't just read the whole page from top to bottom, I'll run it at a much faster pace, that is incredibly slow, and also they'd use keyboard shortcuts or other ways to navigate around, like via the headings, which this page doesn't have, so they can't do that.
Or via sections, which this page also doesn't have so they can't do that. So I'm basically making them read everything in order to find out if they actually want anything on my page, and more likely they're just gonna leave, because that's really annoying, and they probably will get to the screen, the photo and go nope.
So what about my properly structured page or my more semantic one, that's better I should say that not properly. What does that sound like? Again captions highlighting.
You got this.
- [Screen Reader] You are currently on web content, dogs are good, adjunct web content.
Navigation, Main navigation, one item, list three items, visited link, home, link, good dogs, link, bad dog myths, heading level one, dogs, they are good.
We are dedicated to educating the world on why dogs are good, and how they can make your life good.
Mandy Michael, August 3rd, 2018, heading level two, why are dogs good, dogs are loyal, intelligent, devoted and affectionate. They are known to improve our physical and mental health, a dog named Michelangelo also known as Jello. Image.
Dot.
Group International Good Dog Association.
- Okay so, obviously that was better, I knew what the links were, I knew if I'd been to the link before, it read out the headings, it didn't read out the file name of my image which was great.
Overall I was getting more contacts for the content I was looking at.
So my first point, that I spent the last 20 minutes getting to, don't just use divs.
I'm gonna quote Jeffrey Zeldman, I saw this quote recently I was like, I love that, and he said, "To build for people on the long term, "in simple, structural, semantic HTML was best, "each element deployed for its intended purpose." Don't use a div when you mean a P, or a paragraph.
And I think it's pretty simple right, make the most of what HTML is providing you, and there's a whole bunch of things that we can do to make sure that our content is best represented in our HTML, for example we can make use of sectioning elements, Now sectioning elements allow the automatic creation of a document outline, and this is used by browsers to provide an improved user experience.
And prior to HTML 5 we didn't have sectioning elements, so if we wanted to define a section we would use a div, and this made automating that document outline for the Accessibility Tree impossible, because how would you know the difference between a div that supposed to be a section and a div that's just for presentational purposes. So now that we have then we can create that automatic document outline, and that can be used by assistive technology and other tools as well to get a better idea of what's going on in the page. And there are four sectioning elements, first section, and this doesn't have any more semantic meaning other than it's a section, so you can use it for stand-alone sections, bits of content on your page, and because they appear in document outline, you don't wanna use this if it's a generic container, if it's a generic container that's just for styling, use a div, I know I said don't just use divs, but you can use them just in the right place, because they are valuable on occasion.
Now the next one is article, and this just represents the self-contained parts of the page, and if you think about content that can be distributed or reusable like in syndication, that's when you use the article element over the section, and this is common for news articles, blog posts, forums and that kind of thing.
nav as you would have heard, really useful for a screen reader, it announced that I had navigation on the page, and that just provides context around navigation items like menus and tables. aside is another one, and that's probably my favourite, because it allows you to mark up content without it being considered part of the main outline of the document, so this is often used for sidebars and callout boxes, like when you go to a news website, and they have related links smack bang in the middle of the article, that's probably an aside, because it's not part of the main outline of the page. And when you've got that sectioning structure set up you can create a clear structure and hierarchy, and this is used by assistive tech and search engines to better understand what the most valuable content on your site is, and what would make up a valuable preview in search results as well.
So if you have headings use headings, the h1 defines the main purpose of the document per page, and then the h2 to h6 are used as sub level headings. And in a screen reader they can take the headings from the page and create a list so you can skim the document to get an idea of what's going on. So you should always make sure that you put a heading in each section on the page, because that way they're getting a TLDR, they don't have to listen to everything including your badly named images.
And other things you can do is use the header. Now the header is not a sectioning element, it's more structural, and what it does is because it's not sectioning it doesn't introduce a new outline into the document, but it does help to group parts of content on the page. And this is used for main navigation, introductory content, heading elements, logo search, that kind of thing.
There's a footer element that does the same thing for footer content, and a main element does the same thing for the main part of the page.
So creating a clear hierarchy with your content is really important, and on the note of earlier from Patama being lazy, make the most out of HTML's built in functionality, you should always favour HTML's native elements over faking your own.
A really good example of this is the anchor element or a link, because this comes with so much functionality that you don't have to redo, it navigates to a new page or view by default, you can change the URL, it causes the browser to redo or refresh, it's focusable by default with the HREF attribute, you can click it with the Enter key, it opens in a new window, it has link, visited, focus and active states all by default.
Why would you wanna build this again? I don't have time for that, I have dogs to play with.
(audience laughs) And if you need a button element, use the button element, it has a whole bunch of stuff, including but not limited to, receiving keyboard focus by default, you can click it with the Space Key, it resets a form or sends a form to a server, it can be disabled by default with this disabled attribute, and it can show focus, hover, active and disabled states, we don't need to rebuild the web, because HTML already gives us a lot of this for free. And a common thing that I see people do is getting button and the anchor element mixed up, and I understand, 'cause sometimes, especially in our designs we use them interchangeably. But the way that I look at it, is a link navigates the user to a new URL, a button toggles something in the interface like a video player or a pop-up menu.
A good rule of thumb that I like to follow, is if it's got a HREF, it's a link, if you disable the HREF, with prevent default or something, it's probably a button, now you know that there's probably some situations where that's not true, but it's a good starting point, so always ask yourself that question.
Now another thing that you can do with HTML is combine elements for better context, and a really awesome example of this is the figure and the figcaption.
Now they are often used for images, illustrations, diagrams, code snippets, and it represents a self-contained unit of content. And this means that if you were to move the element down the page it wouldn't affect the meaning of the document. So as a result, not every image or figure or whatever is a figure element, sometimes you don't use it, but when you do you can have a figcaption optionally, as a legend or a caption to that figure, and inside the figcaption you can use more HTML elements, you can use the flow elements like paragraphs and headings to make that even better. And you can use the pre element inside the figure with the fig caption with your flow elements. In the pre element displays pre-formatted text or code, and respects the white space that you've put in your HTML document.
And it's usually rendered with a mono-space font, and if you put the pre element inside a figure with the fig caption, a screen reader can read that out and use the fig caption instead of having to read every individual character of the pre element.
But my most favourite combination, is abbreviation and definition elements, now I love these because it tells browsers, search engines and the browser as well, sorry us looking in the browser, that the abbreviation is associated to a definition. And it looks like this, I wanted to show the code because it's kind of hard to explain without it, but basically I have a definition about the International Good Dogs Association, they determine that all dogs are in fact good, and I have an abbreviation, IGDA, and I wrap that in the abbreviation element and put a title attribute on it, and that says International Good Dogs Association, and then around the abbreviation I put the definition element, and what that says is this paragraph defines IGDA, which is an abbreviation of International Good Dogs Association, and I think that's pretty cool, because that's a lot of context that we wouldn't have had otherwise.
And there are so many HTML elements, keyboard I like, KBD, Marks up, Ctrl + C, Ctrl + V, if you put that in your page like a little keyboard thing, progress, is a progress bar done for you, video comes with controls like play and pause and all sorts of things.
The bidi one, which actually I read as bidi, but it means bidirectional, so you can have right to left content.
There's word break and mark and audio, track, and there are so many.
You don't need to know them all, because Mozilla Developer Network has an amazing list of them, you can search it like a keyword, and it'll come up, and it'll tell you how to use it.
And I kind of figure like, we have so much to do, we've gotta do linting and tests, we've got all these complicated deployment processes and build chains, we have to name things, If we can like get some pre-done stuff we should, because it's gonna save you a heap of time, and it's also gonna make your project more understandable to people, bots, and other code that's trying to read it, so as Patama said, be lazy, don't recreate stuff, 'cause HTML's got you covered, it's like your best friend that you haven't really appreciated, and then one day they're not there, and you're like, damn they were really good to me. (audience laughs) Yeah right.
Now, the point of my presentation isn't to teach you HTML, because I wanted to show you how HTML is consumed by different technology, and a really good example of this is reading apps, so reading apps like against Instapaper and Pocket, they take the structured content of the page and they display it with custom styles. And they offer improved readability and options for personalization, and people can use these for any number of reasons, better accessibility or just enjoying the aesthetics. So Instapaper is the one that I use, and you can save articles into it to read later in their own format.
And this is what the div-only version of my dogs are good page looks like.
It's kind of rubbish, like the original version, there's no structure there, the link elements are just part of the text, whereas if we look at the more semantic version, it looks a lot better.
Much like the original page.
But what you may or may not have noticed, is there's no links in this page, because the reading app has gone you don't need links because we're reading it in the page, I'm just gonna put in the main content, and it's put my name and date up to the top and styled them differently, and that information, the name and the date is really important in a reading app, especially when you have hundreds of articles in there, that you very well intend to read at some point. Because how do you know who wrote it and when they wrote it, if that information's not there, and in my previous example with the divs, whilst technically the content's there, it's like halfway down the page, so you might not see that originally, so that's really important, not just for users but as a publisher, if it doesn't say that you wrote it, how do people know to go and read more of your content? Now Pocket is another example, I don't actually use Pocket, but I experimented a bit for this, and it was a really interesting use case.
This is what it looks like in the web view, these are both of my articles, this first one is the div-only version, that is not the title of my page, well it's not the heading of my page, it's the title element of my page, Dogs Are Good, I spelt IDGA wrong.
So that's pretty rubbish, it also isn't displaying my image, sometimes it would display random text instead of the image, but not from the top, like halfway down the page, I don't know why, not really sure, I couldn't read that in their app, I can only view it on the original site, and it was pretty clear to me that Pocket was having some trouble with my divs.
It even took a lot longer to process, and that page was not very long.
Also, so while I couldn't read it in the desktop, web view or the mobile app, I could read it in the desktop app, but it flagged that there was something wrong with my page, and that maybe I should go look at it from the original website, that's kind of rubbish, that makes me look a bit bad, I kind of looked at that and went oh, and then I went "Wait, I wrote the page, "it's probably fine I can go there." So this isn't ideal, whereas the other one, adorable.
(audience laughs) Dogs clearly are good, it uses my h1 from the page instead of the title element, and it's loading in the adorable picture of Jello. And I could read it in Pocket Reader.
And it looks great, they've added their own styles in, so they can hook into all of my HTML elements to do that. And also it's included my byline and the date at the top as well, so you know that I wrote this very important article about why dogs are good, and you can know that it's from a legitimate source, and its relevant, it's not from five years ago, they were still good back then, but you know, we need to be timely, like with push notifications.
And the last one that I wanted to mention is Safari's Reading Mode, because this is my favourite and I use it all the time. And you can access it is Safari and iOS by clicking the little lines next to the URL bar, now if the button isn't there, it probably means there's something wrong with the structure of your page and it couldn't figure out how to apply Reading Mode. For the record my div version did not work, I could not use reading mode.
But I've got to be honest with you, I have misled you a tiny bit, in that on Pocket and Instapaper originally, my name and the date was not at the top.
And when I looked in Reading Mode, not only was my name and the date at the top like the Washington Post's website which is what I use to trial things, some of my content was missing as well, like my lists and my quotes, and I couldn't get it to work properly, stuff was being ignored.
I panicked, because I was like this undermines the whole point of my presentation, what am I gonna do, my life is a lie, HTML doesn't matter, I don't know what to do anymore, I had a bit of a crisis.
But after I calmed down, I played with my dog, I realised that it's okay, dogs are good, I can do this, I'd forgotten about HTML attributes, I've been focusing on HTML elements, because clearly they're important, but I wasn't considering the attributes, which is arguably what makes HTML the most powerful. So I played around with it a bit, and I got my name and the date and a description, and I got that to work in Safari's Reader Mode, in Instapaper and Pocket, my life was right again, I felt good, I didn't have to worry about my life choices. Now I am gonna tell you how I did it, but first I'm gonna talk about search, so will come back to it, and the reason I wanted to talk about search is because it is related, now search engines they rely on crawlers that index websites for content, and then they use algorithms to determine the relevance of that content to search keywords. And they behave a lot like screen readers, in that at least for the time being they can't intelligently understand images, video or audio, so they benefit from text alternatives and well-written content.
Now a lot of the stuff that we've looked at already like structure and hierarchy, that plays a very important role in getting good SEO for your site.
And when you look at a typical search result from Google, what it does is it takes the title element of the page, and then it uses the h1 and the h2 to give you an idea of what the content is.
And when the HTML's page isn't structured properly it can have a really negative impact on your SEO and your previews.
'Cause it's much harder to identify what the most valuable content on the page is. So the more information and context that you give search engines, and browsers and other tech, the better it can match your site to relevant keywords, and the better it can render your content.
So this brings me to the way that I solved my Safari Reader and Instapaper and Pocket problems, microdata.
Now microdata is used to nest metadata within existing content on a page, and search engines, web crawlers, browsers and apps can extract and process microdata from a webpage to provide a richer browsing experience. And in order to use microdata we need a schema, and schema.org provides a collection of shared vocabularies about types of content, and we can use this to mark up our page in ways that can be understood by different forms of technology like search engines.
And there are all sorts of types of content, like person, article, creative, work publisher and so on, and we can use that in HTML with these three attributes, - Itemscope, item type and item prop.
So I'm gonna show you a way that you can get your name to appear in Instapaper or Pocket or whatever, by defining a person metadata for my site.
Some I have a paragraph and inside that it says by Mandy Michael, and what I'm gonna do is add the itemscope item to the paragraph, and what that does is it creates a new item and anything inside that paragraph is considered the scope of my item.
Then I add the item type attribute, and I use the schema for person, and this describes my content as a person, and there are a whole bunch of different things you can do to mark out the content inside of your items come as a person, like, age gender things I'm good at, hugging dogs.
Hopefully CSS and HTML, but who knows.
So the way that I then say okay well Mandy Michael is the author of this page, I use item prop, I wrap the span around my name to do that, and then I just reference author, and then the document and anything that consumes the document knows that I am the author of that document, because sometimes the elements themselves aren't enough, sometimes we need to provide additional information, or data along with our HTML, because technology it doesn't know the difference between a paragraph with my name in it, and the paragraph with some other random text, we have to be more explicit about it, and microdata and HTML attributes help us to be more explicit with our HTML.
And there are a lot of useful HTML attributes that you can use, Aria attributes are another one, and that's used by assistive technology to help provide more context to screen readers and other assistive tech, do so and we were talking about this yesterday, you can add a type of email on to inputs and ill expect an email, you can put a label on the navigation element, and say what kind of navigation it is, main navigation, related links, footer, all this information is relevant and useful context to whatever is trying to consume and read our webpages.
Now I've shown you a very, very small subset of technology that tries to use our websites, and there are a lot of different ways that people and technology try to consume interpret and display our content, and we've seen the impact that even a simple webpage with non-semantic HTML can have on those technologies if we're not using HTML correctly, and that it doesn't really expect the way, it doesn't really work the way that we expect it to. And I hope, I really, really hope that the next time you start writing your website or your blog, or your demos and your tutorials, that you make the most out of what HTML provides, because we have new people starting in our industry every day, and if they see your demos and your tutorials and you're just using divs, they're gonna think that that is how they should do it, because nobody's told them otherwise, and I know that there are a lot of really exciting things in web development that we wanna share, but we have to remember not to forget about HTML, and everything that it does for us, because HTML is not just the foundation that we build our websites on, it plays a vital role in making our website function as expected across platforms and technologies. And if you use HTML to its full potential from the beginning, you're not just making the most out of built-in features, you're making it functional for people, bots, technology, not just now, but anything that comes next, you're saving yourself a heap of time.
So that's all, thank you so much, I just wanted to say thanks to Julie, she's here, she gave me help on the accessibility stuff, and Ricky Mondello to rescue me from my life crisis Safari's Reading Mode, but also a special thanks to Burnt Toast Creative for their amazing illustrations, thank you.
(audience applauds) (upbeat music)
