The personal weblog of Phil Powell

A lovely little article from the Verge about the videos created by a young boy who has cerebral palsy:

This is Christopher Hills. He’s an Apple fan. He also has cerebral palsy, and as you’ll see in the first video below, he can’t control his muscles easily. The incredible thing about Christopher, though, is despite that, he edited these three videos himself. Not unlike Stephen Hawking, he uses a single button to manipulate his computer, which he presses with his head, connected to a device called a Discover Switch.

As well as being very inspiring and life-affirming, these videos also highlight the fact that with the appropriate assistive technology and software which is accessible, wonderful things can be created by people who are severely disabled. Remember, this is a kid who uses a single switch to work with a video editing application: technology proving to be truly empowering.

This .net opinion piece by Drew Neil is the most disappointing thing I’ve read about web accessibility in a while. The central argument is based around the idea of abandoning progressive enhancement to advance the evolution of modern web apps. I’m not opposed to exploring alternative development models to build online apps — after all, web apps can be very different beasts from a traditional web sites — but Drew takes it a step too far:

The web is composed of documents, mostly the written word. Accessibility comes practically for free, but only because of the intrinsic nature of text, and the accessibility features of the software with which we consume it. Since text documents are so readily accessible, we’ve come to think that everything else should be too.

Applications and documents are different. Accessibility is not a right; it’s a feature. The first features to be implemented are the ones that define an application and determine its success.

“Accessibility is not a right”.

Really? Are we still thinking like this?

I’ve watched the web community spend years working for good standards and improved access for people with disabilities, and when I read this kind of thing it really disappoints me.

Javascript and all sorts of other emerging web technologies can work so well in tandem with progressive enhancement, providing granular and selective control over content and features for different display and input devices. Not everything needs to be implemented, not everything needs to work the same. But by excluding accessibility as a feature entirely, you exclude the people who rely on accessibility standards and progressive enhancement to navigate the online world

By taking the view that accessibility is just a feature, you’re saying that people with disabilities are just not important. In my view that’s a very dangerous standpoint.

Web accessibility can be a thorny subject. It’s a subject which can court controversy and inflame conversations about even the most mundane of web topics. It’s understandable: accessibility is ingrained in so much of what we do on the web, and it can be interpreted and applied in a myriad of different ways.

So it’s with more than just a little trepidation that I’m writing this article, for fear of inciting the wrath of the Accessibility Gods with what, to some, might read as outright heresy. But here goes:

I believe that there is a case to be made for changing the way we look at web accessibility. I believe that we should stop viewing it purely as a standardised necessity; a functional requirement. Instead, I passionately believe that we should be treating it as a valuable part of our toolset, which has the potential to act as a catalyst for new and exciting ways for developing online experiences.

Before we delve into that though, I think it’s worth taking a little retrospective look at where we’ve come from, and how web accessibility has evolved.

In The Beginning

In the early days, there wasn’t much of a need to think too deeply about accessibility. The early inception of the Web comprised mainly of simply-structured text documents, which were accessible by their very nature. The web was conceived as a network of inter-connected documents, and those documents were generally well-structured.

But when HTML started hitting the mainstream, along with lots of shiny new embellishments — images, rich media, CSS and all sorts of browser plugins — that semantic purity started to become diluted. The web started to become a fairly messy, inaccessible place. Popular WYSIWYG editors like Frontpage and Dreamweaver only added to the woes, as they belched out invalid and badly-formed markup.

How degrading

While this situation was being exacerbated by our clients insisting on the use of bad practices such as cramming SEO keywords into our alt tags, we set about creating new ways to develop based on the idea of fault tolerance: graceful degradation.

With the rise of Flash as a mainstream web technology, we began to extrapolate the idea that not all web users were using the same technology; not all web users could access our pretty web sites in the same way. So we created HTML versions of Flash websites, text-only versions of image-heavy websites, pared down fallbacks which offered a simplified experiences.

I was always uncomfortable with this idea of degradation: by making the assumption that something might fail, it somehow meant it was okay if things went wrong. But more importantly, it meant that accessibility was treated as a low priority; a special case which would be dealt with if and when we got time.

A more progressive approach

Luckily, we soon realised that this degrading approach was a topsy-turvy way of going about things, and progressive enhancement came to the fore as a driving force in our approach to developing the modern web. It’s become the widely accepted way we implement shiny new CSS3 features, embrace semantic content and take advantage of ever-improving browser functionality. It forms the very foundations of modern methods for creating accessible, responsive web design.

We no longer need to worry about the constraints of browsers or users because we are building solid core functionality with well-structured content at it’s heart, then layering on extra features to create a fuller, richer experience in the knowledge that we are only ever adding to our users experience, never detracting from it.

This is A Very Good thing for accessibility. Well-formed, semantic content is at the heart of everything we build, with accessibility effectively baked right in. As long as we’re careful to make sure that each layer of enhancement doesn’t cause anybody’s experience to falter, we’re crafting a better online experience for everybody.

We’re in good shape

Universal access to the online world is in pretty good shape right now — compared to ten years ago it’s a relative utopia. Most designers and developers have become switched on to the advantages of this approach, and with the wider adoption of good standards and modern browsers, it’s only going to get better. We finally “get” accessibility.

Or do we? Have we started to rest on our laurels? Those text-only sites we used to build to cater for accessibility? We thought they were good enough, right?

Can we do better?

It’s all too easy for us to make assumptions when we’re dealing with accessibility. That, I think, is why there tends to be a lot of heated debate around the subject. It’s a complex, nuanced subject — but much of the time the opinions I read or hear are based on well-intentioned idealism, rather than real-world experience.

We tend to bake our accessible features based on assumptions, rather than experience. Imagine you were baking a cake: first you work out the ingredients and their quantities, and mix them together. Then you bake it in an oven, at an appropriate temperature and for the time needed to make it rise. You may even do a little testing with a knife to make sure it’s cooked right through.

But imagine if you never taste that cake. You assume that the ingredients you’ve mixed will work together, but you have no idea if it’s too sweet, too bland, too dry, too crumbly. If you never taste it, if you never experience it, you’ll keep to the same recipe time after time; never improving, never tweaking or evolving your recipe to make it better.

If we only assume that we’re baking our accessibility well, how can we be certain that the fruits of our endeavours are palatable to those who have to consume it? We can look at most elements of good experience design with a subjective appreciation, which is founded in our inherent understanding of what works, backed up by a knowledge of good practice and sound theory. We can “tell” when something doesn’t work.

But when it comes to creating good experience design which is also accessible, it’s far more difficult to take a subjective approach. Often it’s the case that instead of making informed and engaged decisions about points of accessibility, we take an objective approach which effectively constitutes a checklist: alternative text: check; unobtrusive JavaScript: check; “skip navigation” links: check. We’ve become very adept at implementing the common techniques we’ve learned and honed; have become very comfortable applying standards and best practices. I would argue though, that we’ve become a little too comfortable.

Providing a good experience for disabled users is mostly treated on a par with the experience we provide for mechanical search engines — it’s a necessity, but we don’t tend to put much creative thought into it. To me, this is entirely unimaginative; it’s unexciting, uninspiring, and most disappointingly of all: in a cutting-edge industry, lacks innovation.

I believe that it’s time to put an end to this complacency. I believe that good web design can be an empowering aid to those of our society who are less able — physically, mentally or socially. I think we need to move beyond just doing what we need to do, move on from thinking progressively, and start to think about doing things excessively.

Excessive enhancement

All of the things we currently do to aid accessibility form the backbone of good practice, and are here to stay. As developers, we need to continue creating well-formed and hinted markup so that people using assistive devices such as screen readers can access our content. As designers, we need to continue to create progressive, easy-to-navigate interfaces, which use clear and responsive visual languages. As content strategists we need to continue using clear, descriptive language and find better ways to express rich media in alternative ways.

But let’s move beyond the status quo and start to explore innovative approaches to accessible design: new ways of creating markup which is adaptable to a user’s circumstances; design interfaces which can be even more responsive and intelligent; create content for an experience which is relevant to a user’s needs.

This doesn’t mean that we should start to cram more features into our work. The best design is, generally speaking, simple design, and good accessibility benefits from this notion of simplicity — removing obstacles, condensing complex processes and making them intuitive: these are all accessibility gains.

But perhaps we often tend to take this simplicity too literally: for something to be accessible, it must be basic, linear; we must avoid rich, immersive interactivity.

But rich interactivity can be an incredibly powerful and enabling force, particularly for people who are disabled. The new breed of touch devices is a perfect example of where a new paradigm in the approach to interface design has become an incredibly empowering tool for those who have struggled with a traditional mouse and keyboard. It seems these cutting-edge devices are incredibly accessible. (Bear in mind though, that the use of gesture-based interfaces throw up accessibility challenges of their own, a sign that we still have some way to go).

But are we avoiding the use of modern, cutting-edge web technologies when we create rich experiences for disabled users?

Conventional wisdom seems to dictate that when it comes to accessibility, JavaScript is A Bad Thing. I think that assumption is out-dated. JavaScript has become an incredibly powerful and adaptable technology — it can add subtle elements of interaction, manipulate content in extraordinary ways; it even powers entire, sophisticated applications. But because these kinds of modern technologies are generally treated as progressive enhancements, layered on top of our accessible foundations, the opportunities for applying them to an accessible experience are seldom explored.

There is no reason why JavaScript and emerging CSS3 techniques can’t be harnessed to create more universally accessible experiences for our users.

It’s time we started thinking about accessibility in a multi-layered way; to make it a more integral part of the progressive enhancement model. And just as modern responsive design embraces the idea that “not all users will have the same experience”, our modern approach to accessibility should embrace the idea that “not all users want the same experience”.

We’re accessing the web in so many different ways, through so many different devices and applications, and responsive design is becoming an ever-more prevalent discipline. Our content is being manipulated and moulded to suit our chosen means of consumption, and this, I believe is where accessibility is destined to hit the mainstream.

I call this notion “adaptive accessibility”: providing ways in which people of varying abilities can adapt their experience to best suit their particular needs.

We’re already doing it

We’re already moving in that direction. Services like Readability and Apple’s Safari Reader are tools which strip core content from a web page and display it in a clean, elegant and comfortable format. It’s a simple concept, and nothing particularly new — I like to think of it as RSS in the browser — but the elegant, universal way it can be applied is what makes it an absolute win for accessibility: enabling users to adapt their experience to suit their preferences.

Another example: remember when theme switchers were all the rage? They don’t tend to be so prevalent now, but the ability to change contrast and colour schemes is a feature which can benefit so many different people: people with autism, visual impairments, colour-blindness, dyslexia.

These are simple examples, and they barely even begin to cover the broad gamut of users needs. But they are simple concepts done elegantly, which give an indication of the power we wield, and the potential we have for exploring the creation of richer, more accessible experiences.

And there’s an important distinction to be made between our traditional approach to accessibility and this more adaptive approach. It isn’t intended to be used solely by people with disabilities; it’s not something which is switched on or enabled in special cases — it’s there to be used by everybody, regardless of ability. We often preach the idea that accessibility considerations can benefit perfectly able web users — so let’s embrace that idea: let’s create more adaptive web experiences which are beautifully designed for the benefit of everyone.

Making it personal

Now, this article isn’t intended as criticism — far from it. The vast majority of web practitioners are doing an exceptionally good job implementing and advocating good standards and accessibility in their work, and we should applaude ourselves for the progress we’ve made in making the web a more accessible place. Accessibility has become an important, integrated part of our everyday work, which is a wonderful thing.

But as I’ve already mentioned: I think we’re often prone to making assumptions about issues of accessibility. We work in an industry founded on innovation, where we’re often forging new ideas in an unknown future. To question our common, well-founded assumptions might prove disruptive, but when it comes to accessibility, I think it’s high time we faced our assumptions head on.

Most often, when we’re talking about accessibility, it’s in the context of helping people with disabilities. We tend to think of people with disabilities as a minority and place them into generalised fringe groups: people who are blind, deaf, who have learning difficulties, who use a wheelchair.

The reality is that every individual’s disability can be far more complex, far more subtle, changeable and variable. We ought not to place people into stereotyped categories and assume one-size-fits-all solutions. Different people need help in different ways, and it’s usually the case that they are much better at making decisions about what fits them best — adapting their world to suit their needs.

So, how can we be making broad assumptions about the right way to do accessibility, if we don’t take inspiration and learning from the very people who benefit from it? I’m not talking about “use cases” or “case studies” or recommendations like WCAG; nor am I talking about simply theorising. I’m talking about engaging with and leveraging the knowledge, ideas and experience of people who are the prime beneficiaries of better access to the web.

After all, that’s what equality for disabled people is all about: it’s not about making concessions, it’s not simply about safeguarding against discrimination — it’s about empowering people to participate fully in society.

I suggest we open up our little web design society a little more, and invoke more inclusive participation. Because a more inclusive, diverse and informed community generally results in a more progressive environment from which we all benefit.

Last July, the National Federation of the Blind (NFB)at its summer convention proposed a resolution “condemning and deploring” Apple for the sin of not requiring that everything sold in its app store be fully accessible. The NFB proposed a second resolution that said it was “frustrated” and “disappointed” with Apple’s not including accessibility requirements for its app store. The second resolution passed. While I agree that having such a requirement would be nice, Apple has done vastly more than its operating system rivals Google, Microsoft and all flavors of GNU/Linux to promote accessibility. Also, Google and Microsoft have their own app stores with no requirements for accessibility either.

Before I launch into the politics that seem to have led to the NFB resolution, I will provide a few examples that demonstrate Apple’s overwhelming lead in providing systems accessible to people with vision impairment. Since introducing VoiceOver, the utility people with print impairments use to hear the contents of the screen spoken or sent to a refreshable braille display, Apple has sold 100 million devices that are accessible to this community. Additionally, every product in an Apple retail store that has a user interface includes VoiceOver. A blind person can go to an Apple store and try out everything they sell except the iPod Classic which hasn’t had a software revision in a really long time. I can use any Macintosh, iPhone, iPod Nano, iPod Shuffle, iPod Touch and more sold in the past few years without installing any extra software. Meanwhile, I would need to spend nearly $1000 extra to use Windows on a “standard” computer if I want to use the most popular screen access utility for that platform. Android from Google includes a screen access tool called “TalkBack” which is, in my educated opinion, years behind the out-of-the-box experience provided by Apple and the costly add-ons required by Windows.

This is one of the things which many people overlook with Apple’s operating system: the built-in accessibility features are years ahead of any other OS vendor, and are available out of the box. It’s a perfect example of the adaptive accessibility model I keep banging on about: a rich set of features, which are available to use by anybody, regardless of their ability. So I get quite disheartened when I read about Apple being slammed for poor accessibility.

The crux of the situation is best summed up by Chris’ comment:

While slamming Apple at their annual convention, they celebrated Google with lots of presentation slots for their Android system. As I wrote above, Android accessibility is poor at best but NFB probably got a fat contribution from Google and, as any advocate knows, money talks, accessibility walks.

iPhones and iPads are the easiest systems to make accessible in the history of computing. iOS, moreover, is the funnest accessible development environment there ever was. You’ll have a whale of a time testing this shit out. VoiceOver, like an Oscar Pistorius prosthesis, is actually cool.

But if you can’t make it happen in the first place, you suck as a developer.

Accessibility seems to be getting sidelined when it comes to creating apps, and it’s a worrying trend.

Future bug fixes and developments will be prioritized around two key areas: gaming and the deployment of so-called premium video. Relying on its nearly universal distribution, Adobe hopes to see Flash maintain its position as a leader in browser-based games (something that Google is actively challenging with its Chrome Native Client development kit), and will seek to support its developers with a formalized game dev program and a set of unspecified game services.

I can’t quite see how this is going to play out well for Adobe in long-term, considering that so much browser gaming is likely to be played on mobile/tablet devices — which is the one space where Flash can’t reach.

On the video side of things, Adobe pledges closer collaboration with hardware partners and the delivery of its content streaming and content protection technology to more platforms in native formats.

In short, this means Adobe are forging closer links with Intel and online streaming services like Netflix, Lovefilm etc. Problem with that is that Intel are at serious risk of losing massive market share to ARM-like technologies and the TV ecosystem (whatever that’s going to look like in the next few years), and again: ARM and TV are the two places where Flash doesn’t fit well.

Nobody knows if Flash will even be supported on Windows 8 — if that doesn’t happen, then surely Flash will be pretty much dead in the water.

With a highly accessible interface, Nomensa’s media player can be used by people with disabilities, even when they don’t use a mouse. The simple design also makes it easy for everyone to access multimedia content on the web.

Nomensa’s media player brings together the best of new and trusted technologies. The option to switch between HTML5 and Flash mean the player can be used across all platforms, including Apple’s iDevice range.

Nomensa believe that technology is a tool that everyone has the right to share and use. Nomensa’s humanised media player encapsulates this philosophy, making it possible for everyone to access multimedia technology. It really is humanising technology at its best.

Good move! It’s a pretty powerful and useful bit of kit, which you can find on github:

The Nomensa accessible media player is a flexible multimedia solution for websites and intranets. The core player consists of JavaScript wrapper responsible for generating an accessible HTML toolbar for interacting with a media player of your choice. We currently provide support for YouTube (default), Vimeo and JWPlayer although it should be possible to integrate the player with almost any media player on the web (provided a JavaScript api for the player in question is available).

Seriously.js is a real-time, node-based video compositor for the web. Inspired by professional software such as After Effects and Nuke, Seriously.js renders high-quality video effects, but allows them to be dynamic and interactive.