Archive for the ‘Web’ Category

How disability made me more productive

Next month, I’ll be speaking at the Dare Conference in London. It’s a new event, which features some amazing presentations from some incredibly talented people. I’ve spoken at a few events in the past, but never anything as exciting or important as this, so I’m just a little bit scared, particularly as I’ll be presenting on a particularly personal subject.

The conference is being attended by people from all around the world, with representatives from some big organisations. Which makes me both nervous and excited about what I’ll be able to bring to the event during my twenty-five minutes on stage. I’ve been procrastinating and re-drafting this talk for months now, but this month I need to get it all finished up, rehearsed and refined.

So what will I be talking about? My presentation is titled “How disability made me more productive“. Pretty ambiguous, eh? The description gives a little more detail:

I’m a developer and designer with ocular albinism. When I became registered as disabled in 2008, it made me reconsider almost everything about the way I live my life. Admitting to myself that I had a disability was one of the toughest things I’ve ever done. But over time it’s also been liberating. By covering up my disability, I was making life more difficult for myself. By being honest and open about my weaknesses, I’ve found the freedom to be more creative, more pragmatic, and to participate more effectively.

I’m very self-conscious of the fact that I don’t want my presentation to be too self-indulgent — it could be all to easy to play the “poor me” card and talk about how difficult life can be. Instead, I intend to talk about the psychological and social aspects of having a disability, and how “being different” can, in fact, be a very good thing. I intend to break down many of the misconceptions of what it means to live with a disability, and to impress upon people how important it is to look at disability as a problem of society itself, not of the individual.

Secondly, I’ll be talking about how I’ve learned to be more open and honest with myself and — more importantly — with others about my weaknesses, and how I learned to turn them into strengths. There are constant challenges to this though, and I want to show how creating a more inclusive environment can help people to be more creative and productive, regardless of ability. We live in a competitive, fast-moving world — sometimes we need to handicap ourselves a little, to create a more level playing field. If we’re racing ahead all the time, and don’t give others the opportunity to catch up, then they might not be able or willing to contribute effectively — in work, or in life in general.

Most importantly of all though, I hope that people will go away from my talk with a slightly different view of the world: a better appreciation of the fact that we’re not all the same, that we all have different strengths and different weaknesses, and that is a very good thing; that by being more adaptive to an individual’s needs and abilities, you can inspire the very best in them. In short: be more inclusive. I don’t think we do enough of that right now. I certainly don’t feel like I live in a very inclusive world, and so I intend to start doing something about it.

It’s coincidental that presenting this talk has coincided with my new role as CTO with an organisation which is setting out to enable people to live a more independent life through the use of technology. If I get time, I’ll also be talking about how we’re starting to look at ways to use emerging technologies in unconventional ways, to allow less-able, elderly and vulnerable people to live a more inclusive and fulfilling life. Some of the things we’re talking about in R&D are getting me very excited.

The Dare Conference is taking place 23rd-25th September, and you can get a whooping £200 off a conference pass by using the discount code SPEAKER13. There’s also a special freelancer rate, which gets you in for just £299+VAT. The organisers have also put together one of those “Convince your boss” wotsits, if you need to persuade the powers that be.

Say hello to Jousey Gifts & Gadgets

At the start of the year, we started to develop ideas for an e-commerce business. For years I’ve worked on websites and commerce solutions for other businesses, both big and small. But I’ve always been playing to someone else’s tune; developing things around someone else’s business objectives and aesthetics.

So, when Jo came up with the idea for a boutique online gift store, we started to put the wheels into motion for creating something different, taking everything we know about online commerce, and moulding it into something of quality and substance.

We’re on a long journey with this project — that’s a long way to go — but last week we hit our first big milestone, with the soft launch of Jousey, a place to buy unique gifts and gadgets. The first iteration of the design has been carefully crafted to make simple and intuitive to use, but with a fresh, vibrant feel which we think breaks the mould of boring online stores.

We’re curating big, bold and beautiful product imagery to complement the choice products we’re stocking. And since we’re all doing more and more browsing on our mobile devices these days, we’ve crafted the site to adapt and look just as beautiful on phones and tablets. There are lots of updates and new features in the works over the coming months, and it’s great to have the opportunity to be working on a growing, evolving design for a change.

We’ll be having a proper press launch next month, and you can keep up-to-date with all of our adventures into selling the very best, hand-picked gifts at the site’s blog.

“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.