Yesterday I had a message from Jonathan Hassell, Head of Usability and Accessibility at the BBC, to let me know about the 2nd draft of the much publicised BS8878 British Code of Practice on Web Accessibility. Rather than paraphrase Jonathan, I’ve just copied his message below:
As you may or may not know, the British Standards Institute have now published the 2nd draft of the BS8878 British Code of Practice on Web Accessibility.
This post has been written for Blogging Against Disablism Day 2010.
I recently bought a new phone. It’s great, but like most smartphones it’s taking a bit of time to get completely used to the complex interface.
On the second day of playing with it, I was browsing the web and came across a site which had Captcha. It was a Google product, and I had to complete the Captcha field to continue with what I wanted to do. The problem was, the image that it had come up with was terribly distorted, and I couldn’t make out the letters and numbers. I tried several possibilities, failing every time. Normally I would simply refresh the page to get a new image, but I hadn’t yet learned how to do that on my phone! I tried going back then forwards again, but it just loaded the same image. And crucially, there was no link to an accessible alternative.
It was one of those rare occasions where I had hit an absolute brick wall because of an inaccessible web design feature.
As we’re currently considering designs for our organisation’s new website homepage, I thought it would be interesting to bring together all of the 11 local authority websites which were awarded the full 4 stars by SOCITM’s Better Connected 2010 report.
Hot on the heels of their (always hotly debated) annual report on the state of local government websites (Better Connected 2010), we were pleased to welcome SOCITM reviewer John Fox to a workshop session this morning to provide what he described as a “web content ra-ra-ra presentation”.
Disclaimer – I haven’t had the chance to read the full #BC10 report yet. I hope to add my own perspectives to this blog once I have. What follows is a summary of John’s presentation on the report and what he thinks it means for local authorities.
More on Better Connected 2010 and John’s presentation
Jakob Neilsen has just announced his 10 best-designed Intranets for 2010, and as always it’s a goldmine of information and advice. I haven’t yet forked out for the full report, but the summary alone offers plenty to think about.
One particular point that will raise eyebrows is the continued advocacy of separate sites for mobile devices. There is an ongoing debate about the pros and cons of such an approach, brought to the fore by Neilsen’s post last February comparing Mobile Web 2009 with Desktop Web 1998, and concluding that a separate site is best. Many of us were not convinced, and as Henny Swan argued at the time:
It also hints at repeating the mistakes of desktop web design circa 1998 where we thought the answer was to design for one browser, use proprietary technology, build text only websites for disabled users…the list goes on. So let’s not make that same mistake and instead fast forward to one of the principles of good web design that dug us out of the dark hole of 1998: progressive enhancement.
Henny described how a ‘one site fits all’ approach can be achieved using media queries, and it’s certainly a far more attractive solution than designing and maintaining separate sites.
But this all relates to websites in general, rather than specifically to Intranets, and I was interested to look closer at the suggestion of a separate mobile Intranet.
Intranet on the move?
More about mobile Intranets, and why a separate site may be justified
Yesterday, the Google Code Blog announced Google Browser Size. It’s a handy little tool which allows you to take a contour visualisation of common browser sizes and overlay it onto your own sites, to easily spot which areas people can see without needing to scroll. So for example, here’s my site with the overlay applied:
Browser sizes as an overlay
More about Google Browser Size, and why scrolling isn’t actually all that bad
Today is CSS Naked Day.
The idea is simple – websites all over the world are stripping off their CSS for a day, leaving their sites naked and unstyled. If those sites have been designed well, according to web standards, the sites will still appear in logical order with all content perfectly accessible.
Checking a site with CSS turned off is a great way of detecting possible problems. Many assistive technologies ignore CSS, for example, so over-reliance on styling can lead to problems.
For example, imagine you use CSS to call up a background image. But then imagine that background image is actually an image of content (for example, when people put contact details on the background image of their Twitter page). Without CSS, you won’t see that image, but have you provided an alternative?
The Pretty Simple website without CSS - less pretty, more simple
CSS Naked Day is a great way of flagging up the need for good web standards, and in that spirit I will be shedding my CSS over at www.prettysimple.co.uk. (EDIT: CSS now back on – it was getting too cold!)
I love argument, I love debate. I don’t expect anyone just to sit there and agree with me, that’s not their job.
Margaret Thatcher
Debate and discussion are vital to the progress and development of web accessibility. With that in mind it’s great to see that, as ever, there is plenty of discussion going on out there in the fora, blogs and Tweets of those interested in the subject.
(more…)
I was interested to read, on the RNIB website, that there are an estimated 2 million people with significant sight loss in the UK, 70% of whom have other disabilities or long term health problems in addition to their sight loss.
That’s a really interesting statistic, because it highlights the fact that when we try to take into account the needs of disabled users, we often aren’t talking about individuals with just one disability. People will often have a combination of needs, and we must respond by designing for this diversity, rather than taking a locked-down, ‘one-size fits all’ approach.
A good real world example of this was when I worked in a library. The library had an easy access PC terminal, offering the following features:
Although provision of these facilities was excellent, there was a problem in that often the combination of all of these features proved a barrier in itself. For example, a regular blind user found it difficult to use the large-key keyboard as they were used to a normal keyboard, the layout of which they were instinctively familiar with. Thus, the keyboard was great for users with impaired vision, but not so great for blind users, who had to ask for help finding the location of certain keys (in fact, many keys had been left off completely).
What we quickly realised was that people needed the ability to customise the set-up according to their needs. So we had a normal mouse and keyboard on standby for anyone who requested it, advertised by large-print and Braille posters next to the terminal and backed up by regularly monitoring the terminal to offer assistance. Not the ideal solution, but better than nothing.
This is just as true for web products – we can all too often be guilty of making assumptions about our users and designing solutions based on those assumptions, rather than thinking about real world users. A good example of this is skip links. We know that screen reader users like to utilise skip links, but too many sites hide these links, making them hard to find for sighted keyboard users (for example, those with limited motor skills meaning they can not easily use a mouse). Even worse, when skip links are visible, they are often presented as tiny text, presumably so as not to confuse or distract other users. But what about non-mouse users who have impaired vision and can not read tiny text?
WCAG 2.0 recognises the challenge that all this presents:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.
…and it is a reasonable caveat. However, that doesn’t stop us doing all we can to take into account as many different scenarios as possible, and not making assumptions which cause more harm than good. Offering the ability to customise the page in a variety of ways, or at least not blocking the user’s own browser preferences, is crucial. And, as always, user testing remains a vital ingredient.
I’ve probably raised more questions than I have given answers here, but I hope to do more research on this subject soon, so stay tuned.
I’m desperately trying to get my organisation to realise that mobile browsing is fast becoming very popular, and that we need to design accordingly. Mobile phone penetration is immense in the UK, reaching 100% in 2005 (i.e. one mobile for every person, on average). This near-ubiquity makes them a vital target technology.
However, a debate has been sparked about how best to provide for your mobile users. Usability expert Jakob Nielsen has just published an article comparing the Mobile Web 2009 with the Desktop Web 1998. Ultimately he calls for the creation of separate sites for mobile devices, and therein lies the debate.
Henny Swan discusses why building a separate site is not a great idea on her blog. This follows on from Bruce Lawson’s own musings on whether mobile web development is compatible with the One Web.
I’m definitely against the ‘two sites’ approach in most instances, and many devices nowadays have decent browsers which render pages just fine anyway. For this reason I hate it when I get directed to a Mobile version of a site, often with greatly reduced functionality. By all means offer a stylesheet optimised for mobile browsers, but make it my choice to switch to that (I’ve seen good examples where the main page says “we have detected that you’re using such-and-such device – you might be interested in viewing the mobile version here”).
One issue brought back to the fore when building for mobile devices, though, is the need to keep page sizes down. Designers have increasingly been discarding that ethic with the rise of broadband, but we need to keep building lean sites with clean code to help those who are paying by the MB to browse (as well as for all the other reasons)!
Of course, we’re also seeing a proliferation of apps designed for mobile devices, often allowing them to bypass the standard websites completely (for example, I have Y! Mobile on my device which pulls in my Yahoo e-mails, weather and news etc, without actually visiting the Yahoo website itself). This is a whole new way of enticing mobile customers to access your site’s functionality.
All of this is really about the wider issue of usability. I’d like to do some decent research on what disabled users expect from their mobile devices before taking a definitive stance on the accessibility issues. For now, though, I won’t be building any separate mobile sites – just concentrating on getting the main one right.