Accessibility

Disability app designed by London terrorism survivor

A severely injured survivor of the 7/7 bombings has created a smartphone app to help people with disabilities travel around London more easily.

Native iPad accessibility: is it enough?

I’m writing this on a shiny new iPad, having finally made the leap from laptop to tablet. I’m finding the experience generally wonderful & it’s certainly proving a much more comfortable and convenient way to navigate online spaces. I’ve yet to really get to grips with using the keyboard for any serious amounts of writing – touch typing is a while new learning curve – but I think practice will make perfect in the department.

One of the reasons I was keen to give this device a proper road test was to explore the accessibility features. I need to work up close a lot of the time and regularly use the built-in zoom tool on my desktop and notebook Macs. I also tend to vary the screen brightness depending on the task at hand and the lighting conditions. So seeing how I could adapt my iPad experience to make it as comfortable as I could was top of my priority list.

Being able to selectively zoom the whole screen using simple three finger gestures is great, and is a welcome complement to the two finger pinch-and-zoom functionality found in Mobile Safari. And being to invert the screen colours can be a helpful aid when contrast is making my reading or writing experience uncomfortable or tirimg.

Here’s an example to help you understand what I mean.

I’m currently writing this with the WordPress iPad app, which would ordinarily look like this:

The WordPress iPad app as it appears by default

I’ve tweaked the UI though, by switching to “White on black” through the accessibility settings – so my screen actually looks like this:

The WordPress iPad app, with the native "White on black" setting activated

It’s a simple, but really useful feature, which eases the strain on my eyes and makes for a more productive and comfortable experience. It’s not perfect though: the setting simply applies a filter to the whole screen to invert all colours. So although black on white, or greyscale interface elements like the keyboard translate well, the contrast of other UI elements is actually reduced. Just compare the “Save” and “Publish” buttons in the top of those previous screenshots for an example of what I mean.

These little quibbles are bearable when it’s just text-related content, but it becomes a very disorienting experience when it comes to using apps which feature more graphical and illustrative elements. Browsing my Twitter stream, as an example, shows everybody’s avatars in a strange, inverted x-ray fashion:

The iPad Twitter app, with the native "White on black" setting activated

Notice too that because the whole screen is inverted, the subdued dark background which frames the central stream is now hemmed in by two large zaps of light, which detract from the high contrast of the main content.

Page zooming is also great in many situations, but starts to have failings when it comes to creating content, as opposed to just consuming it. Using the WordPress app as an example again, the very clever screen zooming can start to prove cumbersome. The default text size in the app is pretty small, and can’t be changed. Ideally, I’d prefer to be able to zoom in on it while I type – look what happens though:

The WordPress iPad app using the native Zoom controls

Because the entire screen has been enlarged, the keyboard is now practically unusable. So, I just have to guess-type and proofread later on.

Of course, these are just restrictions of these particular assistive tools, and I’m trying to push them beyond what they were designed for. They’re assistive, and can’t be expected to fix the varied needs of different users for every application – one size doesn’t fit all.

But I think it does highlight the number of mainstream apps which are being developed without the consideration of simple, adaptive accessibility features.

Perhaps that’s because Apple have done such a good job of implementing OS-level accessibility: developers don’t see the need to worry about it, safe in the knowledge that at least a basic level of access will be baked right in. I also suspect that in some cases, it’s due to a certain amount of preciousness over pixel-perfect design treatments (and if you remember the terrible trend for pixel fonts on the web at the turn of the century, you’ll know just what kind of route to hell that can lead you down).

But I think it’s important for developers of these apps to consider extra features which allow users to adapt their experience to suit their particular needs or preferences. Simple things like allowing users to choose text sizes, change colour palettes, adjust white space and remove clutter are all simple and effective ways to allow more granular control, enabling the user to adapt their experience so that it’s more comfortable and enjoyable.

Twiiter for iPad is just one example of an app which could quite easily be improved in this respect. Twitter for iPhone allows me to change the font size for tweets throughout the app; but the iPad app is missing that feature, and I would really like to have it. It wouldn’t compromise the design of the app, but with that one simple feature, it would allow me to enhance my experience while using the app.

This post was prompted by the fact that I was considering a purchase of the iA’s Writer app, which is an absolutely awesome distraction-free writing application: simple, elegant and impeccably designed. But when I was trying to find out more about it, I noticed that all of the screenshots showed black text on a White background. I wanted to know if the app supported a setting for white text on black – I really don’t want to spend lengthy periods of time staring at so much whiteness.

Turns out that it doesn’t have that feature, but I bought it anyway because I can use the “white on black” setting built in to the OS – despite it’s annoyances.

But why not include that feature? Why should I have to use generic assistive features when more granular, app-specific settings would do a much better job? The lack of this kind of feature was almost a deal-breaker for me, but when I considered the alternatives, I decided that iA Writer was best-suited to my approach to working, even with the clunky white-on-black compromise.

But I think that summarises my point quite nicely: why compromise? Despite all of it’s little idiosyncrasies and faults, The iPad is a wonderful, enabling device. But I wonder if a lack of imagination amongst the developers of its apps might be stifling that enabling power for a huge number of people looking for a more assistive experience?

Notes

  1. I’m not singling out the iA Writer app for criticism here – I think it’s a wonderful application. I’m just using it as a real-world example of where I’ve had a desire for a feature which would improve my personal experience of their product. And the iA team were very forthcoming with feedback when I contacted them about it on Twitter.
  2. While writing this post, I found that the WordPress app was just too cumbersome and buggy for serious writing, and so switched over to using the iA Writer app in earnest instead. It proved a much more comfortable experience, and the default font size is just perfect for my needs: not too small, not too large. The distraction-free approach really does suit the iPad’s form factor and will prove to be particularly beneficial for many disabled users who are overwhelmed by the usual breed of text editors.
  3. As I’ve written previously, when considering accessibility features, it’s not just disabled users who benefit. Thinking of accessibility as something which only helps people with disabilities is very misguided.

Voiceover added to Apple TV

In another move towards improving accessibility for users of it’s technology, Apple are rolling out support for Voiceover with the latest 4.1 Apple TV software update. Macworld reports:

The other major feature added with the Apple TV 4.1 software is support for VoiceOver, or spoken menus. This feature can be enabled from the Accessibility submenu of the General menu under Settings. After enabling VoiceOver, the user can set the speed of the voice, from default (pretty fast) to very fast (John Moschitta territory) to slow (normal).

VoiceOver not only reads the name of the menu item you’re on, but it does a good job of reading metadata, including episode descriptions of TV shows. It definitely enables someone with vision problems to navigate through the Apple TV menu system.

I think it’s great that Apple are taking the time to include this kind of thing in their consumer products. Accessibility in most home entertainment systems is pretty lacking, and is something which desperately needs to improve. I personally hat having to negotiate text-heavy PVR menus and iPlayer services through the TV, and have been craving a more responsive way of navigating my media life for years.

Interesting that Boxee (the other potentially big player in the TV media box gadget arena, reviewed in detail by Jon Hicks), lacks any kind of accessible features. I find it interesting that accessibility is taken so seriously in the online space, but we don’t tend to think of it as being important in the world of entertainment. I think that’s going to change as more and more of our entertainment moves online, and interactivity becomes an increasingly important part of engaging with our media: excluded elements of society are going to become more prominent and vocal.

iPad Opens World to a Disabled Boy

An anecdotal little piece from The New York Times about the iPad as an enabling device for a young boy with a motor-neuron disease:

Owen, 7, does not have the strength to maneuver a computer mouse, but when a nurse propped her boyfriend’s iPad within reach in June, he did something his mother had never seen before.

He aimed his left pointer finger at an icon on the screen, touched it — just barely — and opened the application Gravitarium, which plays music as users create landscapes of stars on the screen. Over the years, Owen’s parents had tried several computerized communications contraptions to give him an escape from his disability, but the iPad was the first that worked on the first try.

There are also some interesting insights about the adoption of the device amongst different groups of disabled users:

For a mainstream technological device like the iPad to have been instantly embraced by the disabled is unusual. It is far more common for items designed for disabled people to be adapted for general use, like closed-captioning on televisions in gyms or GPS devices in cars that announce directions. Also, most mainstream devices do not come with built-ins like the iPad’s closed-captioning, magnification and audible readout functions — which were intended to keep it simple for all users, but also help disabled people.

End hover abuse now

Cennydd Bowles speaks out on the trend of using hover states in web interaction:

Designers who pop up information panels or move page elements on hover are using flawed logic, second-guessing what users want to do before they do it. The result, which I’ve seen in countless usability tests, is that users activate these controls accidentally. You know what happens? People actually flinch: “What was that?” They return with hesitation, less confident in their understanding of the site. It’s no accident that the Twitter worm propagated through hover— accidental activation meant users spread the worm unintentionally.

He makes a good point, particularly in a time when hover states are becoming a less reliable feature anyway, as the onset of touch devices makes hovering a non-entity.

Trent Walton has written a really useful and informative article about this subject:

As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.

The problem with magazines on the iPad

Peter Kafka writes about the problems with bulky magazine apps:

The Wired iPad app has a weight problem.

The first one came in at about half a gigabyte of memory, and it hasn’t shrunk that much since.

And Condé Nast’s newest iPad app, from the New Yorker, isn’t much better: It takes up 173 megabytes–but that’s for a weekly issue. If Condé can’t slim the app down, a month’s worth of New Yorkers will be much heavier than the first monthly Wired app.

Appears that this weight problem is down to their use of some horrible image-based reader software:

Both the New Yorker and Wired have the same weight problem for the same reason: They are built on the back of an Adobe (ADBE) program that essentially functions as an image reader.

That is, each page of the magazine is turned into the equivalent of several big photos. Which means an image-rich layout at Wired or a page of text at the New Yorker both consume a lot of memory.

Aside from the horribly inappropriate use of technology (displaying text as images is just dumb and inefficient), this is a horrible accessibility problem: it means that these magazine apps are pretty much unusable for many disabled users.

Once Adobe figures out how to break up HTML text into individual pages, McCarthy will make the switch, she says. Perhaps in a month.

There’s really no need to use HTML. And there’s really no need to have to compromise and use text scrolling. There’s a technology which allows for portable reading of rich media content, whilst maintaining precision layouts, and even maintains accessibility. It’s been around for a while.

It’s called PDF. It’s an open format, and it was created by Adobe. Duh.

Stylebot

Stylebot makes it stupidly easy to customise your web experience:

Stylebot is a Chrome extension that aims to simplify customizing the web, making it more accessible and adaptable. It puts you in control of the web’s presentation, allowing you to quickly change the appearance of any page.

A real coup for web accessibility and adaptability. Beautiful.

Flash is not a de facto standard technology

John Gruber continues to hammer home the reasons why Apple’s abandonment of Flash on mobile and touch devices is a good thing for web standards:

If no one releases a popular web browsing platform that lacks Flash support, then web sites that already publish Flash content are never going to move away from it. I think the web would be a far better place without Flash, or, at least, with Flash relegated to a position like that of Java applets: there if you want it, but not a major foundation.

Flash is never going to decrease in popularity so long as all web browsers support it. Flash might decrease in popularity because of iOS. If you believe that Flash’s current position as a de facto standard technology is harmful to the web, then users — not just iOS users but everyone using the web — would benefit if that happens.

I don’t think Flash is quite as evil as some commentators make out – it can be a powerful tool. But I agree that it needs to be repositioned: less as a standard web technology, and more as a bespoke application platform. So much of the stuff people use Flash for can now be achieved almost effortlessly with modern Javascript frameworks and clever use of CSS. I’ve yet to see a practical example of where Flash could be applied to applications on a mobile device.

Why Does Clean Markup Matter in Web Design?

Webdesigner Depot are on a roll at the moment, putting out some really useful and informative articles, covering some of the basics of good web practice. This latest article covers the practical, long-term benefits of using clean, maintainable  markup:

Mobile browsing is growing like Godzilla on atomic-steroids. Instead of being relegated to the jet-setting Blackberry addicts from 5 years ago, today everyone is using their phone to surf the web.

Assistive technology -screen readers for the blind and alternate interface devices for the handicapped- is common, and you don’t want to lose a sale or alienate traffic just because you didn’t take that into account.

Your site is likely to be translated into a half-dozen languages as readers from around the world find your content. Thanks to the Internet ArchiveGoogle’s cache and others, pages you publish today will be around for a long, long time even after they’ve been removed from your live site.

Clean markup and standards-compliance will go a long way to ensure your sites work in each of these scenarios.

Even if you’re a hardened web developer who knows your craft well, I think it’s always good to refresh your basic knowledge with articles like this: sometimes to reinforce your assertions and assumptions; and sometimes to pick up useful tidbits which have passed you by, or which you haven’t given much thought to.

Progressive Enhancement: Explained

Webdesigner Depot have a really well-written feature on the oft-misunderstood subject of progressive enhancement:

A lot of designers think progressive enhancement only benefits those users who are using outdated browsers, but other users benefit, too. Mobile browsers are the most likely to take full advantage of progressive enhancement. The reasons for this are two-fold. First, mobile browsers that don’t support CSS or JavaScript can still display the content of your site. While most modern smart phone browsers support at least one of those, not all browsers for basic cell phones do.

It’s worth reading the whole article, which includes some very clearly explained advice, including how to sell the benefits of progressive enhancement to clients:

When working on your own, personal website projects, progressive enhancement is something you can implement without a problem. When dealing with clients, however, it can get a bit trickier. A lot of clients are still stuck on the idea that their website needs to appear exactly the same in every browser they’ve ever used. Ever.

Explain the benefits of progressive enhancement to your clients. Tell them that it’s faster and less expensive for them to have you design the site with progressive enhancement in mind, and that their visitors likely won’t care either way, as long as the content is available.

It’s worth noting that progressive enhancement is not the same thing as graceful degradation. This article from A List Apart explains it best:

Progressive enhancement focuses on the content. Note the difference: I didn’t even mention browsers.

Content is the reason we create websites to begin with. Some sites disseminate it, some collect it, some request it, some manipulate it, and some even do all of the above, but they all require it. That’s what makes progressive enhancement a more appropriate paradigm. It’s why Yahoo! swiftly adopted it and used it to create their Graded Browser Support strategy.