Search for a command to run...
Improve website accessibility, SEO, and make styling easier by steering clear of these HTML bad habits!
I'm a front-end developer, digital artist and creative director at Plugin Studios, a digital marketing agency with a visual twist. When I'm not working on projects or learning new tricks, you'll find me digital painting or riding my bike around London.
No comments yet. Be the first to comment.
HTML, short for HyperText Markup Language, is considered the easier part of web development. As a markup rather than a programming language, HTML doesn't require a high degree of logic to master. For an in-depth look at why HTML is easier than a full blown programming language like JavaScript, I highly recommend reading this article by Darcy DeClute. Aside from being easy, HTML is also pretty forgiving in terms of mistakes. For example, a forgotten closing tag here or there, or some misspelled syntax, won't necessarily stop a web page from rendering.
Unfortunately, HTML's easiness and forgiving nature, often makes front-end developers far too lax about their HTML code. Don't forget, HTML, despite its many shortcomings, is still a foundational pillar of web development. Being reckless with HTML comes with some dire consequences, especially in areas related to SEO and accessibility. Below, I've listed the 5 common bad HTML habits I've come across during code reviews over the years and the corresponding best practices.
The <div> element is the jack of all trades when it comes to CSS. If one needs a container in order style, then a <div> might be the right choice. The downside of using a <div>, however, is it doesn't contain any semantic information about the page. In today's modern web environment, where accessibility is of paramount importance, its best to exhaust all the semantic elements HTML has to offer, before making a grab for a <div>. Placing text directly between a <div> is definitely an inferior option to wrapping it between a paragraph (<p>) tag. Semantic HTML elements go a long way in helping screen readers and other assisted technologies interpret a site. In particular, many forget to use the structuring semantic element listed below.
<!-- Grab these semantic tags instead of a <div> to
structure you page: -->
<!-- MAIN -->
<main>
Main should contain the main part of the page,
but not repeated content like header or footer content. A
page should only have one main tag.
</main>
<!-- SECTION -->
<section>
Use section to define a generic area of a page.
If someplace on a page has natural heading attached, odds
are it should be inside a section element.
</section>
<!-- NAV -->
<nav>
Use to wrap main navigation links. The typical ul
and li navigation pattern should have a nav parent
someplace
</nav>
<!-- ARTICLE -->
<article>
Articles wrap self-cotnained pieces of content. Artilces
may be ancestors of sections and also descendent of a section.
</article>
<!-- ASIDE -->
<aside>
The aside element should parent content that relates,
but not directly to other content. Sidebars, tips, maybe even
to contain a quote.
</aside>
<!-- HEADER -->
<header>
Holds the header or introductory content of a page
or a section of a page (not to be confused with the "head"
element.
</header>
<!--FOOTER -->
<footer>
Footer holds closing information for either an entire page
or a section.
</footer>
The alt attribute on the image tag is hugely important for three reasons. First, the alt attribute allows the visually impaired to know what is being displayed. Second, it provides some idea of what was intended to be displayed if the image has issues rendering. Third, search engines look to alt tags to determine the meaning of the page. Good alt image descriptions might just give a web page that extra SEO boost. What makes for a great alt attribute description? Check out this article from Sam Graves on the Allyant website for some pretty good guidelines.
Buttons should be used for actions that affect the website’s front-end or back-end Meanwhile, anchor tags (links) should be used for navigation to somewhere on the same page, within the site, or elsewhere on the internet. If UI/UX calls for something like a button for navigation, then style an anchor element to appear like a button. Using button and anchor tags incorrectly causes massive confusion for those using screen readers.
Using <br>, the line break element, for some extra spacing on a web page, may be quick fix, but its not the right approach. In fact, <br> should be reserved only for a single situation: when breaks are actually part of the content, such as in poems or addresses. The following taken from WC3 exhibits what's good and bad practice:
<!-- Good Practice -->
<p>P. Sherman<br>
42 Wallaby Way<br>
Sydney</p>
<!-- Bad Practice -->
<p><label>Name: <input name="name"></label><br>
<label>Address: <input name="address"></label></p>
Bad use of the <br> throws up all sorts of issues. For one, <br> is not semantic, raising the risk that screen readers and other assistive technologies fail to interpret the line break. In certain cases, <br> elements can also wreck havoc with responsiveness on different types of screen sizes. Rather than hard code line breaks with <br>, developers should make the most of the margin and padding styling options available through modern CSS to avoid issue.
Out of all the bad habits mention thus far, styling an element via the style attribute ranks as one of the worst. Event today, a lot of courses and text books introduce the style attribute during the early stages of learning because its easy. I find this remarkable, because it causes major debugging problems later on when trying to style the page through CSS using conditional styling in JavaScript. The core problem with inline styles is their high degree of specificity relative to other CSS selectors.
CSS Selector | Specificity Points |
Universal Selector (*) | 0 |
Element or pseudo-element | 1 |
Class, pseudo-class, attribute | 10 |
ID selector | 100 |
Inline style attribute | 1000 |
!important | 10000 |
In fact, aside from a CSS declaration made using the !important keyword, inline styles trump every other selector in terms of specificity points. In other words, once inline styles are in place they are very difficult to override from a CSS stylesheet. To avoid this problem, always style using CSS and never use inline styles!
The list above represents just a few of the most common bad HTML habits that I've come across. HTML, although easy to learn and forgiving when it comes to syntax, shouldn't be rushed. Well structured HTML is the first step toward a well designed website that fully considers SEO, accessibility, and usability!