It is vital that the Government's live web sites are as accessible as possible for everyone. There can be no argument about that - their audience is everyone.
With a short, agile, project like Alpha.gov.uk (we've had just over 10 weeks build-time with the full team in place) it's all about setting direction, sketching out the product - even if all the bits don't get coloured in - and about trying to make the right compromises.
So, when it came to accessibility we set out to build the best product we could for everyone, or rather, to start sketching out what it could be. We have iterated and experimented, and used the sort of built-in good-practice (clean URLs, valid HTML with design separated from content, build with syndication to other platforms in mind) that have been the mainstay of commercial web development for several years now.
But we opted against full accessibility compliance from initial launch of the project. The reasoning? That there's no point being 'Triple A' accessibility certified if the underlying product is poor (as is often the case).
Accessibility should start with research and consideration, not with box-ticking or sprinkling a few standard accessibility features - especially in a government context where a user journey regularly extends into the real world (Booking a driving test? You'll probably want to know the facilities at the test-centre).
Making a half-hearted gesture towards accessibility (such as including text resizing or contrast options) or adding a badge to say we were certified, could have implied that we considered that box ticked, when we knew it to be untrue.
One example: we have a feature that lets people set their location by entering a postcode. This lets us do things like send them to the correct local council to pay their council tax with less faff, or display the correct bank-holidays for their part of the UK.
Currently that feature only works fully when javascript is enabled in your web browser. Obviously that is something you would never do in a full live version (or even a beta version) of a website. But by reducing the development overhead it allowed us to really nail the interaction design, something we are continuing to improve.
Was this the right approach? It has certainly allowed us to iterate faster and remain focused on making the product better as a whole. But we are very much open to opinions to the contrary.
For the duration of the project we will be actively seeking feedback and examples of how we can fix real world accessibility issues and identify and fix the mistakes we have inevitably made. We want to hear from as many people as possible.
Hopefully Alpha.gov.uk can be an example of the research and consideration needed to do accessibility right in the government context and help make future government sites more accessible for everyone.
Photo credit: Paul Downey
Richard Pope was Product Owner on the Alpha.gov.uk prototype. You should follow @richardjpope on Twitter
24 comments
Comment by David Gibb posted on
I am very interested in providing online services for disabled people through an improved Directgov site. Many users of Jobcentre Plus's Access to Work programme (which provides funding for additional costs faced by employed disabled people) want to be able to find out more about the support they, personally, could get and apply for support online. While the numbers of disabled people are relatively low when compared to the numbers of benefit claimants I do think you should give them a greater weighting when assessing where and how to apply development resources to achieve the greatest improvement in citizen’s interactions with government.
Comment by Ian Hamilton posted on
"For the duration of the project we will be actively seeking feedback and examples of how we can fix real world accessibility issues and identify and fix the mistakes we have inevitably made. We want to hear from as many people as possible.
Hopefully Alpha.gov.uk can be an example of the research and consideration needed to do accessibility right in the government context and help make future government sites more accessible for everyone."
It can't, for it to be a good example it should have involved testing with disabled users before alpha stage, and that testing to have informed design decisions from the ground up. Soliciting feedback after the event is the most common accessibility failing, it results in sub-standard products and higher development costs.
Comment by Paul Annett posted on
As you acknowledged above, this isn't a pre-release version of a product and we know it has accessibility failings. You know, we'd rather work with the accessibility community on this than feel like it's a constant battle against comments of this tone. We're on the same side after all!
Comment by Ian Hamilton posted on
Absolutely.. I'm sure I don't need to be telling you this but it's obviously not just a big opportunity but also a big obligation and responsibility, hence the reactions that there have been to not having got it right (yet).
Government websites have a very long way to go in all aspects and are crying out for an example of something decent, so no doubt everything about your project will be regularly copied.
So it's absolutely crucial that you work with not just the community but more importantly with many disabled users early and regularly, in order to make a showcase of exactly how accessibility should be done, and ensure that what's copied is a shining example of best practice.
Comment by Ian Hamilton posted on
While I fully appreciate the dire state of government (local government in particular) websites and see what you've done as a vital step in improving general simplicity and usability...
... doing it by disadvantaging disabled people is not a very nice way of going about things. Disabled users are unquestionably your most important users. For many of them use of online services are an absolute lifeline, rather than just a convenience.
A public service website must serve the public. All of it. Especially those who rely on it on the most.
Cutting corners like this does not reduce development costs, it increases them. Retrofitting is many many times more expensive than building in from the start.
Cutting corners like this does not enable you to nail the interaction design. An interaction design which does not facilitate ease of interaction with all of your core users is not nailed.
To say that you're ignoring AAA is one thing, but that's actually not the case at all. You don't even meet A, let alone AA.
http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G183
Example: http://i52.tinypic.com/qr0lye.jpg (difference between link and surrounding text on stories linked to from your homepage)
There are also plenty of AA failings on contrast between foreground and background (eg. light blue on light grey), and contrast is such as easy thing to get right.
Comment by Paul Annett posted on
Hi Ian, thanks for your comment.
Hopefully I can reassure you of a few things...
Before I worked on this project I prototyped a new venue / event listing site specifically targeted at disabled people. The clients themselves were disabled, and we spent many days observing disabled users using existing venue sites. At the end of the process we created a prototype which, much like this Government prototype, demonstrated the site's purpose to the majority of people including the stakeholders, was a starting point for discussion, and, critically, won the client funding to develop the site. The prototype was nothing more than some sketched storyboards and a bunch of clickable imagemaps – completely inaccessible, yet it succeeded in its goal.
With Alpha.gov.uk we've taken the additional step of making the prototype work for 70% of people, most of whom are thankful that we went the extra mile. Normally, prototype sites are kept locked away secretly rather than being made public, and by the sounds of your comment that's what you would have preferred because then nobody would have been disadvantaged.
The prototype is strewn with labelling saying it's not the definitive or only source of information for any of the content, so we're not excluding disabled and deaf users from anything vital.
Accessibility won't be "retrofitted" because this is just a piece of research, not a pre-release version of a site. The complete site will use the lessons learnt from this prototype, but will be developed from scratch with accessibility at it's core. So many other corners were cut to get it out quickly that in many cases the code and the design are not production-ready. We haven't singled out accessibility as the only thing to miss!
Lastly, whilst you're right that to tick the boxes of accessibility compliance might add little development time, that is in many ways just a gesture towards what disabled people really need (I know, I've done the research). To provide text resizing and high colour contrast versions, for instance, would make it look like we naïvely considered accessibility to be 'done'.
What we're talking about is creating audio described content for partially sighted users, video versions of guides for people with learning disabilities, directions to passport offices which include the distance and terrain from the disabled parking spaces to the front door. All of that does come at a cost, both in terms of time and money, neither of which we had in abundance for this prototype.
And with the content not being right, should we really have produced that video version of a guide, knowing that it would need to be re-shot later once we'd revised the content? That sounds to me like accessibility (done right) isn't something that can always be included from the start.
Actually, if you use the site you might find that it's more accessible than you think. We have included some things that have little or no development overhead, such as skip to content links, alt text on images, and semantically meaningful markup. But when it came to choosing between spending more time on accessibility or creating the autocomplete search system for instance, we chose to build the thing that would have most impact on most people, thus securing the long-term future of the project and giving us the opportunity to improve the Government's online accessibility when the project kicks off for real. An opportunity that, I'm sure you'd agree, would have been unfortunate for all users if we'd have missed.
Comment by Ian Hamilton posted on
"Accessibility won’t be “retrofitted” because this is just a piece of research, not a pre-release version of a site. The complete site will use the lessons learnt from this prototype, but will be developed from scratch with accessibility at it’s core."
You've called it an alpha version, which means a feature complete pre-release version of a site, so you can't be surprised if people pick up on things being missing.
If all this is is a proof of concept, then perhaps calling it that rather than an alpha would have avoided much of the commenting.
Comment by Paul Annett posted on
Thanks Ian.
Glad you understand the reasons behind our decisions. I agree totally that 'alpha' is not the right name for it, but mainly because it's tech jargon which doesn't translate well to a non-tech audience.
In fact, I very much suggested that we called it a prototype rather than an alpha, but internally within Government it was already being talked about as 'the alpha project' so it was too late to change the name.
Comment by Ian Hamilton posted on
"Normally, prototype sites are kept locked away secretly rather than being made public, and by the sounds of your comment that’s what you would have preferred because then nobody would have been disadvantaged."
No, it's the simple issue of your obligation to be leading the field in accessibility, and that hasn't so far been demonstrated.
Comment by Susan Parker posted on
I have to agree with some of the posters - while true that you needn't strive for "triple A" perfection" you needn't completely ignore accessibility either in order to rapidly iterate. Your post is essentially saying that it isn't important to get feedback from the disabled on the prototype. That's sad.
Comment by Richard Pope posted on
@Lucy, please don't read this as we have ignored all accessibility. Please have a look about the site and if you have any specific suggestions of things we should improve please let us know and we will take them onboard. What have we got most wrong?
Open the point about poor products, there are plenty of government and non-government websites that claim to be accessible but have very impenetrable underlying architecture and usability.
We need to understand the processes we are proving tools for in order to make them as accessibly as possible - that is part of the process of an alpha/prototype site.
Comment by Lucy Dodd posted on
Hi Richard,
Thanks for your reply to my comment. I dropped you a line via the feedback email address too. Might be better for us to chat over email instead at this point. lucy.dodd@inclusive-experience.co.uk
I don't think you have ignored accessibility entirely but I do think that: 1) Your blog is very poorly written resulting in a miscommunication about what you are really doing to ensure this site is accessible. You really ought to consider re-writing it. It sends out a message that is very negative for you and your team. That is, if you really are bothered about accessibility.Public statements like this can actually be quite damaging these days.
2) You need to be more professional and organised in your approach
Asking me (and I am sure, other experts) to take a look at your site and get back with 'suggestions' and 'what you have got most wrong' is an odd way to show that you are taking it seriously or have any intention on improving it.
Accessibility is my full time job, my profession and I like to do a thorough job when companies engage with me.
Imagine I asked you to look at my website and design some stuff that might make it better!
Getting 'passing' advice from experts 'frustrated' by this blog post is not the right way to go about improving the accessibility of your site and will not give you the feedback you need to make this a success.
I am very happy to do this for you and to give you some 'real' accessibility consultancy when you get in touch via my work email. I take a user centred approach to accessible interaction design.
I hear on the grapevine that your 'leader' is against this approach and would rather opt for metrics than user testing, but I can tell you from experience that the user is always right - even if it hurts the feelings of the design team and upsets 'senior' stakeholders who think they know it all.
Thanks again for getting in touch via this blog.
All the best
Lucy
Comment by James Pullicino posted on
This blog post sounds to me like a very naive excuse to cut corners. Real accessibility is not about ticking boxes and getting certified but about recognising people with disabilities as being part of your main audience. You certainly have not managed to 'nail' the interaction design by excluding accessibility from your focus.
I strongly suggest you change your attitude to accessibility or else it *will* become an expensive overhead which will be hard to fix.
Comment by Lucy Dodd posted on
Hi Richard,
Just read this blog with my mouth wide open in disbelief. The three points that you made that urged me to comment are as follows;
"That there’s no point being ‘Triple A’ accessibility certified if the underlying product is poor."
"But by reducing the development overhead it allowed us to really nail the interaction design, something we are continuing to improve."
"Was this the right approach? It has certainly allowed us to iterate faster and remain focused on making the product better as a whole. But we are very much open to opinions to the contrary."
I worked at the BBC as the accessibility specialist for many years, working alongside Agile teams to help them fully integrate accessibility into web products from the outset. There is no reason why you shouldn't be able to 'nail' interaction design and accessibility in parallel, without increasing the development overhead.
This statement really makes no sense at all. Your development overheads will be much higher if you leave accessibility to post launch or worse, start to receive complaints from disabled users who have a legal case because they can't use this site.
I cannot see any ground breaking interactions here that warrant this excuse either!
I also have no idea what the relationship is between a product being triple A and poor quality. Why would that be the logical choice?
I would really like to help you readjust your understanding of accessibility and enable you to make this site fully accessible. It doesn't have to be a costly or time consuming issue I can assure you.
Comment by christine posted on
I find this really rather depressing.
You seem to have entirely failed to grasp that the devil is in the detail - by refusing to adhere to any significantly onerous government standard, of course you can produce something quick and dirty (and frankly largely useless). There is nothing new here, nothing innovative, nothing that has not been done before, and better both in government and outside it.
It is a crying shame that good money has been wasted on this run of the mill, unimaginative and ponitless website.
Stop wasting my money!
Comment by Jerry Hall posted on
Currently involved in developing a portal / website for citizens to search for information and advice about personalised support to help maintain independence at home, interact with agencies (primarily councils) and share some information. We decided to go for AA compliance as we're developing in an area that is changing quickly and supporting new ways of interaction between citizens and councils. I was asked by a customer to expose the product to a sight impaired user and he found it very difficult to navigate our system. Why? Partly because of the way we structured the portal page content (which we have addressed) and partly because he struggled to use his screen reader software. He could do the things he needed to do with lightening speed but when faced with a new site he really struggled - partly with the screen reader and partly with the unfamiliarity of the new site. I wonder whether this is a factor that gets ignored when assessing how easy a site is to use. We all struggle with new sites to a varying degree and then learn how to use it - quirks and all.
Comment by Andy Williams posted on
Just read one of your other blog articles about the innovative use of APIs. Will you be considering an API style interface to this site? perhaps that could help with Accessibility as people could develop a tailored UI but still use your content and functions.
Comment by Sarah Bourne posted on
When I first saw tweets about this, and then read this post all too quickly, what I came away with was, "We're going to fix accessibility later." And two audiences - people using assistive technologies, whom I work with and for, and government employees, including me - died a little. The former group has seen this all too often: "Don't worry! We'll fix it later!" almost always becomes never. And in government, we look at those whiz-bang interfaces and know we can't use them. This approach puts the trust of these two audiences at extreme risk.
When I re-read this post, though, I realized you were saying something a bit different: you believe your site will be usable, but may be missing a few things needed for 100% checkbox compliance. I'm actually OK with that.
Checklist standards are a way of interpreting how you need to put your code together to make sure it works for people who can't use a mouse or use speech-based software (screen readers, voice recognition) or other hardware or software that helps people with disabilities. But if developers don't understand why you need to do it this way, you can end up with sites that meet all the checklists but aren't actually usable. And when you understand the "why", you stop worrying about the checklist as an end in itself.
An accessible website means you can actually use it, regardless of the quality of your eyesight, hearing, motor control, or other variations of the human condition. It means you can get the information or perform the task, without having to ask somebody else for help. And sometimes accessibility flaws, while potentially annoying, don't actually prevent you from doing those things.
These are the things you should look for to achieve basic accessibility:
Use structural headings so screen reader users can navigate to the major areas of the page.
Make sure you can do everything without using a mouse - don't forget to check the JavaScript functions.
Check your color contrast - this affects people with low vision and color-blindness, which is actually quite a few people.
Make sure you have labels for all your form elements. If you use images for buttons, make sure the IMG ALT is meaningful.
If you return data in tables, be sure to use column and row headers (TH).
Make sure pictures with critical content have good ALT text.
If you do these things, your site should be accessible enough for people to use it and be able to give you valuable feedback for improvements.
In closing, a reminder: You never get a second chance to make a good first impression.
Comment by Richard Pope posted on
@Kate - don't worry, the underlying level of accessibility will be good (certainly much better than many existing government websites).
Clean well-structured HTML, clear content, alt-tags, 'for' attributes on labels etc etc (essentially all the stuff that any professional web developer worth the title add as a matter of course) will be there from day one.
Comment by Kate Waugh posted on
Agree there's no point in ticking boxes for the sake of it, but you will need a good level of accesibility if you're intending to invite people to comment on the site e.g. compatibility with screen reading software. The underlying product might be poor, but are you expecting us all to comment on it and tell you if it's poor? If so, it has to be fully accessible to enable everyone to do that.
Comment by Janet E Davis posted on
I will be interested to see what this pragmatic approach to accessibility at this stage produces. Clear and easy navigation (setting aside whether it's achieved using javascript) is part of accessibility, of course.
Comment by dhwebOfficer posted on
With the number of IE6 users still high, especially within government, what are your plans to address this?
Comment by Tom Loosemore posted on
We do not plan to support IE6 as part of the alpha. As mentioned in my initial blog post, Microsoft have recently launched a campaign entitled "IE 6 Countdown" to persuade everyone to upgrade. In the UK it has 3.5% market share, falling rapidly.
The alpha is not built for Government employees - if you're stuck on IE6, you have my utmost sympathy. Moan, loudly.
As Microsoft themselves put it, "It's time to say Goodbye"
Comment by Tony Scott posted on
Not supporting IE6 should cut your development time by 50% 😉