As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like <span> and how they differ from block ones like <div>. This will save you a huge amount of headache when fiddling with your CSS code.
This riled me too. But, as it’s Consumerfest and goodwill to all is compulsory, I calmed down. And I don’t want to instigate a pile-on of the author of this piece; it’s indicative of an industry trend to regard HTML as a bit of an afterthought, once you’ve done the real work of learning and writing JavaScript. If the importance of good HTML isn’t well-understood by the newer breed of JavaScript developers, then it’s my job as a DOWF (Dull Old Web Fart) to explain it.
Gather round, Fullstack JavaScript Developers – together we’ll make your apps more usable, and my blood pressure lower.
What is ‘good’ HTML?
Firstly, let’s reach a definition of ‘good’ HTML. Many DOWFs used to get very irked about (X)HTML being well-formed: proper closing tags, quoted attributes and the like. Those days are gone. Sure, it’s good practice to validate your HTML, just like you lint your JavaScript (it can catch errors and make your code more maintainable), but browsers are very forgiving.
In fact, part of what we commonly call ‘HTML5’ is the Parsing Algorithm which is like an HTML ninja – incredibly powerful, yet rarely noticed. It ensures that all modern browsers construct the same DOM from the same HTML, regardless of whether the HTML is well-formed or not. It’s the greatest fillip to interoperability we’ve ever seen.
By ‘good’ HTML, I mean semantic HTML, a posh term for choosing the right HTML element for the content. This isn’t a philosophical exercise; it has directly observable practical benefits.
For example, consider the <button> element. Using this gives you some browser behaviour for free:
A button is focusssable via the keyboard. I bet you, dear reader, know all the keyboard shortcuts for your IDE; it makes development much faster. Many people use only the keyboard when using a webpage. I do it because I have multiple sclerosis – therefore the fine motor control required to use a mouse can be difficult for me. My neighbour has arthritis, so she prefers to use the keyboard.
Buttons can be activated using the space bar or the enter key; you don’t have to remember to listen for these keypresses in your script.
Inside a <form>, it doesn’t even need JavaScript to work.
“What’s that?”, you say. “Everyone has JavaScript”. No, they don’t. Most people do, most of the time. But I guarantee you that everyone is without JavaScript sometimes.
Here’s another example: semantically linking a <label> to its associated <input> increases usability for a mouse-user or touch-screen user, because clicking in the label focusses into the input field. See this in action (and how to do it) on MDN.
This might be me, with my MS; it might be you, on a touch-screen device on a bumpy train, trying to check a checkbox. How much easier it is if the hit area also includes the label “uncheck to opt out of cancelling us not sending you spam forever”. (Compare the first and second identical-looking examples in a checkbox demo.)
But the point is that by choosing the right element for the job, you’re getting browser behaviour for free that makes your app more usable to a range of different people.
Invisible browser behaviours
With me so far? Good. The browser behaviours associated with the semantics of <button> and <label> are obvious once you know about them – because you can see them.
Other semantics aren’t so obvious to a sighted developer with a desktop machine and a nice big monitor, but they are incredibly useful for those who do need them. Let’s look at some of those.
HTML5 has some semantics that you can use for indicating regions on a page. For example, <nav>, <main>, <header>, <footer>.
If you wrap your main content – that is, the stuff that isn’t navigation, logo and main header etc – in a <main> tag, a screen reader user can jump immediately to it using a keyboard shortcut. Imagine how useful that is – they don’t have to listen to all the content before it, or tab through it to get to the main meat of your page.
And for people who don’t use a screenreader, that <main> element doesn’t get in the way. It has no default styling at all, so there’s nothing for you to remove. For those that need it, it simply works; for those that don’t need it, it’s entirely transparent.
Similarly, using <nav> for your primary navigation provides screenreader users with a shortcut key to jump to the navigation so they can continue exploring your marvellous site. You were probably going to wrap your navigation in a <div class=”nav”> to position it and style it; why not choose <nav> instead (it’s shorter!) and make your site more usable to the 15% of the world who have a disability?
For more on this, I humbly point you to my 2014 post Should you use HTML5 header and footer?. A survey of screenreader users last year showed that 80% of respondents will use regions to navigate – but they can only do so if you choose to use them instead of wrapping everything in <div>s. Now you know they exist, why wouldn’t you use them?
New types of devices
We’re seeing more and more types of devices connecting to the web, and semantic HTML can help these devices display your content in a more usable way to their owners. And if your site is more usable than your competitors’, you win, and your boss will erect a massive gold statue of you in the office car park. (Trust me, your boss told me. They’ve already ordered the plinth.)
Let’s look at one example, the Apple Watch. Here are some screenshots and excerpts from the transcript of an Apple video introducing watchOS 5:
We’ve brought Reader to watchOS 5 where it automatically activates when following links to text heavy web pages. It’s important to ensure that Reader draws out the key parts of your web page by using semantic markup to reinforce the meaning and purpose of elements in the document. Let’s walk through an example. First, we indicate which parts of the page are the most important by wrapping it in an article tag.
Specifically, enclosing these header elements inside the article ensure that they all appear in Reader. Reader also styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.
(If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.)
Apple WatchOS also optimises display of items wrapped in <figure> elements:
Reader recognizes these tags and preserves their semantic styles. For this image, we use figure and figcaption elements to let the Reader know that the image is associated with the below caption. Reader then positions the image alongside its caption.
You probably know that HTML5 greatly increased the number of different <input> types, for example <input type=”email”> on a mobile device shows a keyboard with the “@” symbol and “.” that are in all email addresses; <input type=”tel”> on a mobile device shows a numeric keypad.
On desktop browsers, where you have a physical keyboard, you may get different User Interface benefits, or built-in validation. You don’t need to build any of this; you simply choose the right semantic that best expresses the meaning of your content, and the browser will choose the best display, depending on the device it’s on.
In WatchOS, input types take up the whole watch screen, so choosing the correct one is highly desirable.
First, choose the appropriate type attribute and element tag for your form controls.
WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
Secondly, it’s important to note that unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
I didn’t choose to use <article> and itemprop and input types because I wanted to support the Apple Watch; I did it before the Apple Watch existed, in order that my code is future-proof. By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users. You are opting out of this if you only use <div> or <span> because, by definition, they have “no special meaning at all”.
Summary
I hope I’ve shown you that choosing the correct HTML isn’t purely an academic exercise. Perhaps you can’t use all the above (and there’s much more that I haven’t discussed) but when you can, please consider whether there’s an HTML element that you could use to describe parts of your content.
For instance, when building components that emit banners and logos, consider wrapping them in <header> rather than <div>. If your styling relies upon classnames, <header class=”header”> will work just as well as <div class=”header”>.
Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
And, best of all, thinking more about your HTML will stop Dull Old Web Farts like me moaning at you.
What’s not to love? Have a splendid holiday season, whatever you celebrate – and here’s to a semantic 2019!
More!
How to Learn CSS – Rachel Andrew’s on the core concepts of CSS that will help you work with CSS, rather than against it.
A (usually) weekly round-up of interesting links I’ve tweeted. Sponsored by Smashing Magazine who slip banknotes into my underwear so I can spend time reading stuff.
A (usually) weekly round-up of interesting links I’ve tweeted. Sponsored by Smashing Magazine who slip banknotes into my underwear so I can spend time reading stuff.
The Baseline Costs of JavaScript Frameworks – “Your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it. Your Angular app will always take at least 2.7 seconds to boot up.”
The dialog element – intro to this very useful element. browser support is about 70% globally, behind a flag in Firefox. Polyfills are available.
Ways to extract slides – techy post by Remy Sharp. “When you run events, once everything is over, it’s nice to be able to share the slides both as a single link but also for the video production*… this post is reminder for my future self on how to do that.”
Programming CSS by Jezza Keef. “It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.”
Twitter and KaiOS take on KaiOS-powered smart feature phones – KaiOS is the successor to FirefoxOS, and Twitter made a PWA for it, despite “those designing the products couldn’t be further removed from the people whom the products are intended for”. Here’s how.
Open-source wedding site – “Now that my wedding is over, I am open-sourcing it”. fully responsive, RSVP uploads to Google Sheets & emails; Add to Calendar feature; single-tap book Uber to venue; no DB required – uses GitHub pages
Acme Inc is organizing and sponsoring Timbuktu’s biggest annual developer conference called “Timbuk-Toot!”. Past speakers include Richard Stallman, Morgan Freeman, Humphrey Bogart and Cruella de Vil.
Would you like to give a workshop or a talk at Timbuk-Toot! in February 2019?
Let me know!
And that was it. It’s not nearly enough information to make a decision, so —unless it’s from someone I know, or I’ve always always wanted to visit Timbuktu— I park this, thinking “I’ll email back and ask them for more information”. Then, of course, the rest of the day happens and I forget about it.
So, if you’re emailing someone to ask them to speak, at a minimum I’d need this information:
what do you want me to talk about? What’s the theme of the conference?
How long is a talk? How long is a workshop?
Are the talks recorded? Are they available to all, e.g. over YouTube?
How many people attend? Who attends?
You mention Acme Inc; is it an internal Acme staff conference, or open to the public?
What are the dates? How can I answer when i’m only told “February 2019”?
Are you paying for my flights/ accommodation? I suspect not, as you don’t mention it.
If you are covering travel expenses, am I expected to pay them and get them reimbursed? If yes, how many days does it take for me to get my money back? (A the moment, over Xmas, I’m giving an two-month interest-free loan of 1000Euro to a conference.)
If I’m a freelancer, are you paying a fee for my time? I suspect not, as you don’t mention it.
Is there a code of conduct? Where is it? Is the speaker line-up inclusive? (Probably not, if you’re not paying expenses or a speaker fee.)
You need to tell me why I should care about it. You might be huge in the Timbuktu web industry, but I don’t know you. So far, all you have done is raise questions which means I have to reply to you and ask them, on top of all the other things I have to do today.
A (usually) weekly round-up of interesting links I’ve tweeted. Sponsored by Smashing Magazine who slip banknotes into my underwear so I can spend time reading stuff.
Service Workies – “Learn Service Workers inside and out with the new PWA Mastery Game
W3C Strategic Highlights October 2018 – “we believe that having two distinct HTML and DOM specs claiming to be normative is generally harmful for the community”; joint work to be at WHATWG if I understand correctly
Chrome Dev Summit 2018 Day 2 Keynote (YouTube video) –
good news from the Chrome team: frameworks will be 1st class citizens: included in intent to implement notices; $200K of funding to improve performance; collaboration between Chrome team and framework devs
Braces to Pixels – Greg Whitworth explains how broozers take your CSS and make it into what you see on screen. It ain’t easy, and this is why Houdini will be so super – you’ll get all of this for free, and just hook into the bits you want to change.
A (usually) weekly round-up of interesting links I’ve tweeted. Sponsored by Smashing Magazine who slip banknotes into my underwear so I can spend time reading stuff.
The Strong tag, <strong>, and the Emphasis tag, <em>, are considered Semantic Markup that allows for added meaning to your content. It serves as an indication to a screen reader of how something should be understood.
Whenever I read “some browsers” or “some screenreaders”, I always ask “but which ones?”, as did Ilya Streltsyn, who asked me “what is the current state of the text-level semantics in HTML reality?”
Léonie Watson to the rescue! Over Twitter, Watters wrote
Most are capable of reporting these things on demand, but do not as standard. So you don’t hear the text/font characteristics being announced as you read, but you can query a character/word etc. to discover its characteristics. This is based on the visual presentation of the text though, rather than through any recognition of the elements themselves (which as @SelenIT2 notes, are not mapped to the acc API).
Ilya (@SelenIT2) noted that “almost no text-level semantic element has a direct mapping to any accessible object”, linking to HTML Accessibility API Mappings 1.0 to demonstrate. This means that even if a screenreader vendor wanted to pass that information to a user, they can’t, because the browsers don’t expose the information to the Accessibility Tree that assistive technology hooks into.
Ilya also pointed my to a GitHub issue on the NVDA screenreader “Semantic support (not just style support) for del and ins on web pages”, in which the developers pose an interesting usability conundrum:
While I normally push for semantics over style, I’ve always found elements like this to be tricky. Strong and em, for example, don’t really mean anything to most people, even though they have more semantic meaning than bold or italic. That said, I think ins and del would mean more to most users semantically speaking…
It’s worth noting that we do support strike, super and sub. We just don’t report them by default. Also, while you make valid points, the reality is that we must always consider the concerns of our users over those of authors. If users find that it causes excessive verbosity, that is reason enough for this not to be a default…
Having emphasis reported by default has been extremely unpopular with users and resulted in a lot of complaints about NVDA 2015.4. The unfortunate reality is that emphasis is very much over-used in the wild. I had serious misgivings that this would be the result when we implemented this and it seems these unfortunately turned out to be quite warranted. As such, we’ve now disabled this by default, though the option is still there for those that want it.
So, should we stop using text-level semantics? Well, <strong>no</strong>. They continue to add meaning to sighted users, and as Watters says, some AT users can benefit from them. But don’t over-use them. Like adding title attributes to all your links, there’s such a thing as too much accessibility.
A (usually) weekly round-up of interesting links I’ve tweeted. Sponsored by Smashing Magazine who slip banknotes into my underwear so I can spend time reading stuff.
Free live transcripts – website listens to you and transcribes in real time. Uses Chrome-only experimental Web Speech Recognition API. Did pretty well on my Brit accent.
A Very Informal Look at Gutenberg Accessibility – “my clients…asked to switch…Drupal …to WordPress because of WP’s UI advantages. …updates to the upcoming WP 5.0 release, specifically the new Gutenberg editor, appears to be undoing these advantages.”
CSS Grid Posters – “An exploration into the world of possibilities with CSS grid.
modalzmodalzmodalz – “We use too many damn modals”, with lots of suggestions for better UX patterns
Building a video editor on the web. Part 0. – “I am going to start the long process of working out what is and isn’t available on the platform and seeing how far we can get today” by Paul Kinlan
MeasureOSS – a “contributor relationship management system”, to help you see how engaged contributors are in your public project on GitHub, by @sil et al
Google unshackles Android-device firms – Manufacturers are not required to ship Chrome and Search if they pre-install YouTube, Maps etc. Good for ecosystem. Thanks, EU! I really hope Mozilla can do some OEM deal to get Firefox pre-installed on some Android devices rather than Chrome. We really need more browser diversity.
A (usually) weekly round-up of interesting links I’ve tweeted. Sponsored by Smashing Magazine who slip banknotes into my underwear so I can spend time reading stuff.
Link o’ the Week: Inclusive Design 24 – YouTube videos of free 24-hour online event about inclusive design for the global community. Thank you to all organisers, hosts and sponsors for this fabulous service.
Context, Culture And Service Design – Marc Fonteijn interviews Diego Mazo about the need for deeply understanding local culture in service design. (30 min YouTube video).
Pornography, Rape, and the Internet (PDF) – “the arrival of the internet was associated with a reduction in rape”, especially in men aged 15-19. So why is the UK government censoring porn, when evidence suggests that will lead to more sexual assaults?
Now, before people start to think “but colour isn’t content, it’s presentation!”, Sara was talking of pages showing colour swatches. In this case, the colours are the content. It seems like a good candidate for a semantic element, because it has meaning.
In my capacity as Ancient Old Fogey Of The Web, I sat and thought about this.
HTML: The mis-spent youth
The first iteration of HTML was a small set of tags noted down by in an email from Sir Uncle Timbo in October 1991, and added to in November 1992. By the time HTML2 came around, some tags had changed names, and a few tags added that showed HTML’s primary use as a language for mathematics and computer geeks: <var>, <samp>, <code>, <pre>, <kbd> as well as the now-defunct <xmp>, <dir> and <listing>.
At this point, we only had three presentational elements: <tt>, <b> and <i> (and arguably, <i> isn’t presentational—the spec says “If a specific rendering is necessary — for example, when referring to a specific text attribute as in “The italic parts are mandatory” — a typographic element can be used to ensure that the intended typography is used where possible.”)
Further generations of HTML reflected the changing uses of the Web; it was no longer the read/write medium that Sir Uncle Timbo had envisaged, so we needed a way of sending information back to sites – thus, a whole form-related markup evolved, which subsequently has served eCommerce brilliantly. Tables were added to show data, extending the web’s original use-case of showing and sharing mathematical papers. This had the side-effect of allowing creative people to (mis)-use tables to make great-looking sites, which meant ever more consumer-friendly sites (and a menagerie of presentational markup which is deprecated now we have CSS).
By the time HTML5 came around, we added a whole slew of elements to demarcate landmarks in common web page designs – <nav>, <header>, <article>, <main> and the like, which has improved the experience for assistive technology users.
By my count, we now have 124 HTML elements, many of which are unknown to many web authors, or regularly confused with each other—for example, the difference between <article> and <section>. This suggests to me that the cognitive load of learning all these different elements is getting too much.
HTML: comfortable middle-age
There’s loads of stuff we don’t have elements for in HTML. For ages I wanted a <location> element for geo information and a <person> element (<person givenname="Bruce" familyname="Lawson" nickname="Awesome" honorific="Mr."> etc.)
But here are some of the main reasons why we probably won’t get these (or Sara’s <color> element):
The 80/20 rule
The Web exists to share all possible human knowledge. Thus, the list of possible things that we could have a semantic for is infinite. We’re already getting overload on learning or remembering our current list of elements, their semantics and their attributes. So we (hopefully) have a set of elements that express the most commonly-used semantics (ignoring historical artefacts which browsers must continue to support because we can’t break the web).
The more complex a markup language, the fewer people understand it, the less conformant the average article will be, so the less useful the Web’s semantics will be.
Testing
Browsers are sophisticated beasts. I’d wager it’s the most complex software running on your device right now. As someone who used to work for a browser vendor, I know there’s a lot of resistance to adding new elements to the language – it adds even more testing to be done and boosts the chances of regressions. As Mat Marquis wrote in his recent history of Responsive Images,
Most important of all, though, it meant we didn’t have to recreate all of the features of img on a brand-new element: because picture didn’t render anything in and of itself
What’s the use-case?
The most important question: if there were a <person>, <location> or <color> element, what would the browser do with it?
Matthew Thomas suggested that new elements need to have some form of User Interface to make them easier for authors to choose the right one:
One way of improving this situation would be to reduce the number of new elements — forget about <article> and <footer>, for example.
Another way would be to recommend more distinct default presentation for each of the elements — for example, default <article> to having a drop cap, default <sidebar> to floating right, default <header>, <footer>, and <navigation> to having a slightly darker background than their parent element, and default <header>…<li> and <footer>…</li> to inline presentation. This would make authors more likely to choose the appropriate element.
Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why.
So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?
The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?”. For instance, if you want to render pages to a small screen (a form of repurposing) then <nav> or <footer> tell you that those bits aren’t content, and can be folded away; but if you’re looking into legal issues digging inside <footer> with some heuristics won’t help much.
I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. <canvas>) or that provide semantics that help repurpose *for Web browsing uses*.
So what can we do?
Luckily, HTML already has a little-known element you can use to wrap data to make it machine readable: the <data> element:
The element can be used for several purposes.
When combined with microformats or microdata, the element serves to provide both a machine-readable value for the purposes of data processors, and a human-readable value for the purposes of rendering in a Web browser. In this case, the format to be used in the value attribute is determined by the microformats or microdata vocabulary in use.
You can add additional schema.org structured data elements to your pages to help Google understand the purpose and content of the page. Structured data can help Google properly classify your page in search results, and also make your page eligible for future search result features.
This is pretty vague (Google secret algorithms, etc) but I don’t believe it can hurt. What’s that you say? It adds dozens of extra bytes of markup to your page? Go and check your kilobytes of jQuery and React, and your hero images before you start to worry about the download overhead of nourishing semantics.
What about Custom Elements?
Custom elephants are Coming Soon™ in Edge, behind a flag in Gecko and already in Blink. These allow you to make your own new tags, which must contain a hyphen – e.g., <lovely-bruce>. However, they’re primarily a way of composing and sharing discrete lumps of functionality (“Components”) and don’t add any semantics.
Conclusion
So that’s why we don’t include lots of new semantics into HTML (but feel free to propose some if there’s a real use case). However, you can do a lot using existing semantics, generic containers like <data> and extensibility hooks. Happy marking-up!
