News Web Standards

Semaphore: A 10k Apart entry powered by SVG, CSS, and JavaScript

A couple of months ago A List Apart announced the 10k Apart contest. The premise is simple:

Build a compelling web experience that can be delivered in 10kB and works without JavaScript.

Over the past year I’ve been exploring the edges of what is possible with SVG and this seemed a perfect challenge to really see how far this new graphics format is able to take us.

The result is Semaphore, a flag semaphore simulator you can control with your mouse, touch, or keyboard.

Side note: Go vote for Semaphore, and don’t forget to check out the many other excellent entries.

Now that it’s up, I urge you to check out the final product and the Github repo to see how it all fits together. Here’s the full breakdown:

What is this?

Semaphore is a simple web app providing a straight-forward method for generating flag semaphore symbols. A visitor triggers the semaphore figure using the on-screen keyboard with either touch, a mouse or other pointing device, by tabbing through the options, or via the letters and numbers on their keyboard. Using a screen reader the visitor will hear the arm positions read out based on a clock face.

The 10K Apart challenge stipulates you must build a functional and “compelling” web experience that transfers no more than 10kB to the browser during first load. I chose to take this challenge as literally as possible, creating a web app that only consists of the bare-bones necessary to make it work: a HTML file, a CSS file, and a JavaScript file, providing a complete experience at just shy of 10kB. There is no lazy loading or external elements, and the app is entirely self-contained meaning once it’s in the browser, the visitor can unplug the internet and still have the same experience as someone on a broadband connection.

How does it work?

Semaphore utilizes modern web technologies to provide a responsive, accessible, high-resolution experience in a tiny package. The flat semaphore figure is an SVG split into three components:

  • the body (loaded as the SVG loads)
  • the two arms (loaded as separate symbols)

When a letter is selected, the JavaScript applies a class to the left and right arms that in turn brings in CSS rules that position the arms using CSS transform: rotate();. In some cases the arms are simply rotated along the plane of the page (much like a clock face), in others they are also rotated in 3D space to allow the flag to “react” to gravity. To make the figure more lifelike, the transition property is used to create an animation. The end result is a graphic figure that appears to be alive. The effect is especially striking when typing on your keyboard.

NoJS Fallback

In the original submission, I had left out the JavaScript fallback. This has now been remedied. If the browser does not support JavaScript, an SVG mapping all the semaphore positions is presented in its place. The graphic also has a long description appended describing the flag positions in plain text for screen readers.


When I originally put this project together, I used a much simpler SVG without symbols and applied the transforms to IDs within the SVG. However, early testing showed CSS transforms are not honored when applied to elements or presentational attributes within an SVG in Internet Explorer 11 and Edge. To get around this problem, I split each of the arms into a symbol within the SVG and called them in separately. As individual elements in the DOM, they accept CSS transforms with no issues.

That settled, I ran into another browser hurdle: While the arms behaved as expected in Chrome, Edge, Safari, and Opera, they were literally all over the place in Firefox. This is because Firefox does not respect percentage values fortransform-origin. There was also the nontrivial issue of positioning the arms in the correct location relative to the body. There are several complex ways around this problem, but because I had already broken the arms out into separate symbols, the easiest workaround was to make each symbol containing an arm the size of the entire SVG. That way they could be absolutely positioned on top of one another, and the shoulder joints (transform-origin points) could be targeted with simplified CSS. Sometimes practical solutions are just way easier.

Flag semaphore? Really? Where did that idea come from?

I’m fascinated by how technology has changed the way we think about information. Only a couple of decades ago, information (and in particular the communication of information) was a highly valued commodity that required means, expertise, and access. Flag semaphore, and its siblings the semaphore line and Morse code, are maybe the most archetypal representations of this reality: time consuming, cumbersome, and requiring rote recall of complex symbols, they allowed letter-by-letter communication across sight-lines and beyond, forcing the communicators to be vigilant, accurate, and most importantly frugal in their communications. In sharp contrast to today’s plethora of always-on internet-enabled communication methods, with flag semaphore every message needed to be concise, accurate, and without ambiguity – properties our modern world is often in dire need of.

Web Standards

Removing White Space Below Image Elements, or Why Inline Elements Have Descenders

If you’ve ever tried wrapping an <img> tag in a container and applied a border or background color you will have come across the infamous “why the #$%@$% is there padding space below my image??????!!?” problem. And if you’ve done your due diligence and searched “remove white space below images” you’ve probably found the solution (or this article, which will provide the solution right now): Use CSS to set img as a block level element and the pesky white space below the image magically disappears. It could look something like this:

img {
  display: block;

 A Case of Descenders

Now that  you know the solution, let me explain why this is happening. Knowing the reason why will help you remember the solution and also help you understand that this isn’t a bug but a bit of an anachronism left over from a time long past.

Let’s take a quick detour to the world of typography:

Graphic displaying the relationship between ascenders and descenders

When you look at the text I’m writing here you’ll note that lower case letters come in three groups: a, c, e, m, n, o, r, s, u, v, w, x, z, æ, and ø, are uniform in height and contained between the baseline and the median (see graphic above). The other letters have either ascenders (b, d, f, h, k, l, t) or descenders (g, j, p, q, y). The ascender is the portion of the letter that pokes up above the median, the descender is the portion of the letter that dips below the baseline.

Illustration of the descender space created underneath an img element when displayed as default (inline)

What does this have to do with images? Simple: In HTML the <img> tag is an inline element. That means it’s treated as text. And when text is placed on a page, room is made for the descender. In other words, the white space you see below your image is caused by the browser assuming there might be a descender in the text directly before or after the image and therefore making room for it. The problem of white space appears because while images when first introduced were considered inline elements, today we use them mainly as block elements. As I said earlier, this is all due to an anachronism left over from a time long past.

So, to sum up: Images are inline elements that are assumed to have descenders. When you want them to appear as block level, define them as such and the descender magically disappears.

The End.

Web Standards WordPress

Title, Caption, Alt Text, and Description: Harnessing the Power of WordPress Image Metadata

Images play an important role in web publishing, and WordPress makes it easy to add images to your content in several different ways. What you probably didn’t know is that taking a few extra minutes to fill in the “Attachment Details” for your images can improve their communicative value, create better user experiences for your visitors, and bring more people to your site.

In this article I’ll explain what the Title, Caption, Alt Text, and Description fields are all about and why they matter more than you think.

Every Image has its own Attachment Post

Screen grab of the Attachment Details fields in WordPress
The Attachment Details fields show up any time you add an image to a post or page

Let’s start at the beginning: When you add an image to WordPress, whether it be as a Featured Image (previously “post thumbnail”), an image in a post or page, or as a header image, you are actually creating a new Attachment Post. Once the image is added you can edit its Attachment Post by clicking the Media button in WordPress admin. This gives you a list of all the attachment posts associated with uploaded media items on the site.

Depending on your current theme you may also be able to access the Attachment Post page for the image from the front end of your site, and this attachment page may display some of or all of the meta data associated with the image.

Images and Attachment Posts can carry a lot of metadata

When you add a new image to a post you are prompted to add so-called “Attachment Details”. These attachment details are probably the most ignored and underutilized features of WordPress and if you learn what they are and how to use them you’ll never ignore them again:


The title is the only attachment detail required by WordPress. Title defaults to the name of the file but should be changed to a descriptive title of the image. This is the title of the Attachment Post for the image and just like a regular post the title will define the pretty permalink for the attachment post. You can also use the Title to search for images in your media archive.

In previous incarnations of WordPress the Title field was mapped to the optional HTML title attribute. This resulted in the title of the image appearing as a tooltip any time a mouse hovered over it. In the current incarnation of WordPress the title attribute for the image itself and also the optional image link are added separately. To do so you have to add the image to the post, then reopen it by selecting it and clicking the pen icon in the top left hand corner, and toggle the Advanced Options section of the Image Details modal window. Here you find Image Title Attribute as well as Image CSS Class (of which I spoke in a previous article), Open link in a new tab, Link rel, and Link CSS Class.

Screenshot of the advanced image options fields in WordPress
The Advanced Options under Image Details allow you to add title attributes to your images.


The caption is the text traditionally displayed underneath the image though the exact placement will vary depending on your theme. The caption is not tied to the attachment post but to where you choose to place the image in a post. That means if you use the same image in several different posts or several different places within a post you can have individual captions for each.

In WordPress captions are added using the shortcode which wraps around the <img> and optional <a> tags. This is why you can’t move images with captions in the visual editor but have to do it from the code end. For the image above the entire embed code complete with caption shortcode looks like this:

[caption id="attachment_2896" align="aligncenter" width="700"]
  <a href="" target="_blank" rel="attachment wp-att-2896">
      class="wp-image-2896 size-large" 
      title="Learn more about the Advanced Options for WordPress images" 
      alt="Screenshot of the advanced image options fields in WordPress" 
  The Advanced Options under Image Details allow you to add title attributes to your images.

It is worth noting that WordPress image captions can contain HTML including links.

Alt Text

The alt attribute or “Alt text” is mandatory for images on the web but is often ignored because it seems unnecessary. This is unfortunate because the alt attribute is both important and powerful.

The alt attribute is the text that displays when an image does not display. The general rule of thumb when applying alt text to an image is to describe in text what the image is communicating.

There are specific rules that govern how the alt attribute should be used:

  • If the image has communicative content (either says something or is illustrating something that has relevance to the content on the page) the alt text should describe the content either by repeating the text in the image or describing its content.
  • If the image is wrapped in a link the alt text should describe the target of the link.
  • If the image is purely for decoration and has no communicative value the alt tag can be left blank (alt=””)

People often think that the alt text is for visitors with accessibility problems. That is true, but it’s just part of the story: The alt text is there to describe image content and relate it to your overall content. While most visitors don’t see the alt text, search engines do and they index the images based on them. And as we move into a world of wearable devices that don’t always show images the alt text will become more important than ever before.

Bottom line: Always describe your images in the alt text field unless they are purely for decoration.


The Description field is probably the best kept secret of images in WordPress. If you add text to the description field that text will be stored as post content for the attachment post. That means if someone lands on the attachment post page for the image they will see the long description (provided the current theme supports it). To see how this works try clicking on one of the images in this article. You’ll be taken to the attachment page for that image where you see the image title, the image itself, the caption, and the description as post content. The attachment page in the theme I’ve built for this site also provides meta data that shows what post the image is associated with, a link to the original image size, and even navigation links to other images within the same post.

Once you’ve added an image to a post and you want to change or add to the Description you have to open the editor for the image Attachment Post. You can do that by going to Media in admin and finding the image or by navigating to the image on the front-end of your site and clicking Edit Media in the WordPress Toolbar. Though the Description field does not have the Visual (WYSIWYG) editor you can treat it exactly as you would any other post or page. It takes HTML and allows you to format the content to make it look like a regular post.

The Power of Metadata

Combined these text fields are a powerful feature that can be used to create better and more communicative experiences to your visitors and also bring new visitors to  your site. To see how let me give you an example:

Let’s imagine for the moment you are a wedding photographer and you are publishing a photo essay about a recent wedding. In the main post you add some images with basic captions and you describe these images with alt text that also includes your company name, words like “wedding photographer”, and the city you work in. When the post is published Google will index this alt text and people searching for wedding photographers in your city are likely to find your images during an image search.

You also add a standard WordPress image gallery to your post, but instead of using a lightbox to make the images “pop” up in the browser you redirect each image thumbnail to the respective attachment page for that image. Then when you add the images in you write a story for each of the images in the Description field.

Now when the visitor clicks on one of the images in the gallery she is taken to the attachment page where she gets to see a larger version of the image along with the added description. And again this description is indexed by Google. That means you can add the names of subjects in the images, detailed descriptions of products, services, locations, or the subject matter, or provide stories to go with each individual image for a truly unique experience. More than a boring image gallery you can create a photo essay – an immersive experience.

Another example of a good way of using these features is to share slides from a presentation. By adding the slides as individual images, adding comprehensive descriptions of each slide in the Description field, and linking your gallery to the attachment page you can provide far more information about your slides to your audience and make that information searchable on the web.

Start Using Your Attachment Details Today!

Now you understand what the attachment details are and how WordPress uses images and their metadata. The next step is to start using these fields actively to provide your visitors with better user experiences and get your content indexed in more places. I wasn’t joking when I said these are the most ignored and underutilized of WordPress’ features, and that also means if you start using them actively and getting the most out of them you will be way ahead of the competition. So what are you waiting for? Go set up proper titles, captions, alt texts, and descriptions for your images and report back!

Web Standards

Web Accessibility as a Right – Should WCAG be Mandated by Law?

There is a reason why the drivers’ seat in a car is adjustable: Not every body is built the same, and to appeal to as wide an audience as possible auto makers know they need to make it possible to drive a car whether you are 1m 30cm or 2m 30cm. The adjustable car seat makes driving accessible for the majority of the adult population.

With this in mind, join me for a short experiment: If you’re on a computer open a separate tab in your browser, navigate to your favourite website and try to navigate through the site using just your keyboard. Chances are it will be a frustrating experience. This is the inaccessible web. And its retirement is long overdue, not just because accessibility is a rights issue but also because accessibility makes the sites we make … well … accessible.

Web Accessibility as Law

In 2013 the Norwegian government passed new regulations regarding the Universal Design of Information and Communication Technology (ICT) which mandates that all websites must meet a minimum accessibility standard of Web Content Accessibility Guidelines (WCAG) 2.0, level AA. The new law takes effect on July 1st 2014 for new web solutions and all existing / grandfathered web solutions must meet the same requirements by January 1st 2021.

The new regulation is an extension of the existing Anti-Discrimination and Accessibility Act which states, in part:

Universal Design means designing, or accommodating, the main solution with regards to physical conditions, so that the solution may be used by as many people as possible, regardless of disability.
§11, Norwegian Anti-Discrimination and Accessibility Act

The regulation targets all private and public organizations, institutions, and businesses who use ICT solutions as their main form of communication with the public regardless of who owns the solution. In other words even if you rent space or services from another business you are still responsible for meeting the requirement.

The “solutions” mentioned are divided into two groups:

  • Web Solutions (publicly accessible informational websites, websites targeted toward mobile devices, and ecommerce solutions)
  • “Automata” (ATMs and ticket vending machines).

And as with any law there are exceptions:

  • Social media including blogs, Facebook, and Twitter, used for personal purposes and in the private sphere
  • Custom accessibility solutions for individuals
  • ICT solutions in schools and educational institutions
  • Broadcast media including film and streaming broadcast solutions

This all boils down to a simple message: If you are a web designer or developer or you own a website or web solution in Norway the government is about to get all up in your business. And it is high time they do.

Lack of Access = Discrimination

The decision made by the lawmakers is clear (not a quote):

If you provide valuable or important information to the public and limit certain groups from accessing that information you are performing a discriminatory act.

It’s hard to argue against this. If you substitute “website” with “pedestrian crossing” or “mall” or “high-rise” or even “television” you’ll realize our society puts a lot of emphasis on accessibility in public, commercial, and private spaces: Pedestrian crossings have audio cues for the visually impaired, malls and high-rise buildings have elevators for those with limited mobility, and television broadcasters provide closed captioning for the hard of hearing. You also realize that these accessibility measures benefit everyone: The audio cues at a crosswalk are useful to a sighted person, everybody uses elevators, and closed captioning allows us to watch TV with the sound off.

In contrast the web is largely inaccessible. And even on sites where accessibility standards have been implemented they are usually an afterthought or extra add-on that provides a reduced experience for the end-user requiring this assistance.

I would argue the lack of accessibility on the web is discriminatory. The web has become an integral part of our information society and limiting access to certain groups is equivalent to a restaurant saying “Oh, you’re hard of hearing? Sorry, we only have the menu available in audio format”. Not only is it an unacceptable practice but its justifications – that accessibility is too hard or too expensive – are untrue.

It is high time we make web accessibility the baseline standard. And if we don’t the government should step in with legislation like they have done in other realms where accessibility is an issue.

Accessibility as a Standard

Like I said: Accessibility is not hard. Nor is it expensive. Accessibility is just different from the status quo. When websites and web solutions are built the accessibility aspect is rarely at the forefront and it is often pushed to the back of the long line of other more pressing requirements – from responsive web design to cross browser compatibility to SEO. This is both what makes accessibility hard and what makes it expensive:

As an afterthought building web solutions that meet accessibility standards requires rewriting the code. But if we design and build our solutions with accessibility in mind from the ground up there is neither much of an extra expense nor any pain and frustration. Accessibility is for the most part about proper standards-based markup,  proper use of attributes and tags, and designing for communication.

Reading the requirements of WCAG 2.0 not as an onerous list of unnecessary demands but rather as a blueprint for building a solid web solution will make our code better and our content more accessible.

Accessibility is not just about Disability

You may think that accessibility is about disability. That is no longer the case. Accessibility is about to become something every consumer of web resources cares about. As I write this Microsoft, Apple, and Google are fighting tooth and nail to be the first to launch a production model car with a computer dashboard wired to the web. Soon web users will start demanding that Siri, Cortana, and Google Now read the web back to them in the car, on the bus, or while jogging, and they’ll want to navigate the web by voice. And don’t get me started on Google Glass, Samsung Gear, and whatever wearable device Apple will roll out this year. The hands-free web is around the corner and one of the main things that is holding it back is the lack of accessibility the web is currently suffering from.

On the flip side this means those that focus on accessibility now will reap the benefits once the voice controlled revolution kicks in full force. Accessibility is about access for everyone, and accessibility will make your content easier to access for everyone.

Accessibility is also about creating informational experiences that make sense. Many of the accessibility requirements in WCAG are common sense web standards: Proper hierarchy markup through the use of headers, blockquotes, cite tags, and so on, using alt and title tags on images and links, clearly explaining the target and purpose of links, annotating images and videos, the list goes on. None of this is about accessibility for the disabled but rather accessibility for the user.

A note on WordPress and Accessibility

The inspiration for this article came from one of my students Hanne Brøter who asked how this new regulation will impact Norwegian WordPress users and developers.

I have good news for Hanne and the Norwegian WordPress community: WordPress is very much on the forefront where accessibility is concerned. The default themes that ship with WordPress, in particular Twenty Fourteen, are almost up to modern accessibility standards, and there is work being done to make the application fully accessible.

More importantly though making a WordPress site accessible is not hard, and most of it has to do with how you manage your content: Using proper content hierarchies through headings and markup, adding alt tags to images and title tags to links, properly annotating videos, adding cite tags to links, etc. And when it comes to building themes keeping up with accessibility just means following the guidelines and writing standards based HTML5. As I said before, make WCAG your baseline and it will be mostly smooth sailing. And when you butt up against apparent blockers like keyboard accessible drop-down menus know that there are solutions Superfish available to get you back on track.

Most importantly start thinking about accessibility as a value, not a hindrance. Having the right attitude is half the battle.

Accessibility for all

I applaud my homeland of Norway for its move to legislate accessibility and I have every hope that other countries follow suit. While I can’t imagine how this would be enforced in a reasonable manner on a global scale I also have no reservations about a government taking this drastic step and getting all up in our grills: The web design and development community has disregarded and ignored accessibility for too long. It is a shameful practice and it has no rational explanation. So when the community won’t self-regulate and get with the programme it is up to our elected governing bodies to do something about it.

In other words if you don’t want to have a bureaucrat knocking down your door because your markup sends visually impaired visitors on an endless goose chase for your content, stop treating that visually impaired visitor like a second grade citizen and make accessibility the baseline of your sites.


Yes, I know this website is not 100% accessible. What you are looking at is an alpha version of a new theme. My intention is for the theme itself to be fully accessible by the time it is released.

Thanks to the input from the WordPress theme review team this site and its theme Simone which you can get for free from the WordPress Theme Directory is 100% accessible.

CSS Web Standards WordPress WordPress Themes

Typograph – new WordPress Theme

I’ve closed the comments for this thread to consolidate all comments for the different versions of the Typograph theme in one place. Please leave all your comments at the Typograph page which can be found by clicking here.

I’ve been planning to launch a proper free WordPress theme for some time now but there have always been major projects in the way. This week I had some extra time so I sat down and developed the Typograph theme which is now available for anyone to use. For free.

The theme is as simple as possible with clear separation between the content and the sidebar, a calm gray and white design with popping red links, a tabbed sidebar box with navigation, search and other important elements and some other styling for increased readability and better navigation. It complies with the new WordPress standard elements like image captions and Gravatars and even has a customizable ad space directly under the first post on the front page. And last but not least, Typograph is fully XHTML and CSS standards compliant.

Download the Typograph theme from the WordPress Theme Directory here!

See a demo of the Typograph theme here

No images

Right before I began the design of this theme, Spyremag published an article about 5 ways to break your design habits, one of which was to design a site using no images. Seeing as I’ve become somewhat obsessed with CSS over the last year it seemed only appropriate to follow this advice and create a no-images theme. Not only would this be a bit of a challenge because I ususually use a lot of images to make my designs more vibrant, but it would also put my coding skills and my understsanding of WordPress themes to the test.

Styled from scratch

Over the last several months I’ve been refining and customizing a copy of the Sandbox WordPress theme to develop an ideal platform for quick and easy WordPress theme design. The plan is to create a “God Theme” if you will that has all the bells and whistles installed and ready to go so that new theme design is quick and efficient. To put the alpha version of this foundation theme to the test I used it to style Typograph from scratch.

Tabbed box navigation

When I created the new theme for Design is Philosophy I spent quite a bit of time developing and perfecting a JQuery and CSS based tabbed sidebar box that would contain navigation as well as other useful information for the visitor. For Typograph I further developed the tabbed box and isolated it in it’s own file to simplify customization for the user. It can also easily be deactivated by commenting out a single line of code in the sidebar.php template. The tabbed box contains navigation for pages and categories along with an about section, RSS link and search box by default. It takes standard WordPress tags and can be customized to include pretty much anything by editing the tabbedBox.php file found in the theme directory.

Download the Typograph theme from the WordPress Theme Directory here!

See a demo of the Typograph theme here

Web Standards

Smart Spam Really isn’t that smart

As you can see from the Akismet counter in my sidebar this blog generates an insane amount of spam (the count started in February 2008). For the most part it is the standard crap you always get but lately I’ve started spotting what could only be described as “Smart Spam” – comments clearly generated based on the contents of the pages within this site that almost seem legit. Almost, but not completely.

Case in point: During my daily spam filter read this one caught my eye because it was so bizarre:

make your site legal…

Avoid legal trouble, make your website compliant with the law. It will save you from serious problems. The best part…you can do it in under 60 minutes….

Now clearly my site is legal so the comment is somewhat misdirected. But what I find amusing is the actual wording because it shows how this particular spam bot works. Obviously it spidered my blog and found the word “compliant” somewhere (undoubtedly in an article about standards compliant code) and misinterpreted it to be a reference to the rule of law rather than the rule of the W3C. But the really amusing part is that if you just change a few key words the comment actually starts making sense for web designers:

make your site standards based

Avoid validation trouble, make your website compliant with web standards. It will save you from serious problems. The best part…you can do it in under 60 minutes….

Much better, no?