Industry News by Claire Remmert Dec 4, 2017 Should I bother with Semantic HTML? With all the modern front-end frameworks and tools it’s easy to forget that HTML is designed to give your content meaning on its own, at the foundational level, before you apply any CSS or JS. I have seen many developers visibly cringe at the thought of writing HTML of any kind. I’m here to tell you: while it may seem like extra work, semantic HTML will make your life (and your users lives) a lot easier. Cross my heart. Semantic HTML: Using meaningful tags to describe your content. Any “markup language” has two basic components: the content, and the markup. In HTML, the markup is called tags that describe the content inside them. “Semantic HTML” is choosing tags that meaningfully describe the content they contain. HTML has always had semantic tags, such as <p> for paragraphs and <h1> for section headings. HTML5 introduced even more semantic elements like <header>, <section>, <nav> and <footer> that pretty much all browsers support. It seems like common sense, but there’s nothing about HTML that requires developers to use semantic tags, and many fall into the trap of “div soup” – using tags that carry no inherent meaning. Div Soup vs Semantic HTML It can feel easier to use <div> and <span> to contain our content, knowing that we can create visual meaning on our own using CSS and JS. But there are many reasons to make sure your markup is semantic. Why worry about it? Accessibility tools depend on it. When a user visits a page with a screen reader, no JS or CSS are taken into account. Let that sink in. If you had a moment of panic wondering if your website would make any sense without CSS or JS, you’re not alone. Semantic HTML promises at least a basic level of structure and meaning for all. Many screen readers have functionality that scans headlines or links, similar to the way visual readers scan through large amounts of text. Using a <button> element allows for built-in keyboard controls like tabbing and hitting ‘return’ to select. For more semantic markup examples related to accessibility, check out this article from MDN. In case you might be one of those people who say “why should I waste time and effort for such a small number of users” (other than just to be a good person and stop ignoring the experience of people with disabilities) consider this: “In a study put together by Google based on data from the World Bank (WDI, 2008) and CDC.gov (NHI Survey, 2008), it was found that there are more hard of hearing users in the United States than the population Spain and more users who are blind and low-vision than the population of Canada.” http://www.interactiveaccessibility.com/accessibility-statistics It affects search engine results and indexing. Search engine crawlers use HTML tags to extrapolate meaning and structure from the vast sea of web content, which means semantic markup increases the chance that an engine will find your site and correctly understand your content, and who might want to see it. Makes use of default styling and functionality. Not Semantic HTML Semantic HTML The first example uses only <div>s and <span>s to markup the content. The second uses correct tags like <h1> and <h2> for headings, <p> for paragraph text and <ul> for a list. This is also true for default functionality of interactive elements like <input>, <label> and <button>. Let the browser do the work it’s built to do by giving it the context it needs to know how your elements are supposed to work. Makes for a healthier code base. Writing Plain Old Semantic HTML as it’s often called (or POSH, the Spice Girl I always wanted to be) is often simpler, more lightweight and easier to maintain. Consider this example: a colleague of mine discovered this in a product he recently started working on: <div class=”footer-fake”></div> What could this mean? What does it do? Why is it there? Why is the class name trying to trick me? So much unnecessary time and brainpower went into figuring out that this <div> was purely there to push the real footer down on the page. And will we ever truly know if there were other reasons for its existence? This is a prime example of using HTML for presentation rather than content, and not considering how future developers might need to understand the document structure. Mistakes you’re probably making: “But I’m using a framework! I don’t have control!” Remember div soup? There are a lot of modern frameworks that, while great for quickly building layouts without writing any CSS, require a lot of hoop-jumping in your markup for the styles to work (looking at you, Bootstrap). Remember: you are always in control, and can use your knowledge to give order to the madness. For example, you can use mixins in Bootstrap to eliminate the div soup, use more meaningful class names and elements, and still get all the seductive power of Bootstrap without the technical debt. <i> don’t know what this is supposed to <b> This one is quite well-known at this point, but it’s worth a reminder why the elements <i> and <b> are not considered semantic: because they exist for style, not meaning. Use <em> for emphasis and <strong> to drive a point home. <br>b, just gonna break the logical flow real quick Ah, the ever-tempting line break. I am definitely guilty, we are all guilty of throwing this simple element into a document for quick spacing fixes. Anytime an element exists with no relationship to content or meaning, we can assume it’s not semantic. Let us admit our sins and repent. Margins and padding are our friends. Use <br> sparingly, in situations like poems or addresses. Headings in all the wrong places This is one of the most common mistakes I see people unknowingly make. Using an <h4> at the top of the page because it looks better. Going from <h1> to <h6> back to <h2> within the same section. Using two different heading elements within the same sentence. Here’s some basic rules to follow: Only use one h1 per page, matching the page title whenever possible. The headings taken out of context should logically represent the page content for screen readers and users who choose this option as a way to scan the page. Try not to skip heading levels when increasing, but you can skip levels when decreasing (h1, h2, h3, h2, h3, h4, h2, h3, h4). How to be better: Think about your content in terms of its structure. Imagine that you’re making an outline of a document (because you are). Use your markup to establish a clear hierarchy that would be easy to scan and understand. If you’re ever not sure which tag to choose, check out this handy flowchart from HTML5 Doctor: Which Semantic Element to Choose: a Flowchart Choose tags to establish meaning, not style. Avoid the “footer-fake” flub. If you are including an element purely to adjust the way the page looks, ask yourself if you could use CSS instead. Odds are, you can, and you (and any other developer who looks at your code) will be glad you did. Do your best, when you can. It’s not all or nothing. The truth is that there’s non-semantic HTML all over the web for all kinds of reasons, and we don’t always get to control it or be responsible for it. I know I am guilty of choosing “simple” over semantic, and sometimes priorities and time constraints dictate that quick fixes are necessary. But I also believe in doing my part to make the web better and more accessible to all, and I know it’s a righteous and worthwhile endeavor to use semantic markup whenever possible.