Anyone looking for a definitive set of mobile accessibility guidelines will be a little disappointed if they’ve ended up here because the bad news is that there aren’t any publicly available ones. I’m involved in writing some and am aware of other organisations doing the same but until these are published all we have are generic resources and a few platform specific resources.Continue Reading Resources for Mobile Accessibility Guidelines
I tweeted yesterday about the Vodafone Foundation Smart Accessibility Awards (#vsa2011), a competition to get developers, designers and users together to come up with an idea for an application that can help older and disabled users:
The Vodafone Foundation Smart Accessibility Awards is a new contest to promote the development of IT applications designed to improve the lives of those with disabilities and people that are older, to help them get more actively involved in society.
It’s a great idea for a competition and has already generated a lot of interest over Twitter. There’s also been a few people asking if I know of any developers, designers or people with ideas that I can put in touch with one another.Continue Reading Vodafone Foundation Smart Accessibility Awards 2011
Sounds obvious doesn’t it, keeping content consistent, but the devil is in the detail. When it comes to writing alt text teams rarely pool their work, let alone have a considered approach to what is appropriate alternative text across websites and mobile.
Screen reader users rely on ALT text to understand content and functionality. On desktop this is well known but on mobile, be it a mobile version of a website or an application, its a different story. If alternatives are not forgotten they’re often badly written, verbose or repetitive which is a problem for voice output users on mobile and tablets such as iOS VoiceOver, Talks/Nokia and Blackberry/Orator and more. Given increasing numbers of screen reader users with mobile devices this can make for an extremely disappointing experience.
To put this into context an organisation’s website may be available as desktop and mobile websites built using Web Standards (HTML, CSS, WAI ARIA etc), W3C widgets (also using Web Standards) or applications for Android phones/tablets, iPhone and iPad – with Android and iOS built using different languages. This is of course a far from exhaustive list.
That’s potentially a lot of technologies to juggle all of which have a means to provide text alternatives for images and objects. It makes sense therefore to use a shared set of text alternatives.
Document images and names
As part of your content strategy document what images your sites uses including logo’s, icons, buttons, thumbnails, background and decorative images. Because we live in an ideal world I’m going to assume you have no images of text, layout or spacer images. Note what images are shared across websites, mobile devices and tablets.
Once done give each image a text alternative that is short and concise, describing what the image is or what it does. Make sure the text alternatives makes sense across your various devices and review your list to see if any images need further explanation in the form of a tooltip. It’s rare they do but sometimes necessary. It may also be that a tooltip is needed on iOS but not necessary on desktop.
The table below shows how three images might be classified:
|BBC 4||NA||NA||Web, Mobile, Android and iOS||CSS background image with HTML text replacement|
|Play||Button||Double tap and hold to play (iPad only)||Web, Mobile, Android and iOS||Only needs a tooltip on iPad|
|||Download [item name]||Button||NA||Web, Mobile, Android and iOS||Must dynamically update with item name|
In the table above you’ll notice that the BBC 4 logo is set as a background image and as such needs to be given an HTML text alternative. The download button also needs to include the name of the item it is downloading as there may be other items for download on the same page. This needs to be made a note of so each team working on each delivery context can implement this.
Someone needs to take ownership of this process working with content editors/developers/product managers from teams delivering apps on various devices. All too often it’s left to the developers having been disowned everywhere else.
Document image attributes according to different devices
Once you have documented text alternatives for images establish how alternatives can be assigned according to different delivery contexts. The table below lists a few delivery contexts and what attributes are used to give the image a name, describe what they are (button, link, image etc) or provide additional explanation in the form of a tooltip.
When assigning names, types and tooltips there are a few things to keep in mind:
All images must have a name. Names should be one to four words, succinct and to the point. They should start with a capital in order to ensure the correct inflection by a screen reader and should never end with a full stop (.).
Information about the ‘type’ of element (button, link, image etc) should never be included in the name. For example ‘Play’ should just be ‘Play’ not ‘Play button’ otherwise a screen reader will announce ‘Play button, button‘.
Type defines what an element is. For example a button, link, text field and so on. In HTML this is already predefined in the surrounding code and communicated by the screen reader. In Flash the type is already hard coded into the object you are naming. In iOS however it needs to be assigned by the developer as a ‘trait’: button, link, search field, static text, image etc.
A ‘tooltip’ is a description and should be used sparingly and only when the name does not adequately describe the outcome/purpose of the image. As descriptions are an explanation and not a command be careful to word them as such. For example a delete button should read “Deletes this event” rather than “Delete event”. You’re not suggesting a user should delete the item you’re simply explaining that the button will delete it. They’re a handy way of including screen reader specific instructions.
- Document all images used across your sites and share this across different development teams
- Assign a name to all images
- Where required assign a ‘type’
- Assign a description only if the image needs further explanation
I’m not a huge fan of skip links as a solution for screen reader users on desktop but agree wholeheartedly that visible ones are extremely helpful for sighted keyboard only users who, unlike screen reader users, are forced to tab through content in a linear fashion. The real value being that they are visible – which is why I think of them as anchored links rather than traditional skip links.
When browsing the mobile web keypad users share a similar experience to keyboard only users on desktop; you have to cycle through content in a linear fashion, often through many page elements before you get to what you want. This makes pages less usable, more expensive and creates significant barriers of access for users with poor dexterity.
To create better keypad access on mobile you want to minimise navigation at the top of the page whilst prioritising key content. This can be a tricky balance to reach and is where anchored links can help.
The BBC iPlayer site uses three skip links at the top of the page: Search, Channels and Categories which fall directly underneath the three links to the three main content areas of the site TV, Radio and Categories. It serves it’s purpose of separating the two sets of links into related navigation sections as well as removing ‘Search’ and it’s form field from valuable real estate at the top of the page whilst remaining accessible. Visually Search, Channels and Categories also have an arrow icon indicating that these links will open lower down the page.
- Prioritise key content at the top of the page
- Minimise navigation to what is essential
- Use visible anchored links for further navigation
- Add visual clues to anchored links to give users more context
See the Mobile Web Best Practices for more information about design for mobile and the relationship between Mobile Web Best Practices and the Web Content Accessibility Guidelines for an understanding of how mobile and accessible web design converge.
These are the smart, sassy woman who were my collective backbone over the last year. They’ve inspired me, supported me, educated me and most importantly laughed at me. If it hadn’t been for them I would have lost perspective on the odd occasion and probably hidden under a rock, instead, they rock.
In no particular order:
- Antonia Hyde – web designer, movie maker and one of the few precious people who can shed some light on how to build websites for people with learning disabilities.
- Kath Moonan – fiesty, creative, performer who champions inclusion in both her professional and private life focused on user testing with people with disabilities.
- Lisa Herrod – My partner in crime running the Web Standards Group International Liaison Group, specialist in web design and inclusion for people who are deaf and hard of hearing. Has a wardrobe to die for.
- Sally Cain - fellow Mum and colleague from years back who focuses on software accessibility and when it overlaps on the web.
I reckon this Fab Four pretty much have it sewn up between them. Thanks ladies x
BECTA, a UK government agency focusing on the use of technology throughout learning, recently invited me to contribute and article on mobile accessibility.
Grab a copy of the article in one of the following formats (sorry, no HTML):
Read this article in Belarussian translated by Patricia Clausnitzer