Whilst guidelines for web accessibility have been in existence for several years and are slowly evolving, until now there has been a lack of best practices targeted specifically at the additional complications of mobile accessibility (web or native). This is especially important now mobile use is so predominant and I believe is globally in the majority due to so many people outside the affluent West having phones and not computers.
Yesterday Henny Swan finally made an exciting official tweet:
Introducing the Draft BBC Mobile Accessibility Standards and Guidelines:bbc.co.uk/blogs/internet…#Mobile#Development#Design#BBC
Henny also blogged and Gareth Ford Williams followed up with more details on LinkedIn
Just to let you all know the Draft BBC Mobile Accessibility Guidelines were published today. You can find them on the Future Media Standards and Guidelines site at:
A blog post about them is here:
The guidelines are in accessible PDF and Word format at the moment but should be in a much more digestible and usable format soon so watch this space.
These standards have been developed over the last 18 months and have been developed and tested using the following mobile projects: BBC Olympics, BBC Sport, BBC iPlayer, BBC iPlayer Radio and BBC Weather.We are asking for feedback to identify areas of focus for the the further development of the guidelines and any comments, would be greatly welcome.
Best Regards,
Gareth Ford Williams
Head of Accessibility, BBC Future Media
This is an excellent start and should help raise awareness of the issues amongst commissioners, designers and developers and so improve the accessibility quality of apps and mobile tech in general.
Image by Hajime NAKANO http://www.flickr.com/photos/jetalone/
So just what exactly are the extra accessibility issues introduced by mobile tech? Well I like to think that accessibility boils down to this simple design mantra:
Don’t make assumptions about how users will access your content or app.
Obviously any engineering or craft activity has to make some assumptions or nothing useful would ever be created. However the assumptions can and should be minimised within meaningful constraints if we want to avoid excluding users (and so reducing market).
For example, it’s a good idea to not assume that all users will be using a mouse and can easily interpret visual-only cues. These assumptions were initially thought of in the context of users with disabilities, though some folks (myself included) pointed out they effect a much wider usage. For example, many users prefer to use only a keyboard for speed of access and a search engine “spider robot” is effectively a blind user. In fact a few years ago there was a hot debate over if accessibility should be primarily for people with disabilities or of general utility. Fortunately, this soon blew over and accessibility efforts are now concentrated on improving accessibility for all users and use cases.
With the rapid rise in mobile technologies (and I include all portable formats in that definition) it soon became clear that “contextual disability” also occurs and needs to be specifically addressed. For example in bright light conditions the screen becomes hard to read, if not impossible. thus, adaptations usually designed for people with low vision or blindness are potentially usefully for all users in certain common circumstances. Another example is that when driving a car verbal interactions are much more appropriate so hands and eyes can be used for safe navigation.
Another design assumption has become apparent with the very wide variation in screen size and resolution across devices (eg Apple’s retina displays). In the early days of the web this was not an issue as screen size was a small range and as text was the content the browser was free to reflow to any screen size/resolution. However as I found when trying to make my first ever website with graphics look good on both 19″ and 13″ monitors, it isn’t that easy to accommodate variations. In fact given the state of browsers and HTML then I gave up.
Now we have a name for handling variation in screen resolution on the web; ‘Responsive design‘. With this a few core techniques allow the user experience to be adjusted according to screen size. At this point in time however, the technology such as CSS media queries is still a little immature, certainly when compared to some native solutions I have used. However this is a hot topic with solutions like CSS Grid Layout looking very interesting. We can expect rapid improvements.
In addition to screen size variation, the almost ubiquitous use of touch technology on mobile devices provides a new challenge for designers wishing to target multiple devices. Leading the charge are web apps and widgets which offer a path to creating solutions that can run on devices ranging from small screen mobile with touch to traditional desktop with large monitor, keyboard and mouse. In this space the W3C and others are working on new specifications for handling different input modes in unified ways.
Windows 8 appears to be targeting this world of portable and desktop devices and their different interaction modes. At the moment it’s somewhat schizophrenic with both the Windows Store Apps and traditional Windows 7 style desktop sides being quite separate. However I think we can expect Microsoft to learn and develop the user experience rapidly. What is of special interest is that Windows Store apps can be created using the key W3C specified open technologies (actually, this may be the preferred technology). This allows portable solutions to be more easily developed. Add the fact that Microsoft now play an active part in web standardisation efforts, we can expect improvements in the device and accessibility support in both Windows and web solutions.
A final assumption is more an issue of device and operating system manufacturers not supporting interaction methods available on desktop and that are commonly used by people with disabilities. In particular people with physical disabilities who use simple switch devices to interact have had little access to mobile devices. On the desktop, switches are nowadays connected as USB devices (often simulating games controllers) but very few mobile devices have USB sockets. Bluetooth is a viable alternative and for example Komodo OpenLab’s Tecla switch access device uses this approach to provide switch control of Android and iOS devices. An exciting development here is that iOS 7 includes switch controlled scanning and so we can hope Android and Windows will take note and follow.
In some ways it’s reassuring that mainstream developers are hitting and addressing many of the issues that the accessibility community has be working on for some time. We can expect faster and more innovative solutions. As long as accessibility remains firmly on the agenda and the accessibility community keeps up the highly effective work to help ensure vendors keep their eye on the ball..
Along with the W3C Mobile web Initiative, the BBC draft guidelines have an important part to play as we collectively figure out how to remove damaging assumptions and create usable and accessible solutions that are available on a wide range of platform formats. As the authors point out, these are a starting point and they welcome the discussion on how to move forward.
As a footnote, the Cloud4All EU project is exploring automatic personalisation of devices according to a users accessibility preferences profile. This will act as a way to help remove the sensitivity to designer assumptions by applying the best available adjustments. An important part of this work is context awareness.
[Update 2013-06-20] in addition to the W3C Web Events working group the IndieUI and Pointer Events working groups are also working on combined input modes.