Archive for the ‘Web’ Category

“Accessibility is not a right; it’s a feature”

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.

Let’s be excessive

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.

So let’s be excessive, and see where it leads us.

Adobe’s Flash roadmap

Interesting report on The Verge today about Adobe’s proposed roadmap for the Flash Player runtime:

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.

Seriously.js

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.

Is HTML5 causing confusion?

This .net article, follows up on a blog post written by Adrian Roselli in which he rallies against the continued use of HTML5 as a global term for modern web technologies.

On speaking to .net, Roselli said that HTML5 “as a brand versus the name of the version of a particular specification” already causes confusion, not only with clients but also developers. “I suffered through this with DHTML and Web 2.0, and those weren’t even real specifications. I expect to continue to deal with it with HTML5.” He told us that new developers may not even be taught the differences, partly because the educators themselves don’t know.” As these devs come into the workforce and get direction from clients or non-technical supervisors to lean on HTML5 for a project, they may not understand that the marketing term ‘HTML5′ is just the latest variation on ‘DHTML’ or ‘Web 2.0′ and presume they are being directed to use one specification. They may spend far too much time rebuilding capability in script, or perhaps just failing at trying to address it, when a related specification already exists.”

I kind of agree in theory — confusing technical specs with buzzwords can make life difficult for developers in all sorts of ways — but I think this is just a difficultly we’re going to have to live with. I don’t think it’s too difficult, when speaking about the technical aspects of web technologies like HTML5, CSS3 et al, to explicitly make clear that we’re concerning ourselves with the specification of those technologies.

I have conversations with decision-makers on a fairly regular basis, who band around the phrase “HTML5″ to communicate what they’re anticipating for a project, and that’s fine with me. When it comes to actually sitting down to spec a particular project though, that’s when individual technologies are defined and ratified.

In the original post, Adrian states:

I am repeating a request that when we who know better (developers, tech writers, robots named Frank) speak about discrete specifications, we refer to them as such.

I agree with this. But here’s a question: what umbrella term should we use for these specifications? Modern web technologies do represent a major sea-change in the way we’re approaching things, and I feel we need a catch-all term to refer to them, for both technical and non-technical people. Some developers might have hated the terms DHTML and Web 2.0, but at least they gave us a common language which could be understood across disciplines; you could “get” the gist of what was being talked about.

SoundCloud HTML5 Widget: ready for primetime

After months of testing, SoundCloud have announced that they are now making HTML5 the default for serving up their embeddable widgets. They’ve also added some great new features to it:

Today we are adding two major new features to our HTML5 widgets – Comments and Likes. This means that from now on you’re able to comment on sounds embedded anywhere on the web and you can save them as a favorite on SoundCloud too.

Also, we are proud to announce that today we are officially switching our default widget to be the HTML5 widget. We also know that our major partners plan to support it in the near future. Of course the old Flash widget will be still available if you need it as an alternative option.

This is great news for the ongoing rollout of HTML5 in the wild and is a great example of what the technology can be capable of. There’s still a Flash fallback too, so it’s not like moving to HTML5 means that any users are locked out.

The old print model just doesn’t work

In an article comparing the latest crop of paid-for newspaper apps, Rory Cellan-Jones picks up on what is lacking from a traditional approach to publishing on digital devices: He says of The Times iPad app:

What it does not do is take advantage of those things that online products can deliver which a paper cannot. Search, for instance, is absent – trying to find out whether today’s Times has an article on a particular subject means flicking through every section.

More seriously, the app is not a “live” newspaper – what you get each morning is the edition that went to bed about the time you did. Take today’s iPad Times for instance. There is a long article about Apple and the challenges it faces from rivals now that Steve Jobs is taking sick leave.

But not only does it quote a share price that is way out of date – the 6% fall at Tuesday’s NASDAQ opening – it also fails to mention the startlingly good results published at 2130 GMT on Tuesday evening.

This shows exactly why the old print model just doesn’t translate effectively to the digital world — modern-day journalism needs to be responsive; be more relevant.

News groups appear to be groping in the dark, unsure of what readers want from an app.

What readers want from an app is what readers have been getting from the web: searchable, relevant, up-to-date journalism and content. But they want that experience to be enhanced through the use of intelligent, intuitive design which digital devices can provide.

Publishers aren’t learning from the web

Oliver Bothwell ponders the current state of publication apps on tablets, concluding that publishers just aren’t learning lessons from the web:

And now it is quite easy to see why the media apps are failing. They are all difficult to navigate requiring too many swipes, flicks and scrolls to find things. Eureka has a lovely opening navigation and the magazines have contents pages but where are the search bars? Have they learnt nothing from the web? Where are the related articles, tags and comments. They are not taking advantage of the fundamental tools available to them. Instead they are creating gimmicky apps without any real substance. Media companies are changing but without realising what is their best asset, their quality journalism and ability to edit, which they sacrifice to fads and pointless interactive content. Newspaper and magazine sales are down because the internet allows easy consumption and access to lots of information; the only way to start making money is by championing this in their apps and combining with excellent user-interface and editorial design. At the moment there isn’t an app which is better to use than the newspaper or website equivalent and this should be worrying to an ailing industry. The approach is entirely wrong; it is not the content that is the problem, it’s the way it’s being presented.

I’ve, personally, yet to find a media app which feels “right” — even the very popular and innovative Flipboard doesn’t fit the bill, for the may of the reasons that Oliver flags up: too many swipes, no way to effectively filter and search.