Showing posts with label accessibility. Show all posts
Showing posts with label accessibility. Show all posts

Sunday, 13 April 2014

Review: Adaptive web design

Adaptive web design by Aaron Gustafson is a good book on an important topic. How the web evolves, and how it caters to the broad spectrum of its users, that now make up the majority of the population in affluence societies, is a crucial consideration.

The book is a curious mixture of tips, philosophy and polemic. Gustafason includes specific technical detail, for example microformats, structuring CSS selectors and ARIA roles.

He also treats progressive enhancement as a moral issue, which is both a reasonable point of view and a rhetorical device. For example, he describes the technique of graceful degradation as "fault tolerance's superficial, image-obsessed sister" and that eventually "smart folks working on the web began to realize that graceful degradation's emphasis". He thus frames issues in a way as to try and ensure the reader's conclusion cannot be anything other than agreement, which is a time-honoured technique of polemic.

This book is a good overview of a topic that can fade into the background under the pressure of deadlines and corporate disregard for users, so it's great that Gustafason has put his energy into a book that software developers can rally around.

However it has two serious flaws, one of omission and one of commission, that make it less useful to a contemporary software team than it otherwise might have been.

The flaw of omission is that it does not engage with the recent crop of client-side MVC applications. Adaptive web design was published in 2011, two years after the release of Google's framework AngularJS, but it contains no mention of this style of application development, which challenges some of the fundamental assumptions of the progressive enhancement movement.

Client-side MVC is, literally speaking, progressive enhancement, but it's not of the sort that Gustafason lionises. These applications, usually constructed with the help of extensive JavaScript frameworks, place rich interactivity on top of APIs, where as traditional progressive enhancement layers unobtrusive interactivity on top of HTML.

The major difference with Gustafason's vision is that the HTML comes on top of the JavaScript rather than the other way around. Data is pulled into the browser by Ajax calls, before being rendered using client-side templating engines directly into the DOM. This allows the application to keep a model of the application's state and rules in the browser, and to update that model and apply those rules in the interests of a rich experience without the latency of calls back to the server.

I don't know how such applications should be regarded. They don't, for example, allow users to access content if JavaScript is unavailable. This may or may not have the same urgency as it did when Adaptive web design was written three years ago, but in this book at least, Gustafason is unable to give us guidance.

That substantially diminishes the relevance of this book, as the most pressing question most contemporary teams will have about progressive enhancement is how it relates to the major movement in the JavaScript world towards client-side applications.

The flaw of commission, that makes it difficult to treat Adaptive web design as even a point-in-time reference, is the way that Gustafason uses definitions and terminology.

One such example is the term "accessibility". Gustafason takes the perfectly reasonable view that accessibility is a broader issue than simply people who use assistive technologies. The problem with this definition is that it's incompatible with the common usage of the term.

Interestingly, this is an example of a failure of progressive enhancement of language itself. Specialising normal language into terms of art allows the common punter to at least get the gist of what's being discussed. Expanding the definition of terms is much more confusing, because it leads to sentences where the word simply does not make sense under its old definition.

But all this is bunk when we get to the "Accessibility" chapter itself, where Gustafason reverts to the classic idea of accessibility being about people with physical needs that might impede them from accessing content. I guess Gustafason just found it too difficult to sustain his own revised definition.

But the terminology that most grates with me is the assertion that progressive enhancement can be defined as "fault tolerance". The most obvious issue is that there are many instances of progressive enhancement that don't involve "fault". For example, it doesn't make sense to talk about the fault of my browser not specifically recognising the XFN microformat, but my ability to browse the page regardless is, as Gustafason points out, a classic case of progressive enhancement.

The greater problem is that there are times when fault tolerance and progressive enhancement are actively opposed. For example, when browsers tolerate malformed markup it makes it more difficult for later changes to e.g. HTML to be added that bring new features because they are more likely to clash with the "fault tolerant" HTML implementations of older browsers.

The pity is that I don't think this particular confusion is necessary. Progressive enhancement is a very specific kind of fault tolerance, and Gustafason's attempt to compare progressive enhancement to Galapagos finches is entirely misleading, if entertaining. If Gustafason had chosen an alternative term to "fault tolerance", perhaps "graceful gradation" (to contrast with "graceful degradation") then the same point could have been made with much greater clarity.

Adaptive web design is a solid book, written with energy and with a strong sense of the historical development of the web. If a team reads this book together, it will spark a lot of important discussions, but its occasional problems with terminology and its failure to engage with client-side MVC means it will not settle them.

Tuesday, 9 June 2009

When is the right time for the fancy stuff?

Derek Featherstone wrote an interesting post on When is the right time for accessibility? His thesis is that accessibility should be planned for at the design stage, but that implementing it should not be a high priority early on. The idea is that accessibility should be worked on as the product matures and included in a subsequent release.

As far as web accessibility and interaction-heavy sites are concerned, he is asking the wrong question. What he should be wondering is, When is the right time for the fancy stuff?

Sites with a lot of flash and javascript tend to be the worst accessibility offenders because the meaning of the site is only apparent by interacting with scripts on the page. The content is not comprehensible from the DOM itself. If you're sight impaired, don't use a mouse or don't have the reflexes of a twenty-something-year-old flash developer then you might be out of luck.

Derek is of course aware of the importance of accessibility. However his approach seems to be to build the stairs first and then put in the wheelchair ramp later, and no matter how well you plan you will always come across implementation problems you had not considered.

My main criticism of Derek's article is that he constructs a dichotomy between business imperatives (getting the site up) and doing the right thing (implementing accessibility). However there are tangible benefits for your project in getting accessibility right early on.

Most importantly, there is one blind and deaf user that every web developer should be concerned about: Googlebot. If a site is not accessible for a human with a disability then it almost certainly will not be indexed properly by Google. You cannot improve your site through user feedback if you have no users because no one can find your site.

The other main advantage of tackling accessibility early is that progressive enhancement is a sounder development methodology than building everything big-bang style. Build your pages so that they work without any flash or javascript. Once you have that working, you have a sound basis on which to build your incredibly sexy ajax effects.

That affords your testing finer granularity. You can test the plain version of your page before you spoon on the flash and javascript. If there is a bug, you will know whether it occurs as part of the form-submission process or in the interaction layer. That beats monitoring HTTP requests with Firebug trying to work out where the hell the problem is.

Of course, a big motivation web developers to make their sites accessible is that it's the right thing to do. And it is. But if you follow progressive enhancement and make accessibility part of your development process then you'll get more out of it than just a warm fuzzy feeling.