Chris Ashton – Senior Developer

Category: Accessibility

  • When do I need a non-JavaScript solution?

    The short answer to “when do I need a non-JavaScript solution”? Always. The long answer? Keep on reading…

    When I test a new feature built by another developer in my team, one of the first things I do is to turn off JavaScript and see what happens.

    Developers often act surprised at this, and look at me disdainfully for inevitably breaking their application when I choose to access it in this way. “This is a client-side calculator! Of course it’s going to break without JavaScript!”

    Similarly, when I sit in on meetings with developers and stakeholders discussing what they are hoping to build, “fallback images” and non-JavaScript solutions are often treated as a bit of an afterthought. When I put forward the question of fallbacks, it doesn’t surprise me when the answer is a smirk and a “well, I suppose we’d better give IE8 something“.

    We’ve all become so used to modern browsers and increasingly powerful mobile devices that the concept of a non-JavaScript solution seems an unnecessary extra effort; an additional burden on designer and developer alike. After all, the actual proportion of users who access the website without JavaScript enabled is never more than a couple of percent.

    However, ignoring fallbacks due to the low percentage of users most affected is short-sighted and is missing the point.

    We’re all non-JavaScript users

    You may have looked at the proportion of users who access your website with JavaScript turned off through no fault of their own (e.g. corporate users of IE8) or deliberately (self-aware tech-savvies who are sick of being tracked with cookies) or who don’t even have JavaScript available in the first place (anyone using increasingly popular proxy browsers for reduced data consumption). The combined total of these users might be a tiny proportion of your overall users. Heck, it might even be zero.

    This is no excuse for ignoring your non-JavaScript implementation. Why? To paraphrase somebody on Twitter:

    “Every user is a non-JavaScript user until the JavaScript loads.”

    We’re not all on fiberoptic broadband connections. If you’re on a mobile phone on the train and you’re about to enter a tunnel, you’ll be stuck with whatever content arrives in the few kilobytes you managed to download before the signal cut out. Which would you rather see: a sea of whitespace and badly formatted text accompanied by nothing but the prospect of a seven-minute data vacuum, or the core article text with some basic but sufficient styling?

    Varying degrees of non-JavaScript solutions

    Non-interactive features (such as datapics) have no interactive element and thus should get the core content, untainted by “Turn your JavaScript on!” messages. The content of the feature should be accessible and readable without jumping through hoops. Perhaps it’s not possible for the content to look quite as polished as the JavaScript version (though if we’re disciplined about using CSS for presentation and JavaScript only for interaction, this should not be the case).

    Some features, such as quizzes, require client-side interaction to be of any real benefit to the reader. Is a non-JavaScript solution necessary, or even viable?

    When it comes to content where advanced functionality is the core content, I still expect a few things for non-JavaScript browsers:

    • Though I’m not expecting anything particularly exciting or useful, I would expect the page to not look broken.
    • I’d expect a message something to the effect of “You must turn on JavaScript in order to view this content.”
    • And I wouldn’t expect lots of unnecessary markup containing questions I can’t answer and buttons I can’t click.

    To paraphrase another anonymous tweet:

    Use JavaScript to inject the markup your interactive application requires.

    So, the answer to “when do I need a non-JavaScript solution?” is… always.

    Other benefits of providing a non-JavaScript solution

    A better experience for corporate users of IE8 and for mobile users in temporary data blackspots aren’t the only advantages of implementing a defaults-first solution. Reasonable core-content experiences provide benefits in a number of other situations:

    • Reasonable experience if another script on the page breaks your JavaScript.
      • Bugs can and do creep into live pages. Maybe the ID of the element your script hooks into has been changed, or another script on the page is re-defining jQuery at runtime, or you’ve accidentally deleted a JavaScript dependency from the server. Instead of the page spewing a load of JSON or unused markup to the user, the user will be presented with a simpler version of the same content.
    • Accessibility for screen readers
      • Canvas-based interactives are not usable by screen readers. If they get a description of the fish game that they could be playing in a more modern browser, disabled users at least get an understanding of what content is on the page.
    • Search engine optimisation
      • Canvas-based interactives are not crawlable by search-engine spiders. However, a simple description of the canvas content will give search engines an idea of what content exists on the page.
    • Support for harsh browser environments and future compatibility
      • Who knows what lies ahead technologically? We may one day browse the web on our toasters, pub urinals, coffee cups and Boris Bikes. We have no way of knowing what level of sophistication such browsers would support. By providing core content to all, we’re future-proofing our content as much as possible.
    • Clearer separation of concerns – content, presentation, interaction
      • It’s well known that HTML is for content, CSS is for presentation and JavaScript is for interaction. Keeping the three areas separate is good architecture, and supports a defaults-first development style. By delivering our non-JavaScript solution through our markup and CSS alone, we’re fitting into this programming ideal.
      • Clearer separation of concerns means more maintainable code, meaning fewer bugs, bugs which are fixed more easily, the improved ability to work in parallel with other developers (e.g. one on presentation, one on interaction), and so on.
      • Cohesive codebases and fewer bugs means hitting deadlines, and if you’re lucky, bonuses and pay rises. As developers, we’ll have gained a stronger handle on the advantages of keeping each area separate (the Single Responsibility Principle), and will strive for similar ideals in the rest of our codebase, leading to better use of object orientation and the like.
    • Last but not least, making websites accessible is the law. Don’t risk being sued for having an inaccessible website. Part and parcel of this is ensuring that every solution has a non-JavaScript default.

    Continue reading: Coding defaults, not fallbacks (coming soon)

  • How to differentiate between links

    When you visit a new website and are about to click on a hyperlink, do you know what is about to happen?

    In the early days of the internet, a link was just a link. You’d click it and be taken to a new page.

    Nowadays, clicking on a link can trigger any number of different behaviours. It may, as before, be an ordinary link that takes you to a new page. It may, however, open the link in a new tab or window. It may even trigger an event on the same page, such as an alert, or open up a floating box full of text (this is a common design pattern for displaying ‘Terms of Service’).

    Personally, my sites open links in the same page by default, only opening in new windows if the link is to a different domain. You might disagree with me and think along the same lines as Vitaly Friedman – that you should never force links to open in new windows – but the point of this blog post is not to discuss the merits and disadvantages of each approach. Gotta leave me something to write about in the future!

    No, this post is about tackling a design problem that has been worsening since the turn of the millennium.

    The problem for website users

    When you click this link, what do you expect to happen? You might be able to gather some clues by hovering over the link and hoping for some information to appear. But you can’t do that on touch-screen devices. And even if you could, the information can be missing, masked, or downright misleading.

    This looks like a link to a review site: Food Review Site

    In fact, it triggers an event on the current page.

    We could make things more explicit by writing our links like this:

    Google (opens in a new window)

    But this is a long-winded, ugly way of indicating the link type. We need something more concise. Something immediately recognisable without the need to concentrate.

    Ideally, we want to follow a consistent standard so that a user who has never even been on your site before will be able to accurately predict the browser behaviour when clicking on a link on your page.

    The de facto standard

    Increasingly, websites are adding a small icon next to links that open in new tabs. Here is a screenshot of Wikipedia’s implementation:

    New window icon - Aberystwyth University page on Wikipedia

    Though these icons vary slightly from site to site, the principle is the same – a small icon that indicates the link’s behaviour.

    The problem for developers

    So, we have a solution to the problem. What’s the issue?

    The issue is that it is a pain to implement. Namely, it’s a pain to remember to do- and to actually implement- the manual addition of an image next to each of your applicable links. It may be quicker and more maintainable to add a class to your links, e.g. “.opens_in_new_window”, which you can style from within your CSS – but that doesn’t relieve the burden much.

    If only there were a way for links to be targeted automatically…

    The solution

    a[target=_blank] {
    background: url('data:image/gif;base64,R0lGODlhCwALAJEAAP///5mZmf///wAAACH5BAUUAAIALAAAAAALAAsAAAIdlIOJJgEPA3MKKGdRfjRtu3UcFGFXRVpTqh6nZBQAOw==') no-repeat center right;
    padding-right: 15px;
}

    This is a simple snippet of CSS that applies a ‘new window’ icon to all of your links that open in a new window. That’s it.

    The url is a base-64 encoded image, which saves the browser from making an additional HTTP request for the image. If you don’t like the one I’ve used, you can encode your own icon at http://www.base64-image.de/ (and this is a nifty example of it working!)

    Advanced attribute selectors (a[target=_blank]) work in IE7 and above, and base 64 encoded images work in IE8 and above, so there is substantial cross-browser support and backwards compatibility.

    Let me try it!

    Try copying the following into a file on your computer, save it as index.html, open up in your browser. You’ll see two links – the first opens on the same page, so has no icon, whereas the second opens in a new tab, so has the icon.

    <html>
    <head>
        <title>New Window Icon</title>
        <style>
        a[target=_blank] {
            background: url('data:image/gif;base64,R0lGODlhCwALAJEAAP///5mZmf///wAAACH5BAUUAAIALAAAAAALAAsAAAIdlIOJJgEPA3MKKGdRfjRtu3UcFGFXRVpTqh6nZBQAOw==') no-repeat center right;
            padding-right: 15px;
        }
        </style>
    </head>
    <body>
        <h1>New Window Icon</h1>
        <p>
            <a href="#">Internal link</a>
        </p>
        <p>
            <a href="#" target="_blank">External link</a>
        </p>
    </body>
</html>

    That’s an important design problem solved in just 4 lines of CSS – and one of those is a curly bracket!