From online flight boarding passes to application forms, we all use PDF more than we probably realise. And with the Federal Government making all paper-based forms available electronically in PDF format as part of its Electronic Services Delivery strategy, PDF continues to be an essential part of our day-to-day lives, both at work and at home.

However, while we encounter PDF frequently, it doesn’t necessarily follow that it is the best method for us to use. In fact, it’s almost taken for granted that it’s just the way to do things – so we at UsabilityOne decided to investigate this further, and bring to light the real user benefits and limitations of interactive PDF forms.

You can check out our findings in our latest report, Incorporating the role of PDF in the Australian Government’s Electronic Services Delivery strategy.

Once you’ve checked out the report, make sure to tell us about your experience of using PDF by commenting here!

This week I came across an interesting article on accessibility by Gary Barber. In this article, Gary complains that behind a facade of interest in, and understanding of, web accessibility, organisations in Australia do not really care about making their websites accessible.

I surely agree with him. There are very few organisations that approach us for help with accessibility who are driven by a genuine desire to make their website accessible. In most cases, companies start worrying about accessibility only when they have to meet some legal requirements. The reason behind this is that organisations still do not realise the great benefits (e.g. financial return) of offering accessible websites (sadly, I remember talking about this 6 years ago and little has changed).

I also agree with Gary on the fact that we need a centralised library of accessibility solutions. Whenever I encounter an accessibility issue for the first time, I spend hours reading about different solutions implemented by various developers, trying to decide what would be the most effective one. The creation of a centralised library would make this process much easier.

There is, however, a statement in Gary’s article on which I disagree: “the WCAG checklists don’t work. (…) Checklists are just too open to management and insecure web team members abusing them and warping the real results.” Yes, in an ideal world we would be running accessibility testing with users who have a disability, rather than reviewing websites against checklists. Unfortunately, this is simply not feasible. Due to the variety of types of disabilities that can affect the users’ online experience, and the even larger amount of assistive technologies that people may utilise, a website must be tested with a huge number of users. Even so, it would not be possible to say with any certainty that a website is accessible to everybody. We have tested websites with a sample of people with highly varied disabilities before, and yet at the end of the project we could not be certain that we had covered every issue simply due to the fact that we were catering to such a wide, diverse range of issues. This is why guidelines (like WCAG) and checklists have been written. They are very useful and effective at identifying many common and serious accessibility issues so that they can be resolved. Sure, complying with WCAG does not guarantee that a website is 100% accessible either, but it is a very good starting point to efficiently address many common accessibility issues.