Archives

Home » Blog

Tracking When Users Print Pages

Originally posted on my blog on March 26, 2013.

A few months ago I had the pleasure of writing a piece for .net Magazine about print styles (Make your website printable with CSS). It was posted to .net’s web site last month and received an overwhelming one comment. That comment, however, summed up something I hear all the time:

Would be interesting to see some statistics on how many people actually print websites.

For years I have argued that the best user statistics are those for the site you are building. In the absence of global numbers for how many users print web pages, in this post I’m going to show you how you can measure how many (and which) pages get printed from your site by using Google Analytics. I am also hoping those who know everything about Analytics can answer some of my questions.

The Concept

While looking around for existing solutions to track printed pages, I found this article: Use Google Analytics to Track When People Print your Web Pages (written exactly one year before I got my own code working). While there doesn’t appear to be anything wrong with this approach (I did not try it), how it both produces the tracking code (JavaScript) and presents the data in Analytics (different than how I report on custom events), doesn’t match my preferred approach.

I want to be able to call the Google Analytics tracking image (__utm.gif) only when the page is going to be printed, skipping unnecessary HTTP calls and the resulting image download (brief though it is). I rely on the CSS @media print declaration to call the image. I also don’t want to write that image call to the page with yet more client-side script when I can assemble it all right on the server.

Since my post Calling QR in Print CSS Only When Needed already outlines the general flow (presuming I only want to support Internet Explorer 8 and greater), I can lean on the CSS syntax there.

To reiterate this technique will not work in versions of Internet Explorer 7 and earlier.

Constructing the Query String

I had a heck of a time finding information on how the Analytics query string needs to be constructed, and when I did find information it didn’t always explain the values in much detail.

Google’s developer site has information on all the query string parameters for the GIF request, but no information on what is required or what all the possible values might be. I did find a list of what may be the required parameters while searching among a thread on tracking emails with Analytics. Through a good deal of experimentation I came up with the following minimum list for my purpose:

Variable Description
utmac Account String. Appears on all requests. This is your UA-#######-# ID.
utmwv Tracking code version. While my standard GA requests use 5.4.0, I opted to use 4.3 for reasons I no longer recall.
utmn Unique ID generated for each GIF request to prevent caching of the GIF image. I just concatenate the current year, month, day, hour, minute and second.
utmhn Host Name of your site, which is a URL-encoded string.
utmr Referral, complete URL. In this case I just insert a dash so it is not blank.
utmp Page request of the current page.
utmt Indicates the type of request, which is one of: event, transaction, item, or a custom variable. If you leave it blank, it defaults to page. Because I am tracking events, I use event.
utme Extensible parameter. This is where you write your event. I use 5(Print*{page address}). See below for why.
utmcc Cookie values. This request parameter sends all the cookies requested from the page. It can get pretty long. It must be URL encoded. It must include __utma and __utmz values.

Because the whole point of this is exercise is to track the event in Google Analytics, it was important to understand how to construct the event for the query string. I struggled a bit.

I still haven’t figured out what the number 5 maps to, but it works. I also found that I need an asterisk as a separator, though I found no documentation explaining it. In the end, the only way a print event tracked as I wanted was when I constructed it as: 5(Print*/Accessibility). In this example, /Accessibility is the address of the page I am tracking.

The other tricky bit is pulling the cookie value and stuffing it into the string. Conveniently I can get to this within our content management system (QuantumCMS, which you should use) on the server side. Many others (if not most or all) have a similar ability. At the very least you have to include the __utma and __utmz values, passed as encoded parameters for utmcc. Without these, my tracking would not fire.

The Completed Query String

For ease of reading, I will break the string to a new line at each &. This represents what is generated when I visit the careers page on the Algonquin Studios site using Opera.

http://www.google-analytics.com/__utm.gif
?utmac=UA-1464893-3
&utmwv=4.3
&utmn=2013326124551
&utmhn=algonquinstudios.com
&utmr=-
&utmp=/Engage/Careers
&utmt=event
&utme=5%28Print*/Engage/Careers%29
&utmcc=__utma%3D267504222.1477743002.1364314722.1364314722.1364314722.1%3B%2B__utmb%3D267504222.17.7.1364314901604%3B%2B__utmz%3D267504222.1364314722.1.1.utmcsr%3D%28direct%29|utmccn%3D%28direct%29|utmcmd%3D%28none%29

Constructing the CSS

Now that you have the query string and the Google Analytics tracking image, you just need to call the image when the page is printed. All you need to do is embed a style block at the top of your page with the print media query, and call the image within it:

@media print {
 header::after
  { content: url(http://www.google-analytics.com/__utm.gif?utmac=UA-1464893-3&utmwv=4.3&utmn=2013326124551&utmhn=algonquinstudios.com&utmr=-&utmp=/Engage/Careers&utmt=event&utme=5%28Print*/Engage/Careers%29&utmcc=__utma%3D267504222.1477743002.1364314722.1364314722.1364314722.1%3B%2B__utmb%3D267504222.17.7.1364314901604%3B%2B__utmz%3D267504222.1364314722.1.1.utmcsr%3D%28direct%29|utmccn%3D%28direct%29|utmcmd%3D%28none%29); }

If you read my post on embedding QR codes, then this code will be familiar — I use header::before in that example. As such, I use header::after here so you can use them both keyed off the same element (header) without conflict.

If you look closely, you may have noticed that my event parameter looks like 5%28Print*/Engage/Careers%29 instead of 5(Print*/Accessibility). I URL encoded the parentheses on the entire string to make certain that they do not conflict with the parentheses in the CSS. If you don’t do that, the browser will get confused and fail to load the image.

Once you have the CSS in place, I recommend going into HTTP Fox or the Chrome Developer Tools to make sure the image is called when you fire a print preview (save paper!), and then to make sure it has the parameters you expect — particularly the utme value:

Screen shot of Chrome Dev Tools.
Screen shot of Chrome Dev Tools showing the query string parameters for the tracking GIF.

Checking Your Google Analytics Report

Assuming you’ve verified all is working well, you just need to run a report for events in Google Analytics. Bear in mind that Analytics isn’t up-to-the-minute, so you may need to give it some time to capture all the data.

Log into your Analytics account and make sure you set the report date to the time period where you rolled out these changes. Choose “Content” from the “Standard Reports” on the left side. From there, expand “Events” and then select “Top Events.” You should see “Print” as one of the items in the “Event Category” column (you may need to show more rows).

Screen capture from Google Analytics
After you click “Top Events,” you will see all of the events you are tracking (if any other).

Click on the word “Print” in that grid and you will see all the pages that were tracked (ostensibly because you or a user printed the page).

Screen capture from Google Analytics
The report is handy if you know the page addresses, but Analytics doesn’t think of them as such. As a result, clicking the addresses will not take you to the page.

From here you can run a secondary dimension to cross-reference this with more information. In my example, I tested different pages in different browsers so I could quickly verify the cross-browser support. You can run screen resolution, landing page, or any other dimension that you think might be handy to compare.

Screen capture from Google Analytics
An example comparing the printed pages with the browser as a secondary dimension of the report.

Conclusion

I am just adding this to my own site, so I don’t have any numbers to offer as part of this post. However, if you implement this please feel free to let me (and everyone) know how many users you have who print and for what site. I don’t expect the numbers to be high, but I do expect to see it happen here and there.

If you have any additions, corrections or suggestions, please let me know. I am still unclear how all the Google Analytics query string parameters come together and exactly what they all mean, so there may be some optimizations I can work into it.

Related

Related articles on print styles:

Stuff I’ve Written

Chrome: Blink and You Missed the News

This post originally appeared on my blog on April 4, 2013.

The new Blink logo.
It’s old news by this Thursday morning, but in case you had not heard, Google is forking WebKit to make its own rendering engine, Blink. Opera will be using the Blink fork of WebKit as its rendering engine.

A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn’t offer my opinion, however.

I will format this the way I did when I provided my in-depth analysis of Opera’s move to WebKit (away from Presto) less than two months ago.

So what does this really mean?

For Developers

Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.

Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.

If you aren’t sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post “WebKit Will and Won’t Be the New IE,” where I provide a high-level overview of these variances.

For Users

At this point it doesn’t mean a whole lot.

Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won’t be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to “WebKit Will and Won’t Be the New IE” for how poor testing can impact users, but that’s not a function of the engines.

Because Apple only allows WebKit on iOS devices, and even then it restricts those browsers to a different JavaScript engine and thus a lesser experience, Chrome and Opera for iOS may still stay on WebKit. Over time as its harder to incorporate features from Blink back into the WebKit core, there may be feature divergence which may affect users.

That’s just speculation on my part.

For Standards

For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.

With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto’s wind-down (to be fair to Presto, it’s expected to exist in the wild until 2020, but with no new feature development).

I am hoping that this is a good thing for standards.

Blink won’t be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.

Technical Aside

From Peter-Paul Koch:

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Related

First some bits from The Twitters:

And now to the related links:

There’s this one from 2010 by Haavard Moen that I thought worth highlighting: “Dear Google: Please fork WebKit.”

Update, 5:35pm

A video Q&A from Google Developers about Blink (time markers available on the Chromium blog).

Calling QR in Print CSS Only When Needed

This post originally appeared on my blog on March 8, 2013.


For those of us who put together print styles for our sites, we’ve probably tossed around the idea of embedding QR codes so that users can quickly get back to a page they have printed. In the hardcopy version of my article for .net Magazine, “Make your website printable with CSS,” I show how you can embed QR codes in your page (it’s not included in the online version).

In my example I use the Google Charts API to generate the QR code on the fly. The problem in my example is that the QR code image gets called whether or not you print the page. Not only is this an additional HTTP request, it’s also an additional download that immediately gets hidden. This puts a bandwidth burden on users who aren’t printing, but it’s also the only way to support your users on Internet Explorer 8 and below (who may be the ones trapped at the office who want to bring the document home).

If you truly have no IE8 or below users, then the less bandwidth-hoggy approach is rather simple, if a bit inelegant.

Since each call to the Google Charts API to get the QR code must include the full address of the page, I cannot leave this to my linked CSS file (which is static, not run through any server-side processing), nor would I want to push every URL for every page of my site into that file. Initially I wanted to use a data- attribute to hold the URL and then, using the generated content feature of CSS, have it take that value and feed it into the content: CSS declaration to have it generate the image from there. Except that’s not how CSS works. You cannot use CSS to generate an image from a CSS variable.

The easiest solution is to a put a style block at the top of your page (something I hate doing) and feed the current page’s URL into the Google Chart API query string to dynamically draw the image. The rest of the styles that affect placement, spacing, etc. should all be in your print stylesheet already. The example:

@media print {
  header::before
    { content: url(http://chart.apis.google.com/chart?chs=120x120&cht=qr&chl=http%3A%2F%2Falgonquinstudios.com/Engage/Careers); }
}

That’s it. Now when (and only when) you call the print styles, the image will load. As proof, here is a screen shot using HTTPFox showing the page before the print styles were called and after, where you can clearly see the QR code is called only when the print styles are fired.


Screen shots of the list of HTTP requests before and after the print styles were fired. You can click / tap to see the full-size image.

Screen shot of the print preview with the generated QR code in place.

Note: This technique will not work in any version of Internet Explorer that doesn’t support CSS generated content, which includes IE 8 and below. Internet Explorer 9 and above happily include the QR code generated with this method.

Letting Mobile Users See Desktop View of RWD Site

Originally posted on my blog on January 11, 2013.

Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?

There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.

Clearly it’s enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the “desktop” version of a site from a menu built into the browser.

Except that feature doesn’t work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn’t do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.

Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we’re kind of stuck. While I have many ideas on how that might work, that won’t address the issue today.

While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.

There are some core steps the hammer out in the logic of any solution:

  1. Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.
  2. In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.
  3. Either using a round-trip to the server or client-side script, remove the media query logic and serve up the “desktop” CSS.
  4. Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.
  5. Now display a link to view the “mobile” version of the site. Again, this can be done with or without script.
  6. If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.

This process is a bit oversimplified, but it covers the broad strokes.

There are some hurdles, of course. Your users might not understand what you mean by “desktop” or even “mobile.” You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don’t clear the link from the page for them. And so on.

You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.

These screen shots should give you an idea of what to expect when you visit the site:

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7, all styling determined by media queries.
CHSBuffalo_iPhone_desktop CHSBuffalo_Nexus7_desktop

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7 after clicking “View desktop layout” (with the zoom as the user would initially see it). The link to return to the mobile layout is at the top, though not as obvious as it could be.
CHSBuffalo_iPhone_desktop_oops

This is what the user on an iPhone sees as soon as the desktop view loads—note the link to return to the mobile view is nowhere to be found. We did a poor job there and will have to fix it. Don’t make the same mistake if you try this.

Related

Page-Level Container Discussion for HTML5

This post originally appeared on my blog.

HTML5 logo — I am the 'alt,' not the 'title' As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains “a website or a blog entry’s main content” is
body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of “main” or “content.” In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it’s already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn’t We Get a Content Element?

The flip side of this argument is that we’re just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn’t restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of “main” and “content” that already exist in the wild when naming this element.

Where it goes from here is anybody’s guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn’t expect to see a new element by then.

Related

Designing With User Technologies In Mind

When building, redesigning, or maintaining a web site or web application, it’s important to understand the technology visitors will use to access the site to create the best user experience possible.

So what do you need to consider? Although there can be many factors at play, here are the key questions you should answer:

  1. What browsers are used to view the site?
  2. What devices are used to access the site?
  3. What screen resolutions are commonly used by site visitors?

Browsers

Most of us web developers have a tendency to get pretty excited about using new coding techniques and technologies like CSS3 and HTML5, but it’s important for us to consider what browsers the site visitors will be using so we can determine whether those techniques are appropriate or not.

If you find that your user base primarily views the site in recent browsers, then you may have more flexibility with new technologies. However, if you find that a significant portion of users are accessing the site in older browsers, you’ll need to make sure that they can complete all functions without any major drawbacks.

That doesn’t mean that the site has to look identical in all browsers however. Many web developers commonly employ a technique called progressive enhancement. This coding technique allows for users in recent browsers to see the site design as intended (with enhanced design elements) without negatively impacting the experience of users in older browsers in a significant way. Enhancements might include design elements like rounded corners, gradients, or drop shadows.

There are many desktop browsers that support progressive enhancement techniques including Google Chrome, Firefox, Safari, Internet Explorer 9, and Opera. Internet Explorer 8 and lower usually do not get the benefits of such enhancements.

Most mobile browsers tend to have good support for progressive enhancement techniques as well, including the default Android browser, Safari, Google Chrome, Amazon Silk, Opera Mobile/Mini, and many others.

Devices

Understanding what devices your visitors are using will help you engage with them more effectively. There are many devices that allow people to hit the web in addition to computers, including tablets, phones, and gaming consoles. Most computer users access the web in a similar way, with a keyboard and mouse, but don’t forget that there are some users who rely on screen readers to recite the content of the page to them and who navigate by keyboard only.

Tablets and phones are “tap” devices, meaning that users interact with web sites using their fingers. For these devices, it’s typically helpful to create larger tap radii for links and to avoid displaying critical content on mouseover or via right-click.

Because there are many different ways to access a web site, it’s important to design and develop with accessibility in mind. You should always aim to make your site accessible for your target audience and their expected browsing devices, but not at the expense of impaired users.

Screen Resolution

With users accessing the web on phones, tablets, PCs, laptops, TVs, and a seemingly endless number of devices that come in all shapes and sizes, there is, likewise, a seemingly endless number of screen resolutions that you must consider while developing a site.

PCs and laptops tend to have resolutions equal to or greater than 1024 x 768 pixels, although you may still see a few users running at 800 x 600 pixels. 1024, though possibly the lowest desktop resolution that you’ll need to really consider, is still rather popular and has held a significant portion of the market share for many years. You should, in most cases, consider that to be your base and confirm that your site is usable at those dimensions.

Phones, tablets, and netbooks bear further consideration. If your user base includes a number of mobile users, you may be able to improve usability significantly by applying a different layout or styles optimized for smaller sized screens. CSS3, widely supported by recent mobile browsers, offers an elegant solution of applying different styles at different browser sizes and is often the preferred approach.

Bringing It All Together

Understanding how users experience your site or application will allow you to serve them better and, ultimately, improve overall customer satisfaction. The easiest way to gather data on browsers, devices, and screen resolutions is via Google Analytics, which offers reports for all three. I highly recommend that you review these reports to get a better understanding of your users, especially if you are considering a redesign for your current web site and to close it out, here are some nifty screen shots of those reports:

Browsers:

Devices:

Screen Resolution:

My Print Styles Article in .net Magazine

The Summer 2012 (#231) issue of .net Magazine has my tutorial on making print styles for your site. Not only did I get four pages, the article got a mention on the front cover (small though it is) and my photo in the contributors section.

If you’ve spent much time here or following me on Twitter, then you know I have written plenty about the lack of print styles on modern sites, particularly those claiming to use responsive techniques. I figured it was about time I showed some techniques to make it happen and hopefully demonstrate how dreadfully simple print styles are to do.

While my article is clearly the stand-out piece in the magazine, and totally worth getting just for my work, there is some other stuff in this issue that might interest you:

Creating flexible layouts that will work on any device and any screen size is the next big challenge for CSS. In this month’s issue Peter Gasston takes us on a tour of some well-implemented properties you can use now as well as the exciting proposed properties we could be using in the future.

There’s also a guide to creating or updating your online portfolio from Gary Marshall, an interview with Elliot Jay Stocks and tutorials on HTML5′s Drag and Drop API and building a basic responsive site with CSS. Here are some more highlights:

  • Build smoother JavaScript apps
  • Make your website printable
  • Make your sites load faster
  • The pro’s guide to Adobe Edge
  • Build an ecommerce store
  • Using PHP Data Objects

By the way, in case you want to read up on some of my prior discussions about print styles, here’s a handy list of links for you:

Accessibility Bookmarklets and Tools

This post originally appeared on my blog.

Testing accessibility on your web projects can be a tricky task if you have no firsthand experience with visual, audible, physical or even cognitive impairment. Having resources in the community is important as is tracking down the same tools in use in that community.

Despite all this it’s nice to have some quick techniques for testing your sites without the need to break from your regular workflow. Conveniently, there are a number of tools already out there. Here is a quick rundown…

WCAG 2.0 parsing error bookmarklet

From Steve Faulkner, this experimental bookmarklet uses string matching to evaluate a page against the WCAG 2.0 success criterion for section 4.1.1 Parsing. It leans on the W3C Nu Markup Validator to do its job.

Get the WCAG 2.0 parsing error bookmarklet from The Paciello Group for yourself and while there, read up on how to use it.

Nu Markup Validation Service Bookmarklets

Excuses for failing to use the W3C Nu Markup Validator fall away when all you have to do to validate a page is click on a bookmarklet. Also from Steve Faulkner, this collection of four bookmarklets allows you to validate the current page (in the current window or a new one) or provide the URL of a page to validate (in a new window or not).

Get the four Nu Markup Validation Service bookmarklets (also from The Paciello Group).

Favelets for Checking Web Accessibility

Jim Thatcher has come up with a series of bookmarklets (or as he calls them, favelets) that allow him to make the human review process easier by highlighting details he might otherwise have to wade through code to see. Bookmarklets include image checkers, heading counters, data table notes, ARIA details, and form features.

Get the full collection of “favelets” for checking web accessibility and be sure to read the detailed instructions on how to use these in conjunction with a manual testing process.

Web Accessibility Toolbar

This particular tool is not a collection of bookmarklets. It is also not built to work for any browser other than Internet Explorer. It does, however, provide far more features than bookmarklets can do on their own. Used in conjunction with a manual test and the bookmarklets listed above it can help our overall accessibility testing process far more than just the bookmarklets alone.

Download the Web Accessibility Toolbar For IE and give it a test run on your sites.

If for some reason you are running Opera 8 or Opera 9, there is a version of the Web Accessibility Toolbar for Opera (but again, only 8 or 9).

Juicy Studio Accessibility Toolbar

This toolbar is a Firefox add-on from Gez Lemon. Like the toolbar above, it provides a bit more control than a bookmarklet will afford. This will show you ARIA live regions, show you ARIA landmarks and roles, provides a table inspector and a color contrast analyzer.

You can get the Juicy Studio Accessibility Toolbar from the Mozilla add-on site.

NonVisual Desktop Access (NVDA)

Since I’ve strayed far afield of bookmarklets I thought I would toss this last one into the mix. NonVisual Desktop Access (NVDA) is a free, open-source screen reader for Windows. While it’s intended for the entire OS, it’s also great for testing web pages. Its support of different accents makes for much fun when it speaks to me as a Scotsman.

Download a copy of NVDA for yourself and make sure to donate when you do — this is how projects like this are able to continue and how you can support the disabled community.

Somewhat Related on My Blog

Dining in the Dark

This post originally appeared on my blog on Wednesday, April 25, 2012.


A blindfolded photo attempt of my meal, served and eaten in near darkness. Thankfully it turns out that my aim with my fork was better than my aim with my cellphone camera.

Two weeks ago our longtime client Olmsted Center for Sight (formerly the lengthily-named Elizabeth Pierce Olmsted, M.D. Center for the Visually Impaired) held a benefit dinner titled “Dining in the Dark.” The concept was quite simple and given away by its name — attendees would enjoy a meal in total darkness. Not only did my company co-sponsor the event, I attended it and had the pleasure of dining with Olmsted’s president.

The meal started off with wine and salad, which you were allowed to eat in light. Then we were presented with bibs and blindfolds, and the lighting was turned down to just the candles on the table (the servers needed to see, after all). And so in darkness we set upon the main course followed by the dessert course and wrapped up with coffee service. During the main course an Olmsted representative guided us through techniques to get the lay of the land, identify foods, cut meat, find drinks and so on. I ignored all this and dove in with my characteristic nonchalance about my meal and found myself stymied by the simplest things — it takes a couple tries to realize your knife is upside down and that you are cutting with the blunt edge and not the sharp edge.

I have spent over a decade working with Olmsted Center for Sight. I have had the opportunity to see how its clientele/constituency uses computers and surfs the web. I have attended seminars, spoken at events, been a part of lawmaking discussions, implemented software and web sites, all in my time consulting with Olmsted. I have been working with low-vision and blind users for most of my professional career, but nearly always in the form of technology. Though I had some time running concerts for thousands of attendees and making sure outdoor and non-standard venues were handicapped accessible, this dinner afforded the chance for me to experience some of the day-to-day tasks that I take for granted, but this time without sight.

This post may seem to be a little outside of my generally technical discussions here, but I believe that experiences like this are important for anybody who cares about inclusive design or accessibility. Some day everyone reading this will have reduced vision, mobility, hearing, and so on. Learning now how to design and build to support those changes serves to position future generations of developers to design and build to support the future you. That’s just a good investment in your long term well-being.

Consider spending an hour blindfolded and try to do a mundane task like get dressed, eat a meal, or even use the web to look up a menu on a web site (you’ve already seen me rant about how awful that experience is for average users). Consider limiting your movement, restricting yourself to a chair, putting in earplugs, and so on. You may find your get far more insight into daily life as well as software and web development than you expected.

If you’re still reading and also care about accessibility, then in keeping with the low vision theme of this post here are some resources to use when developing sites for the blind. This is not an exhaustive list by any means, but there are links to many others within.

This handy video shows you how blind people use the iPhone 4S. It’s worth a couple minutes of your time.

This link isn’t a resource, instead it’s a story of a police department using its forensic techniques to help save 26 pages of hand-written content after the blind writer’s pen ran out of ink.

Updating My Web Site? Yeah, I’ve Been Meaning To Get To That…

I’ve been wondering – how many people out there would remember to check the batteries in their smoke detectors if it weren’t for daylight savings time?

Every six months, I spend a minute or two on a Saturday night trying to remember if I gain  or lose an hour that weekend. Shortly after figuring out if I’m jumping ahead or falling back this time around, I inevitably hear my dad’s voice in the back of my head saying, “Every time you change the clocks, make sure you also remember to change your smoke detector batteries.”  Day-to-day family life is pretty crazy for me these days, so I’m not 100% certain I would remember to change those batteries if my dad hadn’t hammered it into my head for years. And I’m glad I remember, because my family and my house are pretty important to me!

While I’m willing to bet most people would agree with the idea that if you run a business of any kind these days, you need a web site. But the time frame for how often you need to update (or outright change) your web site is probably far less agreed upon than say, how often you need to change the batteries in your smoke detectors. Most people might argue you should mix things up every two to three years, but I’ll bet there are some who would say you can go longer.

At the risk of sounding like my mother, technology is hard to keep up with. What’s new and fresh today will be old news in a short period of time. The truth is, if your web site is more than two years old and you are not planning to update it, or the technology it rests on, you’re probably behind the times (and your competition). For example, if your site doesn’t automatically adjust when it’s viewed on a cell phone or tablet, what are you waiting for? Your site won’t develop a mobile-friendly version of itself. How about an even more basic question – are you still sending content changes and updates to your web vendor or “tech guy” instead of using a quality CMS in-house? Well, guess what? You’re essentially hoping the smell of smoke will get you out of bed late at night, because you’ve neglected your smoke detector maintenance.

Regardless of how long you think you can go without paying it some attention, the sales call to see if you are ready to update your web site should be viewed like daylight savings.  It’s a subtle reminder, me calling to say “Hey, Busy Person! Don’t forget about this important part of your business.” When you get the call, even if you aren’t ready to deal with it then and there, ask me to call you back on a specific date in the future (sooner, rather than later) and put that call on your schedule now. It will help you make sure that your site update doesn’t get put off longer than it should.

Hmm. Maybe I should change my phone sales pitch. “Hi, this is Tom from Algonquin Studios. Have you changed the batteries in your smoke alarms and when would you like to begin updating your company’s web site?”