iPod Touch

I use my iPod Touch every day but not so often to listen to music or videos. Daily I check my Facebook account, email, RSS feed (from hotukdeals!) and surf the web. It’s faster and more accessible than waiting my laptop to boot up and with having a wireless connection at home and work, it’s also portable.

Me 2.0

Over the last few months I’ve really delved into the world of social networking and anything Web 2.0 in general. As I mentioned above I now have a Facebook account, I have umpteen RSS feeds that I read on my PC first thing every morning, which often lead me into hours of R&D and frequently new ideas for design/development work I’m currently involved with. I have a del.icio.us account, in fact I’ve two, one for development bookmarks, which is listed on this blog and one for web design stuff. I don’t know how I lived without these before as they are a fantastic way of managing your bookmarks and sharing with colleagues. I’ve set up a Flickr account and have uploaded many photos for sharing. Admittedly I’ve been a little disappointed with Flickr. It’s not as intuitive or user friendly as I’d expect and also I have to pay for it if I want to create several sets rather than bung all my photos into one. Hmm!

Not Biting

There are other social networks I’ve looked at and quickly dismissed. I don’t get Twitter at all and really don’t see the need to tell the world what I’m doing or where I’m at every day! There must be good applications for this tool but I’ve yet to see it. Digg just doesn’t float my boat, why would I want to waste my valuable time promoting something to world? What’s in it for me? Wikis are great and something I really want to implement in the NICS but finding practical uses and more importantly, content contributors are even bigger challenges.

What’s Next?

I now feel so 2008 and can’t help wondering what new fads will grab my imagination in 2009. Already with my iPod touch I’m newly fangled with interactive comics such as Bone, Shadowhawk and Atomic Robo while I patiently wait on the English version of Lucky Luke to be released.
Work wise I’ve eventually got a Flash video streaming service in place and will be launching a campaign site at the end of the month which will be the first to use it. High on my list of priorities are projects to replace our content management system, a corporate Intranet integrating with Sharepoint and the launch of a NI version of Directgov in March.

A busy year ahead awaits – yet again!

Before even looking at the application my first response is a simple one – provide an accessible alternative. That is give the user a phone number or address where they can receive appropriate assistance or better still, think about what the application’s main function is, can any of it be delivered in a static form? With a bit of work the answer is usually yes.

It’s impossible to make GIS data fully accessible. These applications are inherently visual and cannot be understood or even made usable to screen readers but that doesn’t mean to say the WCAG should go out the window.

Commonly the problems I see with new GIS based applications are:

• Invalid markup, likely to result in unpredictable behaviour in various browsers and therefore the dreaded “Best viewed with Internet Explorer…” message.
• Form labels not associated with inputs. I have no motor impairments yet find it frustrating when a lazy developer expects me to click on a tiny input box as opposed to the large label beside it.
• Fixed fonts. IE6 still has a large share of the browser market so we must cater for these users by using ems/keywords/percentages in font sizing.
• Reliance on colour alone. Colour is used to define regions or features on a map. If shades of one colour are used several times, unless you aren’t colour blind and have a top of the range monitor you won’t see the difference.

These issues are only covered by the WCAG but I’m a firm believer that accessibility should go further than the WCAG and common sense should prevail.

Non-WCAG issues I come across include:

• Poor error recovery. Not directly covered by any WCAG 1.0 checkpoint this is something developers constantly overlook. Users click on a form submit, perhaps not choosing options and nothing happens. At least thats how it appears unless you they notice the error message at the bottom of the page in that nice off white colour.
• Unintuitive GUIs. The developers know how to navigate the GIS, the clients do but does anyone else? That’s usually the first thing I spot, being removed from these projects, as I spend my first 20 minutes figuring out what I’m supposed to do.
• Non-standard forms. Every form on the web has it’s submit button to the side or at the end, right? Unfortunately not. Placing a submit button at the top of list of checkboxes is just dumb and goes completely against normal practice. You wouldn’t ask someone to complete a form then ask them to sign and date the top of it would you?

I could go on but would prefer to look at what can be done to improve GIS data. It appears that many of these systems are built on top of legacy applicatons and accessibility and usability is bolted on at the end. Like any well planned website project, accessibility and usability must be considered from the outset. I would like to challenge these application developers to start thinking outside of the box. For example, why must the system dictate what colour county borders are? Why can’t I as a user customise that feature and select my own colours. In fact why do I need to use the system in the first place? Why can’t I complete a simple form with my postcode, check the info I’m interested in and receive a nice colour map with supporting documentation?

Perhaps therein lies the answer (to some situations) in that the map is something a user turns on should they want it there and then but that the user can still get their answers without it. With Google leading the way in GIS and their intuitive GUI, it’ll be interesting to see what comes next.

In his entry Jack rightly raises the issue of the COI going with WCAG 1.0 as their standard. When browsers, assistive technologies and website content have all evolved dramatically since the WCAG was introduced in 1999, why are we still following these standards. Well in the absence of anything else and WCAG 2.0 taking forever, what else is there? I’d really hoped that in the last few years we’d see a website owner taken to court so that at least we could see for definite what the law’s minimum requirements would be rather than making assumptions.

I personally feel that the UK Government needs to step up to the mark here and by Government I mean civil servants. There’s a need to recognise the opportunity for not only meeting demands among developers who care but more importantly citizens who are suffering inaccessible and unusable websites.

As I’ve mentioned before in Northern Ireland we have an audit process which most, new central Government websites must go through. As a result we have a host of sites which by and large are usable and accessible, meeting at least WCAG 1.0, priority 1 checkpoints.

We have our own interpretation of the WCAG, most of which is available online but desperately requires updating. So why haven’t these been updated? Well quite simply resources and priorities. I don’t have the time to revise them and equally such an exercise is not high enough on my long list of things to do. The COI however, obviously have a lot more resources available for such work as their recent consultation document demonstrates but it did little to convince anyone that they are about to put a set of sensible, practical and robust guidelines in place.

Is this because they didn’t know what standard to aim for? Is it worth putting in weeks of work around a set of outdated standards? Or do you wait on WCAG 2.0 then go for the jugular? This is where I sit on the fence. As I mentioned above part of me thinks COI should step up to the mark and do it now. I would be confident that COI with the assistance of the PSWMG could put together a killer document, a reference guide that would even make the old fogeys responsible for WCAG 2.0 sit up and take notice. But would they be leaving themselves open to criticism and perhaps legal action in European courts if WCAG 2.0 is seen as an international legal standard.

All this uncertainty makes life all the more difficult if not demoralising for the developer in the street who just wants to do a good job and ensure the sites he builds don’t present barriers to users.

Constantly I’m asked about a range of issues to which I struggle to find a definitive answer for, should sites be fixed or fluid, is it ok to use PDFs, are images for text ok? For me the only real way we’ll ever be able to make a more definitive call is if substantial, concentrated user testing is carried out, on a wide range of people, with different platforms, ATs, environments etc. I find it hard to believe that no one has undertaken such a task but have yet to find results of any such level of testing.

Surely this is something central Government would welcome and fund? If not, are there other routes, for example charities? I for one am tired of sitting on the fence, I think it’s time we started lobbying for positive action.

Last week the Cabinet Office issued a “Public consultation on Delivering Inclusive Websites“, guidance to update Chapter 2.4 of the Guidelines for UK Government Websites. The Cabinet Office say the document “covers some of the design solutions to common problems faced by users but is mainly aimed at strategic managers and project managers to assist with planning and procurement”. But does it really?

Let’s look at the current guidelines for UK Government websites and Chapter 2.4 entitled “Building in universal accessibility + checklist“, originally published in May 2002. This chapter is basically a set of guidelines for web developers advising them on issues to be aware of and techniques they can use to satisfy standards. Admittedly now outdated it served a purpose and set standards that in the main were measureable and achievable.

Compare to the latest update and we see two very different beasts and here begins my rant!

The latest offering is 24 pages long yet it’s not until we reach page 16 where the first piece of advice to web developers is offered. At first glance at the document I thought haven’t I seen this before. So off I went digging through my pile of documents tucked away in my drawer until eventually I found PAS78. A few minutes later and yes, as I suspected there are many similarities between these documents. But why bother? PAS78 is great, it gives people an insight on what they need to be aware of and ask for when commissioning a website. So why reinvent the wheel? Leave PAS78 where it is, refer to it but don’t regurgitate the content. Chapter 2.4 has always focused on covering “design solutions to common problems faced by users”. Only this time it’s “some” design solutions to the point I wonder why even bother?

I could rant all day about this but will spare those who are kind enough to read my blog by giving a few examples!

Firstly what does the new guidance say about Images? “Ensure that all images have meaningful alt text.” That’s it. So I have decorative images on my page, am I supposed to give them alt text? Of course not. The current guidance rightly says “If an image is simply for decorative purposes (a horizontal line, a coloured spacer, a transparent spacer or material termed ‘screen furniture’ or ‘eye candy’) and is not essential to the understanding of the website, an empty alt=” ” should be used, also known as a ‘null alt’.” So by removing this guidance we’re now muddying the waters for developers without expert knowledge. Does this now mean when I audit a site and discover alt text such as “right nav go arrow” I ignore it and pat the developer on the back for giving the image alt text?

Example two. “The use of images of text… is undesirable”. Checking dictionary.com one translation of undesirable is “Not likely to please”. So what does this mean? Should or shouldn’t I? Who will I not please and if I don’t please them what are they going to do to me? Images for text is often a bone of contention on NI Government sites, we often have debates of when images should and shouldn’t be used and rarely agree or even totally convince ourselves. Here was an opportunity for the COI to help us out, give us definitive examples.

Lastly and the biggest gripe I have is the failure to include advice on a topic which has caused numerous arguments in my daily job – fixed v fluid layouts. One of my main responsibilities of my team is to peform pre go-live audits on all main NI Government sites. Up until about 18 months ago our stance on fluid layouts was mainly led by our corporate layout standards [PDF]. Any site required to follow these standards has to use a fluid layout. Ok but what about those who don’t? Well we recommend in our audits that they abandoned fixed for fluid. Then along came the eAccessibility of public sector services in the EU report [PDF] and this is where our stance changed.

Section 4.3 of this report, entitled “Common reasons for failure at Level Double-A” has a sub section “Table height/width absolute values CSS absolute values”. It supports the use of fluid layouts and goes on to say “With failure rates of 89% and 74% for the two items reported here, it is clear that such fluid coding of web pages is still not widely deployed.” So taking our line from this report we assumed the COI was saying that all public sector sites should use a fluid layout. So eagerly awaiting this guidance appearing in the revised Chapter 2.4 I was amazed to see no mentioned whatsoever of the fixed v fluid debate. Now where does that leave us?! Do we just ignore this Cabinet Office report. Why was it’s findings not the basis for revision of Chapter 2.4?

I’ve read in various places that some people feel this latest document has a checklist mentality. Personally I feel it’s the complete opposite. It gives a little nugget of advice but is in danger of encouraging developers to take huge strides backwards with it’s lack of definitive guidance.

I wonder just how many people are aware of the updated version of Chapter 2.4 which never seen the light of day? It was sent to my line manager a few years ago when we were asked for feedback. I was proud to have made a significant contribution which was accepted and published in revised drafts. The document gave some really great advice, stuff I haven’t seen elsewhere, at least not all in the once place. Who took the decision to scrap this document and instead churn out the bride of PAS78?

All comments and discussion welcome!