Stop Linking to Nowhere

Do you find yourself writing this kind of thing in your HTML?
<a href="#" onclick="doSomething()">Some action</a>

Does that href="#" make you feel slightly uncomfortable? Like it’s not really doing anything, a bit of a hack? You’d be dead right to think that.

Links are used like this all the time and there’s really no need. The intended purpose of links is to point to another location and provide navigation. That’s why the href is there. It’s pointing to another place but it’s often left pointing nowhere.

It’s probably worth pointing out that using href="#" doesn’t actually do nothing. It adds a # onto your current location, changing the URL, so when you then click the back button it appears to do nothing but is actually going back to the last location, the URL without the #. If you do use href="#" and an onclick event be sure to use event.preventDefault() with it to prevent this location change.

Links get used in this way mainly because we want the styling and the interactivity. Hovering a link gives visual cues – underline changes, cursor changes so it’s easy for a user to see it’s something they can interact with.

So, what’s the alternative? If you’re just performing an action, use a button. It has the visual cues. It doesn’t have any hacky href="#" nonsense. It can be styled however you wish if the default styling is too full-on. It can even be styled to look exactly like a link, though personally I think there’s value in differentiating between navigation and actions.

And there’s more… You get some more benefits for free with a button.

You have a disabled property. You can easily make your action unavailable. Not so easy with a link.

It’s more touch friendly. This depends on styling but out-of-the-box it’s a larger touch target.

It has an autofocus property so it can be in focus on page load without needing any JavaScript. Ready to go at the tap of the Enter key.

If you use links for navigation and buttons for actions you get every tool doing what it’s best at. You could cut your food with the side of your fork and raise it to your mouth on the side of your knife but why would you? This isn’t really so different.

Google Analytics – Why You Should Replace IDs in URLs

Google Analytics is brilliant at tracking things like Page Views for a website. It logs the URL and then keeps a count of how may times that URL is requested. Great, right? Not always.

There’s a problem. Dynamic sites that use IDs in their URLs generate a lot of different URLs. A typical example might be a site being made up of list and details screens, so the URL for a list screen might end in /List/. For a details page there’s probably one template with the data changing dynamically and the ID for that item is probably in the URL, something like /Details/123 or /Details?id=123.

This means that Google Analytics sees every visit to a different item’s details as a different screen. This is ideal for some data analysis, like seeing which item is viewed most but not so great when you want to look at something like the performance of that template. Having hundreds of different URLs makes it impossible to analyse the template as a single screen.

Good news. It’s quite easy to set up another view to show the aggregated data using filters.

  1. Go to the Admin area and create a new view.
  2. Find Filters and add a new filter.
  3. Add a Filter Name.
  4. Select a Filter Type of Custom.
  5. Use the Search and Replace option.
  6. Select a Filter Field of Request URI.
  7. The Search String needs to match the ID. You can use regex to match any patterns so if you know your ID is 3-5 digits long you can use [0-9]{3,5}. If it varies you could use a wildcard, like id=*.
  8. Add a Replace String. I use something to represent what’s being replaced, like ID. This gives me a URL like /Details/ID or /Details?id=ID. If you’ve used a wildcard in the Search String with part of the URL you can replace this too, like id=ID.

Here’s an example of replacing a GUID in the URL:

Google Analytics Filtering screenshotThe full regex needed is:


An added bonus. When you look at your reports in Google Analytics you’ll no longer see URLs like /Details/aace7226-0576-4a0f-9b39-bb549a53ee11 but just /Details/GUID. Much easier to understand, especially if your URL contains several IDs or GUIDs.

Hope this helps you analyse your screens, templates or UIs rather than just the data requested.

Experiment: Font Size vs Colour Contrast

One of the things I’ve learned early on in web accessibility is the importance of colour contrast to make things easy to read on screen. High contrast is good but the size of text is also a factor. If it’s larger it’s easier to read even if the contrast drops.

At the same time, having very large text with high contrast is quite “full on”. It can feel a bit like you’re being shouted at. Oppressive is the word I’d use.

This got me thinking. I wonder if we can scale colour contrast with font size so that it always feels good. It’s really an extension of responsive design.

So, I tried it in CodePen.

See the Pen Font Size vs Color Contrast by Chris Smith (@chris22smith) on CodePen.1248

I’ve just done some very crude maths to make the RGB colour proportional to the font-size. As the font gets larger so do the RGB values, and vice versa.

I’m sure there’s probably some beautiful golden formula for getting the optimum contrast at every size but I wouldn’t really know how to go about finding these optimum settings. This experiment seems to prove that the general idea is sound though.

Please feel free to play around with it, take it further and let me know how you get on.

Making Icons Accessible

I’ve been using the excellent Font Awesome for a few years and it’s become part of almost every new design that I do. For a long time I’ve just slapped my icon down on the page, styled it and added a click event where needed. Job done.

Having spent some time looking a bit more deeply into accessibility, I can now see that this is not a great approach. There’s more to consider. If you can’t see it what is it actually doing?

Here’s how I approach using icons now. It may not be the perfect solution but it’s certainly a lot closer than most use cases I see. The way I use HTML depends on the use case.

If the icon is purely decorative – there in addition to text, e.g. a floppy disk icon next to the word “Save” on a button, then I think we can reasonably just forget about it and hide it for non screen users. A simple aria-hidden=”true” attribute should do.

<button><i class="fa fa-save" aria-hidden="true"></i> Save</button>

If it is there as an indicator, in place of a label, like where a hotel might have icons for TV, bath, etc. then we can use an <span> to wrap it. Inside the span we add our icon and another span with a text alternative. We show the icon and hide the inner span for screens, show the text only for other media.

Finally, if the icon is interactive and acts like a link or button, let’s make it a link or button. Like the previous example, use the <button> or <a> tag to wrap the icon and a span text alternative and show/hide for the appropriate media. This has the added bonus of making it possible to tab to the icon and so use just the keyboard to navigate the page. It also handles the icon’s active state and visited in the case of a link.

Alternatively, if you didn’t want to add a span with text inside your button or link, you could use the aria-label attribute to provide a text alternative.

One little tip. If you use an icon inside a link or button, do not leave whitespace between the outer wrapper element and the inner icon as you may get unwanted effects in the styling, such as underlined spaces either side of your icon. Keep it tight.

A New Found Appreciation for Images on the Web

I’ve been putting images in web pages for years. Nearly 2 decades now. For most of that time it has been quite easy. Add your source and the dimensions and BOOM, there you go. There was always some work around optimising images outside of your page but once in there, easy.

Then, with higher pixel densities it started getting a bit harder and we had to work it out with media queries and srcset. Now SVG is widely supported, all this fussing around with different versions for different resolutions has gone away, at least for simple graphics.

I’ve recently been doing some design work on an Android app and it’s a very different way of doing things with images. For example, I’ve created a splash screen for while the app is loading. It’s a full page, wide logo in the centre, coloured background.

On the web, I’d just set the background colour and then centre the SVG logo, probably with flexbox, and use a flex-basis of 80% or some margin to give it a flexible width.

On Android, I’ve had to provide the splash screen image as a series of PNG files. 5 different resolutions, varying from 480×320 up to 1920×1280, and then in both orientations, 10 files in all. The clever part is that at the point of installing the app the Android device will only get the files appropriate for its size and pixel density but it means a lot of messing around with assets.

It’s been a similar story for icons too. Multiple resolutions. You want a different colour? That’s a separate PNG.

I’m making it sound worse than it actually is. Luckily there are great tools that let you import a single image and export all the variations you could need.

But it does make you think about the differences between platforms. To me, the web browser, with it’s ability to resize on the fly, use SVG, recolour, apply filters, transform and animate in CSS makes Android image support feel very primitive.