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.

Briefly, the standard is designed to be an end-to-end guide to helping web product (website, mobile site, IPTV site) owners ensure their products condier the needs of disabled and elderly people at all stage of the web production process, from initial requirements gathering, through selection of technologies and platforms, testing, launch and maintenance.

It’s a standard for web producers, project and product managers, who need to understand the process of how to create accessible web products, rather than how to create the technology, design and editorial of web products (which WCAG already does very well).

It will supercede the previous PAS-78 guidelines, updating them to include guidance on such topics as:

• The Equality Act 2010
• The relationship between inclusive design and user-personalised approaches to accessibility, including whether to provide additional accessibility provisions
• Creating accessible web products for computer, mobile and IPTV platforms
• How to procure accessible web products
• How to assure a product’s accessibility throughout the production process, including the value and costs of different forms of accessibility testing
• Dealing with feedback and complaints on accessibility from users

The standard is a guide to the use of the different accessibility guidelines out there (bringing together references to the work of WAI-WCAG and WAI-AGE, as well as others), rather than replacing or replicating those existing guidelines.

This Draft for Public Consultation is a chance for people to tell us whether our drafting committee have got the content and style of the standard right and both given them an idea of the breadth of the parts of their production process that accessibility issues impact, and also demystified accessibility so they feel confident they know how to proceed.

DPC BS 8878 can be viewed at www.bsigroup.com/drafts until 30 June 2010.

Jonathan Hassell

I certainly aim to pop along and comment, and I’d urge others to as well.

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.

What did I do? Well, I could have fired up my laptop and done it on that. I could have closed the browser and logged back on, or tried again later. I did none of those things – the moment was lost, as was my interest in completing the task. But what if it had been something really important?

The experience reminded me of a few conversations I have had recently about web accessibility, and all of these had a similar theme – the unnecessary need for some users to take the long way round to access information.

In terms of web accessibility, the most serious type of problem is when a user can’t access information at all (for example, when no alt description is given to an image containing important content, such as navigational tabs). But there is also the slightly ‘softer’ issue where information is available, but the user has to work to get to it.

Are you sending your users the long way round? (Photo by incurable_hippie)

Someone recently posted to the Accessify Forum, asking whether it was a good idea to create an alternative accessible version of a website. I recommended that this be avoided, as it creates an unnecessary division between ‘types’ of user which is undesirable and potentially discriminatory. Making it necessary to click on a “Text-only” or “Accessible” version simply introduces another workaround which some users will have to use, and goes against the principles of inclusion and integration that Web Accessibility tries to promote. It reminds me of when you see signs for wheelchair access which take you round the back of a building – some people will have to take the long way round, and may feel quite inferior as a result.

Another example was during the recent televised UK election debates. When the second debate televised by Sky News hit the airwaves, there was immediate outrage across Twitter and the web at the fact that no live captions or BSL interpretation were available. This meant some users had to look elsewhere for the content – something they should not have had to do.

THERE ARE NO #SUBTITLES (why not?) on #leadersdebate it is NOT #accessible for 1 in 7 (70,000) #DEAF people @skynews you #fail!!! pls RT

An angry Tweet from Pesky People

Too much of the web involves these sort of workarounds for some users, and the problem seems to be that some developers think that this is good enough. Going back to the building analogy, there are often very reasonable factors which mean ramp access has to be round the back – for example, to comply with building regulations. However, there are far less reasons why a web site should require someone to take the long way round.

So if you’re a developer, give consideration to how you’re presenting your content and think carefully about whether you’re offering an equal experience for all your users. Forcing someone to take an alternative route or employ workarounds to get to your content, just as with my experience with Google on my new phone, may well mean they give up and go elsewhere.

Photo derived from a work by incurable_hippie used under the Creative Commons Attribution-Noncommercial license.

In doing so, I was surprised by the variety of approaches taken by these best-practice sites. I had hoped for some clear trends and design methodologies, but instead found some striking differences. Of course, the presentation of the homepage is only a small part of the story on any website, and given that many users will come in via search engines (and thus possibly never even see your homepage), any analysis should be proportional.

Nevertheless, visual comparison of the 11 4-star websites does offer up some useful inspiration and the similarities have plenty to tell us.

Note: screenshots taken in March 2010

On this page:

• The 4 star websites
  • Allerdale Borough Council
  • Brent Council
  • Buckinghamshire County Council
  • Cambridgeshire County Council
  • East Sussex County Council
  • Exeter City Council
  • Newcastle upon Tyne City Council
  • Oxfordshire County Council
  • Salford City Council
  • South Tyneside Metropolitan Borough Council
  • Worthing Borough Council
• Similarities
• Surprises

The 4 star websites

Allerdale Borough Council

www.allerdale.gov.uk

Brent Council

www.brent.gov.uk

Also see the comments below for a link to Brent’s upcoming, minimal version.

Buckinghamshite County Council

www.buckscc.gov.uk

Cambridgeshire County Council

www.cambridgeshire.gov.uk

East Sussex County Council

www.eastsussex.gov.uk

Exeter City Council

www.exeter.gov.uk

Newcastle upon Tyne City Council

www.newcastle.gov.uk

Oxfordshire County Council

www.oxfordshire.gov.uk

Salford City Council

www.salford.gov.uk

South Tyneside Metropolitan Borough Council

www.southtyneside.info

Worthing Borough Council

www.worthing.gov.uk

Similarities

• 7 of the sites had clear links to RSS feeds
• All had links to latest news
• 9 of the sites put the main categories on the right-hand side
• Most had localisation features – often via a postcode search or similar

Surprises

• The length of the homepages was a surprise, with some stretching to three screens long (with a 800px high viewport).
• Many of the pages appeared quite text-heavy.

Is there anything else you think is notable about these screenshots? Do you have a favourite? Let me know via the Comments section below…

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.

Summarising the report, John spoke about the negative headlines that we can expect to see coming out of this year’s findings, which stated:

‘Given the urgent need for councils to deliver more for less, it is really disappointing that the performance of this lowest cost service delivery channel seems to have stagnated over the last year. This should not be taken as a criticism of web managers, many of whom do an excellent job with limited resources. Rather, responsibility lies with councils’ top management, many of whom still do not recognise the key role of the website in reducing corporate costs through the efficient management of customer enquiries.’

Martin Greenwood, SOCITM Insight programme manager

Indeed, such headlines are already cropping up:

• Local government web use ‘disappointing’ (BBC News)
• Most councils not yet ready to support self service (eGov Monitor)
• Slightly Better Connected: Annual survey paints a gloomy picture (UK AuthorITy)
• Council Website not ready to ease the cuts (Local Government Chronicle)

But John was quick to reiterate the point that the criticism isn’t aimed at the hard-working web teams across the country, but rather the management figures who are holding back the development of this vital channel. The middle management strata, John suggested, is full of people who simply ‘don’t get the web’ – and no matter how dedicated your webteams are, or how much buy-in you have from the very top, this is always going to be a major problem.

Why is the web so important in local gov?

Now more than ever, the web must be seen as a vital channel for service delivery. With local authority cutbacks looking like they may be as drastic as 20% in some areas, the need for self service is critical. This is closely tied into the concept of avoidable contact – where people help themselves to information online at a far lower cost that requesting it directly from a member of staff.

And the figures are impressive. SOCITM estimate that whilst a web transaction costs an authority just 39p on average, the equivalent transaction by telephone costs £3.21 and a face to face encounter sets us back a whopping £8.23 (Source: SOCITM Insight, Dec 2009). Of course, some people will always want, or need, to use the more traditional channels, but the web is a vital addition. And currently, despite being the cheapest channel, the web continues to also be the one that delivers the highest levels of failure and dissatisfaction.

Taking actual stats from SOCITM’s Insight take-up service, John showed how, year on year, people appear to be finding less of what they want on local gov sites, with satisfaction levels also dropping. In terms of numbers, one metropolitan district had a failure rate of 36% (people who said they did not find what they wanted). This translated to 43,018 visitors, and if we assume all of these people were forced to make contact with the authority in a different way, the cost implications are huge.

How good are local gov websites?

The SOCITM process assesses whether a site is useful, usable and used. It uses a main survey of 120 questions, carried out by 12 reviewers, with 5 supplementary surveys and additional data (for example, from accessibility tests carried out with the RNIB). A total of 433 local authority websites were assessed.

The report uses a new 4-star ranking system, with 9 essential criteria:

• Information
• Links elsewhere
• Currency
• Transactions
• Use of A to Z list
• Use of search engine
• Navigation
• Use of location
• Accessibility

The report is intended to help councils understand the state of their own development, and with nearly 50% of sites getting just 2 stars, there is plenty of room for improvement. Only 12 got the full 4 stars this year.

Stuart Harrison’s mash-up of Better Connected 2010 results

Best practices

John talked us through a number of good examples of sites that had done well, and reported on feedback from the reviewers which praised sites for:

• clear, consistent navigation
• good A-Zs
• high standards of content
• a pleasurable overall experience
• useful eServices
• good locational information

John used Allerdale BC, East Sussex CC and South Tyneside MBC to highlight some of these good points – these all got 4 stars and are worth a look.

Allerdale Borough Council - getting it right, says SOCITM

Changing to a web culture

John mentioned a number of things that we need to be doing to bring about the cultural change necessary to support the web as the principal customer service channel.

Perhaps the most fundamental is to “think customer”. The web should be 100% about the user and their needs. Everything we do on the web should be for our citizens. This potentially means rethinking a lot of the content we currently offer.

Also, service providers need to “think web”. Posting info to the website shouldn’t be an after thought, or a box-ticking exercise. It should be at the heart of everyone’s processes.

Next, we need to advocate the web to our colleagues, who in turn need to advocate it to their service users. We need to sell the benefits, and promote the channel wherever possible. An obvious example is if someone receives a phone call about something that is available on the web – use that opportunity to promote the website, so that next time the contact can be avoided and the user can benefit from all the other content on there.

The customer journey

There was time for a look at a few more good and bad examples of content, before a final consideration of the customer journey. Wycombe DC was given as a good example of delivering a strong focus on task management – enabling citizens to quickly do what they need to do online.

Salford’s postcode search was another good example of providing additional functionality, pulling in maps, democratic info, refuse collection times, local facilities such as schools and community centres, whilst also linking to key online tasks such as council tax and planning applications. Such “find my nearest…” searches are becoming increasingly useful as data can be brought in from a number of sources, and are a great way of presenting a broad range of relevant information on a local gov website.

Finally, a mention of the fact that the customer journey may go beyond our own site. What if the service is provided by a different organisation? Are we providing links to related info and other sites, to help our customers get the information they need, wherever it may be? This can have its own challenges in terms of sustainability and accuracy, but is another example of providing an excellent, and complete, customer service online.

John’s presentation came at an opportune time – we are currently working towards implementing a replacement system for our websites and taking a long, hard look at both our web content and our customer’s experience of interacting with us online. We may have only got 2 stars this year, but I look forward to seeing where we rank in BC2011.

More thoughts on the Better Connected 2010 report to follow soon. In the meantime, local gov bods can log onto Communities of Practice to follow some interesting #BC10 discussions there.

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 Swan: Progressive Enhancement for mobile

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?

Mobile Intranets – a unique case?

Intranets serve a very specific business purpose, and for a defined set of users, so the scope for delivering a useful mobile version is arguably better than with a public site:

1. You’ll have a far clearer idea of who would want to access a mobile version, and for what purpose.
2. You’ll also have a good idea of the devices being used to access the Intranet, assuming they are company-issue.
3. Finally, the potential advantages that a tailored mobile version could deliver to staff are tangible and might justify the time and effort required to build and maintain.

Neilsen points out a couple of potential problems – one being that most staff will already be in an office (and therefore presumably have desktop access) and the other being the possible lack of technical expertise at operating handheld devices. The first point is simply part of the business case – if you have a significant amount of staff needing Intranet access out of the office, then you have a compelling business case. The second point is a training issue – and in fact many companies might equally observe that some of their staff aren’t skilled enough to operate their desktop computer properly either. If the business case exists for such usage, either from a desktop or a mobile device, then training should be in place to support that. Neilsen also observes that devices are becoming far easier to use, reducing this risk.

Neilsen also points to a move towards “anytime, anyplace” access. This is certainly true of many large companies who are promoting flexible working options, and is likely to be a crucial element of any business case for creating a mobile-friendly Intranet.

Working on the move

So let’s assume we do want a separate mobile Intranet. What will it look like?

For a start, how do we access it? Will the user be required to log-in? That would seem sensible – an Intranet is, by its very nature, not for public consumption, and the risk of the employee’s mobile device being lost or stolen means that security must be considered paramount. Measures such as automatic time-outs might also be necessary, as well as preventing log-in details from being saved by the device.

Once logged in, what would we want to see? This is where a bit of research will prove invaluable. Find out what the key tasks are and make them easy to access. Accessing staff directories seems to be an obvious one, for example, as well as receiving any urgent news or alerts. Customisation would be ideal here, allowing people to compile a list of common tasks and links.

Opening documents

My organisation’s Intranet is probably fairly typical in that it has a massive amount of information available as downloads – PDFs, Word documents, Powerpoint presentations etc. Whilst some newer generation devices can handle these quite well, it’s important to remember that they can cause issues when downloading and opening (because of large file sizes, incompatible formats etc). As with any website, any key information should always be available as a web page as well as a download, and a company moving towards a mobile-friendly Intranet must keep this in mind.

Is your Intranet awash with downloads?

Apps

Neilsen mentions one team that developed a dedicated iPhone app, rather than building a separate site, to optimise the design for mobile users. This sounds like a perfect compromise, but only if you have full control over the devices that your staff are using, and only if those devices are advanced enough to support such apps. We’re not all lucky enough to get iPhones from our employers, so this may not be realistic for many, but the use of apps is nevertheless a good example of improving usability for mobile users.

Publishing from a distance?

As a web author for my organisation, I can see tremendous benefit in being able to not only access the Intranet on the move, but also to update the pages too. Mobile access to the publishing environment could be a killer feature, either via a browser-based interface or using a dedicated app. Again, the security risks of this are obvious, so measures would need to be in place (such as multiple log-ins or gated publishing requiring third-party approval). But the potential could be huge – especially in emergencies or out of office hours.

Standalone systems

One issue that may be harder to conquer is the fact that many Intranets are also a portal to numerous standalone systems and databases. Staff directories, forums, pay systems, HR processes, online forms, room bookings etc – these are very often delivered as separate products and making them available to a mobile device could be far trickier than simply re-formatting some webpages. Any business case would need to look at the practicalities of this and decide how crucial these additional systems are to an employee on the move.

Adaptability

One of the most convincing arguments against designing mobile-specific sites is that devices are constantly updating and advancing, and that there are very few universal standards to design to. Even if you know what devices your staff are using today, it could be that they are upgraded far sooner than your website will be. Any attempt to design a mobile-specific site would need to have sufficient adaptability to ensure that the next corporate upgrade of devices does not leave you with a useless mobile site. I’ve seen huge problems with companies designing Intranets to suit their dominant corporate browser version (for example, IE6) which then holds back any attempt to refresh that browser later on, in the fear that their sites will break (which, in the case of IE6-friendly sites, will almost certainly be the case).

Mobiles - evolving fast (image by True Blue Titan*)

Conclusion

For the reasons explored above, it’s more likely that a mobile Intranet will be a stripped-down version of its desktop self for reasons of practicality, rather than usability, although there is an argument for offering a tailored design to streamline the most common tasks undertaken by staff on the move. This is unlikely to be successful without significant investment of time and expertise, however, so a strong business case is crucial to put focus on what is to be achieved.

Failing that, designing your Intranet with mobile-specific styles, or at least adhering to common best practice and web standards, will help to ensure that anyone logging on whilst away from the desk will still get to what they want.

* Phone Evolution image is a derivative of a photograph by True Blue Titan, used under the Creative Commons licence

Browser sizes as an overlay

What this shows is that, for example:

• only 1% of users have to scroll to see all of the main banner on my site
• 80% can see the Latest News box in its entirety, without scrolling
• Half of users have to scroll to read the Good Causes section

That’s all very interesting, and Google cites a good example where a call to action on a page (in their case, a “download” button) was below the fold for 10% of users. However, the logic gets a little fuzzier when they state:

Using this visualization, Bruno confirmed that about 10% of users couldn’t see the download button without scrolling, and thus never noticed it.

Introducing Google Browser Size – Google Code Blog

Spot the error – the assumption that users will not notice things below the fold.

Thinking beyond the fold

This assumption doesn’t ring true with my experience of user testing, where people will almost always scroll if it is clear that more information exists below the fold. And I’m not alone in observing this. A recent article over at cxpartners talks about the myth of the page fold, describing how user testing revealed that users don’t actually mind scrolling:

People tell us that they don’t mind scrolling and the behaviour we see in user testing backs that up. We see that people are more than comfortable scrolling long, long pages to find what they are looking for. A quick snoop around the web will show you successful brands that are not worrying about the fold either.

The Myth of the page fold – cxpartners.co.uk

This is a really good example of how user testing can be used to prove (or disprove) dominant assumptions about user behaviour.

And there’s a wider issue here – that of separating content from presentation. We shouldn’t be wasting our time worrying about the minutiae of how web pages look, especially given that the rise of mobile browsing makes this pretty hard to do anyway. When you add user preferences such as increased text size, this becomes even harder, if not impossible, to truly account for.

With that said, I really like Google Browser Size, and think that what it does do well is remind us that there are so many variations out there that we simply can’t account for them all. By all means use it to identify a few quick wins (for example, an important call to action should be at the top anyway), but don’t get too hung up on making your site fit every shape and size of browser.

Horizontal scroll

It’s probably worth pointing out that when we say that users don’t mind scrolling, we usually just mean vertical scrolling (up and down). Horizontal scrolling is a different matter entirely, and in my experience users hate to have to scroll horizontally. There are some nice examples of how you might get away with it if part of the design (see Design Meltdown’s gallery of horizontal scrollers), but unintentional horizontal scrolling can drive users away in no time at all. Avoid inflicting this upon your users by designing to the lowest common width of your intended users, or (far better) implement a fluid-width design.

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!)

Some fellow CSS naturists

• Jack Pickard
• Johan De Silva

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.

For anyone looking to get stuck in, Accessify Forum offers an ideal starting place. Expect plenty of well-informed and well-meaning conflict around all things accessible.

Meanwhile, Henny Swan has sparked an interesting, albeit oft mooted, discussion on her blog (iheni.com) about whether accessibility is only for people with disabilities. My opinion is that it is – we have other terms (usability, availability, etc) for talking about the needs of other users. Any attempt to broaden the scope could lead to losing sight of that – although all are, of course, inextricably linked. Not everyone agrees, though. Go see for yourself and join the debate.

And elsewhere, Ann McMeekin of pixeldiva.co.uk is running a poll on the use and location of a site’s Accessibility link. Plenty of discussion already, with a surprising number of people unsure of what such a page is. Should it offer practical tips, a technical statement of conformance, or both? And should it be proudly placed at the top of the page or squirreled away elsewhere? Cast your vote today!

And for Local Gov types, this year’s Better Connected report from SOCITM is at the centre of a little bit of discontent over at the E-Access Bulletin, which has put what some consider to be an overly negative spin on the results. Given that it heavily focuses on findings based on the superseded WCAG 1.0, it was obvious that debate was on the cards.

These are just a few examples of the wonderful discussions going on, and it’s only through engaging in these debates that we can reach the right conclusions and increase the efficacy of our own attempts at building an inclusive web.

So don’t just sit there – go debate!

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:

• Raised desk to allow wheelchair users to get nearer the keyboard
• Large-key keyboard
• Trackball mouse
• Screen reader software and headphones
• Screen magnification software enabled by default

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.

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.

Related links

• There’s a discussion about this on AccessifyForum, including an edited version of this very post.
• Bruce Lawson has written an article on ZDnet: Forget the mobile web: One site should work for all.
  
• Also see the W3C’s Mobile Web Best Practices (MWBG), as well the relationship between MWBG and the Web Content Accessibility Guidelines.