Writing Meaningful HTML Semantics
There are several semantic specifications available to HTML. Each of them creates meaning for a different purpose or scenario.
Semantic Specifications
We’ll look at each semantic spec and describe the value each provides.
HTML5 elements
With the release of HTML5, we got several new DOM elements aimed at supporting semantic structure, such as header, footer, nav and article. Read more about HTML5 elements in the addendum.
WAI-ARIA
WAI-ARIA is a 3rd-party specification. It is designed to work within native HTML code to be used to further specify meaning, DOM structure, and navigation to assistive technologies such as screen readers.
The WAI-ARIA spec defined several tags which define and describe content, particularly for assistive technologies. For example, where HTML5 would use <div id="content"> or <article id="main"> to describe the primary page content, WAI-ARIA supplies a tag attribute as <element role="main">.
Value
Bringing finer grain of semantic structure to assistive technologies enables them to do their jobs better. Assistive technologies see the WAI-ARIA code and respond by performing more predictably, more logically, and by following the content as defined by the content creator.
It may sound silly, but a semantic HTML DOM often isn’t enough to supply a great content consumption experience. Read more about WAI-ARIA in the addendum.
Microformats
Microformats are a 3rd party set of specifications which describe objects and their attributes, such as people, books, contact information, addresses and organizations. Though their adoption is not yet thorough, the modern set of platforms which adhere to and recognize the Microformats specification add a great deal of value to its users.
For example, a person’s profile may have their first and last name, mobile and home phone numbers, mailing and office address, and email address. A Microformat version of this would enable a supporting technology to create a contact entry containing all of that data, properly entered, with the click of a button.
Example of a properly micro-formatted person:
<div class="h-card"> <img class="u-photo" alt="photo of Mitchell" src="https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"/> <a class="p-name u-url" href="http://blog.lizardwrangler.com/" >Mitchell Baker</a> (<a class="u-url" href="https://twitter.com/MitchellBaker" >@MitchellBaker</a>) <span class="p-org">Mozilla Foundation</span> <p class="p-note"> Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities. </p> <span class="p-category">Strategy</span> <span class="p-category">Leadership</span> </div>Some platforms have made attempts to replicate this type of functionality, which brings us to “Auto-semantics”.
Auto-semantics
(e.g. highlighted phone numbers on iOS Mail)
(What I call) Auto-semantics are a specific platform’s attempt to extract meaning from items whose meaning is otherwise unspecified. For example, if you open an email on iOS Mail, by default the phone number in the sender’s signature will be highlighted. At this point, iOS enables the user to tap it and choose from a variety of options, such as dial the number or create a new contact entry with the number.
Auto-semantics technically qualify as an assistive technology because they are doing something to help the user. As such, we need to be aware of their existence and effects uno our applications. Read more about auto-semantics in the addendum.
CSS and ACSS
The CSS3 spec brought us a couple semantically-focused attributes, such as speak and voice, and of course aural. Simply put, some should arguably be ignored because they’re not fully-baked, while others are nothing short of a miracle for screen- reader users. Read more about CSS in the addendum.
Example of these new CSS3 attributes:
speak: auto | none | normal; div { voice-family: male; richness: 80; cue-before: url("beep.au") }ACSS — Aural Cascading Style Sheets
The theme of separating presentation from content lives on in ACSS; basically CSS for ‘styling’ the voices of screen-readers. While widespread support is still lacking, there are some high-level attributes of this spec that remain useful for curating your presentation. Before we cover those, let’s cover how ACSS should be used today.
Use it Sparingly
Like you should with any CSS, writing ACSS should be written to the lowest level of compliance possible. Why is that? Because just like visual CSS, Aural CSS can quickly create a jarring user experience. For example, if your application is for kids, you might be tempted to set the pitch: to x-high; in an attempt to emulate a kid’s voice, but since many visually-impaired or screen-reader users tend to speed up their reading rate over time, you’d end up serving them a page that sounds like Alvin and The Chipmunks.
Smart ACSS Use
Joe Burns has some great examples of valid use-cases for ACSS in his article covering the feature set.
In one of his examples, you might have a page in question/answer format. In a case like this, alternating voices between female and male would likely aid in comprehension.
.question { voice-family: male; } .answer { voice-family: female; }In addition, it may be helpful to emulate a classical question/answer forum setup by placing the question voice “behind” (as if in the back row of a forum), and placing the answer voice up front — emulating a person on-stage.
.question { voice-family: male; azimuth: behind; } .answer { voice-family: female; azimuth: 0deg; }I would caution against setting any application-wide ACSS attributes because users of screen readers tend to get very accustomed to the ‘voice’ they’ve tailored to their preferences over time. The best user experience will be to take advantage of that unique comfort level, and only make augmentations when it will benefit them.
Open Graph
Open Graph is a protocol pioneered and maintained by Facebook. It consists of a set of <meta> tags designed to describe the content of a web page for the sole purpose of richly representing that content elsewhere… with the prime example being sharing—particularly when sharing to a social network. Read more about Open Graph in the addendum.
An example of Open Graph tags:
<meta property="og:title" content="About Our Company"/> <meta property="og:type" content="article"/> <meta property="og:url" content="http://www.mysite.com/article/"/> <meta property="og:image" content="http://www.mysite.com/articleimage.jpg"/> <meta property="og:site_name" content="My Company Name"/> <meta property="fb:app_id" content="1234567890987654321"/> <meta property="og:description" content="A description of our services and company profile."/>Addendum
Semantics are what enable us to create meaning from our content.
Why meaningful semantics?
It’s not 1995 anymore; CSS is here and we have the opportunity to separate presentation from content. (While that’s nearly impossible to do completely, the benefits of attempting to do so remain valid. It’s not dead.)
Every web browsing device needs accessibility
Nowadays, you can’t even purchase a web browsing device without inheriting it’s built-in accessibility features — they’re pervasive in developed countries. And even in fringe cases like people in developing countries using old Symbian phones with monotone displays; they also, almost especially benefit from semantic markup because their devices are ‘dumb’ enough to take full advantage of a semantically-coded site’s lightweight, logical markup.
What’s the downside?
Put bluntly, there is no significant downside. There are only benefits. Even from a development point of view, sure — it’s a bit more work — but it’s time spent integrating approved specifications that are barely changing as quickly as the HTML spec itself. Technologically, most of these specifications have reached a point where they’re fully-baked. They’re not going anywhere, and the demand for their implementation is only growing.
What’s the upside?
The benefits to the user are truly staggering. When determining our cost/benefit analysis of implementing these semantics with our own web applications, it shocked me that at least 20% of our users should be using assistive web technology. Only about 3% actually are. This is where the argument for semantics gets strong.
We’ve seen time and time again that specs like WAI-ARIA are not useless to a person with perfect cognitive and physical abilities; their web browser still takes advantage of these semantic codes in some way. Other technologies like Open Graph and Microformats have obvious benefits to everyone. In a word, it’s not just about accessibility for the disabled. Everyone benefits.
HTML5 Semantic markup
While some question whether these new HTML5 tags should have become a part of the HTML spec (as opposed to WAI-ARIA, for example), there is no doubt that they have quickly become widely adopted and thereby improved the opportunity of creating meaningful semantics.
Before HTML5 was released, the WAI-ARIA spec arguably already contained all of the necessary items to supply these types of descriptions; we already had aria-role="header", aria-role="menu" and so on. Personally, I love having the HTML5 elements because it relies less upon WAI-ARIA and – let’s face it – us front-end web developers are spending far more time refining HTML than our WAI-ARIA implementations. If nothing else, the addition of these semantic tags is a clear and practical benefit to a given front end web developer.
Let’s talk about WAI-ARIA
This is a great example of where the rub lies; WAI-ARIA is a specific, scoped set of attributes designed to work with any HTML. But since HTML5 supplied <article>, which do we use? In practice, it’s easier to use <article>, but HTML is nowhere near the ability to describe content to assistive technologies to the degree of WAI-ARIA. So what should we do?
In my opinion, we should do both. For example: <article role="main">. Here’s why.
The HTML spec isn’t going away anytime soon. As responsible front-end digital technologists and web developers, we should be aware of specification updates and adopt them. Like WAI-ARIA, HTML is good at a few specific things (and getting better at others), but even the addition of these new, semantic HTML5 tags like <article>, HTML will never be a replacement for it, because that’s never been what it was meant to do. But wait, there’s more.
Am I saying that HTML should forget about growing toward more semantic markup? No way! In an ideal world, HTML will eventually supersede the need for WAI-ARIA. Crazy right? I know. But here’s how I see it: HTML was designed to be a code set which would supply a web browser with a semantic framework by which a page could be rendered. Check. Ship it squirrel. Now what? If HTML was really about technical semantics in the first place, why would that logic not then make the jump from supporting the web browser to supporting its user?
Sure — where do you draw the line? The last thing we want is HTML6 to have an additional 500 DOM level tags like <secondarynavtitlesubdescription>, but would I like to have <navtitle> and <navdescription>, nested under a <secondary> tag? You bet! It makes sense to take these new HTML semantic tags further. The catch is, we’re not there yet. So we back-pedal to the next best way to richly support assistive technology, which is WAI-ARIA.
When I have this conversation with developer friends I often get the maintenance question: so you’re saying that we should code WAI-ARIA with the full knowledge that, one day, we’ll have to rewrite all of it? Yes, because churn. It’s not 1998 anymore. Code is cheap, and it’s easy to do it right. People don’t pay a few million dollars for a high end website anymore (that money now goes to brain-power). Instead, they grab the latest HTML5 Boilerplate build or use Squarespace or a WordPress theme. Is it good enough? Not always, but it can be, and some of them are already. Code naturally churns at a far more rapid rate than the HTML spec. Build for now.
Let’s talk about auto-semantics
The problem with Auto-semantics is that they’re often half-baked (and the code they’re parsing is too). This, like with Microformats, often creates a disjointed experience in practical use. (This is why the Microformats standard is so important — it represents the opportunity for structured data to be used efficiently by other applications.) Back to our iOS Mail example, if you use this function to create a new contact from the highlighted phone number, it usually won’t also grab the mailing address just beneath it, or mark the phone number’s label to match the “mobile: ” prefix in the signature. In short, the tech is still dumb.
Let’s talk about CSS3 semantics
If you thought the new HTML5 elements were controversial, check out some of the latest CSS3 specification, which includes accessibility-focused items such as speak and clip. While many purists argue for the separation of content and style, these new CSS3 attributes enable us to supply all users with a better, more focused experience of using a presentation.
This is where the old argument for the separation of presentation and content starts to get fuzzy. For example, using CSS’s speak: none; often results in the same effect as using WAI-ARIA’s aria-hidden="true". So which one do we use? We run the risk of either over-specifying or diving into the muddy waters of coding to support specific technologies. It’s like we’re back in 1998 making sure our sites work in Internet Explorer.
It’s not a simple problem. Different technologies support different specifications and — however unfortunate — we need to draw the line somewhere for the sake of maintaining a streamlined development process. Here’s how I wade through this mud.
When it comes to the separation of presentation from content, there is no better example than the purposes of HTML and CSS. While HTML has some fully-baked ideas about semantics (like <article> and <nav>), CSS arguably does not. The fact that a couple new semantically-focused attributes were added to the CSS spec does not in any way qualify it to replace any competing methods or technologies (as things stand today). While this may change, this is the situation now. Does that mean we shouldn’t use speak: none;? In my opinion, yes. We should avoid it because, unlike HTML, there are no signs of the CSS spec evolving in a direction that might one day make it a valid replacement for WAI-ARIA. In a word, today it’s little more than cruft. If something shouldn’t be spoken aloud to a screen-reader, then it’s not valuable content and it should either be removed entirely or attributed to aria-hidden="true".
CSS has never been, and shows no signs of ever becoming a tool which will improve the user’s experience by way of semantics (unless that user is the developer maintaining it ;). It’s great at presentation, and it’s use should be limited to that.
Let’s talk about Open Graph
Adoption has been wildly successful, and the protocol “just works”. These days it’s immensely important that your public web pages and applications be as visible as possible to a world who searches Twitter for the latest news, and Facebook for extended learning.
But that’s just the theory of Open Graph. The reality is that — when Open Graph is used — shared content comes to life with contextual data. Author names, featured images, publication dates, copyright data… the list goes on. For the user, the experience is so much more rich with useful data and compelling content when they see your article linked on Facebook or Twitter. If it’s good for your users, it’s good for you too.
