Sep 2nd, 2011 by Henny
I’ve been concerned that there’s been a lot of talk around Mobile Safari supporting WAI ARIA but there’s little documentation out there confirming what is and isn’t supported so I thought I’d run a few basic tests with Mobile Safari on iPhone 4 and iPad 1 to see what’s what. Continue Reading »
Aug 18th, 2011 by Henny
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 »
Aug 3rd, 2011 by Henny
I’ve been playing around with ways of expanding abbreviated text on mobile using both <abbr> and <span> specifically to see how well supported voice output is. I ran a few mobile browsers and voice output software over a test case for abbr and span listing abbreviated days of the week using <abbr>, <span> and as is (i.e. Mon, Tue etc).
The results in the table below lists what is ‘spoken’ by each browser / voice output pairing:
| Mobile Safari / iOS VoiceOver | Opera Mini / iOS VoiceOver | Opera Mini / Android / Talkback | Android/ Talkback | Android/ IDEAL Web Reader | Nokia/ Talks | |
|---|---|---|---|---|---|---|
| Uncoded | Monday, Tuesday, Wed, Thursday, Friday, Sat, Sun | NA | NA | NA | Mon, Tue, Wed, Thu, Fri, Sat, Sun | Mon, Tuesday, Wed, Thursday, Friday, Sat, Sun |
| ABBR | Monday, Tuesday, Wed, Thursday, Friday, Sat, Sun | NA | NA | NA | Mon, Tue, Wed, Thu, Fri, Sat, Sun | Mon, Tuesday, Wed, Thursday, Friday, Sat, Sun |
| Span | Monday, Tuesday, Wed, Thursday, Friday, Sat, Sun | NA | NA | NA | Mon, day, Tuesday, sday, Wed, nesday, Thursday, rsday, Friday, day, Sat, urday, Sun, day | Mon, day, Tuesday, sday, Wed, nesday, Thursday, rsday, Friday, day, Sat, urday, Sun, day |
Note: Android’s browser and Talkback (from the Google EyesFree Project run by TV Raman) still don’t support ‘web view’ so was not included in the test case. Equally, Opera Mini does not support speech output either on iOS with VoiceOver or Android with Talkback so was not included. I will revisit this if things change. The IDEAL Web Reader is a self voicing browser available for free on in the Android Market place.
If looking for a solution that works seamlessly across desktop and mobile browsers it looks like <abbr> and <span> is not it. What works best for screen readers on desktop browsers is <span> however this seems to have the worst support on mobile.
At least two screen reader users (@blindgeek and @kirankaja12) have mentioned that TTS expanding text can be quite annoying, presumably because it gets things wrong and confused. As a developer I’m not sure there is much that can be done about it especially given it can not be over ridden with <abbr> or <span>. The best advice is to avoid abbreviations where possible and keep written text plain and simple on mobile,
Jun 22nd, 2011 by Henny
Establishing a mobile accessibility strategy can be a bit daunting. It’s tough to know where to start and even tougher to know where to stop: what devices should be supported, browsers, apps, access technology, who is it for and how teams can incorporate best practices into their working practices?
The goal is to make the web both portable and accessible but it’s a challenge marrying the ideal with the realistic in the vast, agile and diverse space that is ‘mobile’. Here’s a handful of some of the issues that have come up for discussion when developing portable, accessible content and how they are helping me shape a mobile accessibility strategy I’ve been working on. Needless to say this is very much a work in progress…
The mobile context is by definition disabling. Mobile doesn’t lend itself to easy browsing when you’re on the move, dealing with poor light, glare, small screens, old hardware and small keyboards. As well as taking context into account developers also need to consider variable support for web technologies (HTML, CSS, JavaScript etc) within different mobile browsers and platforms. There are a daunting amount of variables that impact on how we access mobile content including:
While mobile accessibility is all of the above for the purposes of this blog post, mobile accessibility is making web content accessible to people with disabilities in the mobile context. This includes users with visual, mobility, hearing and cognitive impairments as well as older users.
When developing on desktop we need to take into account 5 major browsers (Chrome, FireFox, Internet Explorer, Opera and Safari) and 3 operating systems (Apple, Linux and Windows). While this can be painful it’s not nearly as daunting as the mobile context where we have many, many more browsers and operating systems not to mention handsets (that can impact on how well styles are supported) and screen sizes. The mobile market is also more unsettled and subject to change as new releases come onto the market all the time.
It can be incredibly hard to know where to start and what devices to support. The harsh reality is you can’t build, test and deploy to every device out there guaranteeing a fully accessible experience. There are simply too many variables and too many unknowns.
So how do you decide what devices to support?
Running through the above check list I found the following themes:
While we compiled a list of devices we decided the requirement should be to build and test against a set of general mobile accessibility guidance and develop device specific guidance. By integrating this into our development process we hope to widen the support considerably beyond our list of supported devices even if we initially test on only a few.
There is no formal equivalent of the Web Content accessibility Guidelines (WCAG) for mobile however there are general Mobile Web Best Practices Guidelines (MWBP). Given the mobile context is inherently disabling there is is a significant cross over between the two, so much so there is a mapping between WCAG and MWBP.
This is a good place to start however it’s not practical to refer developers, content editors, interaction designers and testers to two documents that cross reference each other. What’s more there are also device specific guidelines which reference accessibility (for example Apple, Android, Nokia and Blackberry) all of which are relevant but taken as a whole not easily digestible or practical.
So what is the best strategy?
Establishing a set of core mobile accessibility guidelines internally is a good place to start. These should list all guidelines that are relevant to mobile content regardless of the platform or device with a baseline of technology support (HTML, CSS, JavaScript etc) decided in accordance with the least advanced device in your list of supported devices. These general guidelines can then be supplemented with device specific guidance where necessary.
How general mobile guidelines are presented is a million dollar question but I prefer to break them down according to roles within a team:
There is of course a cross over between roles but the ultimate responsibility has to stop somewhere. Go on, be brave.
Writing a core set of mobile only accessibility guidelines is a lot of work and time will tell if in fact it is the best strategy. As previously mentioned there is also a significant overlap with WCAG. I think it’s a really, really useful process to go through but I’m simultaneously asking myself if we even need seperate mobile and desktop web accessibility guidelines. Surely a baseline shared set of guidelines could work? WCAG is after all ‘technology agnostic’ (i.e. HTML, CSS, JavaScript, Flash etc). Could we take the same approach and have a core set of accessibility guidelines that are both technology and device agnostic?
The idea of agnostic guidelines is possibly a little over simplistic in a wolrd where we have to contend with websites and web apps as well as platforms and devices but I can’t help coming back to the knowledge that the principles of designing for the mobile web have a lot in common with designing for the desktop web and are, most importantly, shared.
Time will tell as to what approach is best but the key is being realistic in what platforms/ devices you can support, understanding your users and supporting your development teams.
Having teams communicate with one another is also essential. Just because you have separate teams working on desktop content, Android and iPad apps it doesn’t mean they can’t share the same content strategy. Details such as using consistent text alternatives across desktop and mobile cut down development time and vastly improve the user experience when accessing the same content from desktop, phone and tablet.
I’d be interested to hear from anyone else going through the same process or if you have any thoughts on if there should be a base set of accessibility guidelines for all web content or not.
Jun 17th, 2011 by Henny
The good folk at Environments for Humans are running the second one-day, Accessibility Summit September 27th from 9AM to 5PM (CT). And the best thing about it? The conference comes to you, live and direct, as it’s all online.
I’ve been lucky enough to be invited to speak about Integrating Accessibility Across Devices alongside some pretty inspiring people such as Glenda Sims, Derek Featherstone, Jared Smith, Anitra Pavka, David Berman, Jason Kiss and Matt May. So if you want to find out more about HTML5, ARIA, colour, accessibility and Star Wars then snag yourself a 20% discounted ticket using the discount code 20SWAN.
Just in case you can’t make the date, or think you may be asleep for half of it, you can watch the recordings whenever you want afterwards.
Bargain.
Jun 15th, 2011 by Henny
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.
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:
| Image | Name | Type | Tooltip | Delivery | Note |
|---|---|---|---|---|---|
 |
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.
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.
| Name | Type | Tooltip | |
|---|---|---|---|
| Web | alt=”xx” | Automatically assigned | title=”xx” |
| iOS | Label | Trait | Hint |
| Android | android:contentDescription | Event | |
| Flash | Name | Automatically assigned | Description |
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.