Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Universal Design for Web Applications 85

Michael J. Ross writes "Two decades ago, Web usage was limited to a single individual (Sir Tim Berners-Lee) using the only browser in existence (WorldWideWeb) running on a single platform (a NeXT Computer). Nowadays, billions of people access the Web daily, with the ability to choose from over a dozen browsers running on desktop computers, laptops, and a variety of mobile devices, such as cell phones. The number of possible combinations is growing rapidly, and makes it increasingly difficult for Web designers and developers to craft their sites so as to be universally accessible. This is particularly true when accounting for Web users with physical and cognitive disabilities — especially if they do not have access to assistive technologies. The challenges and solutions for anyone creating an accessible website are addressed in Universal Design for Web Applications, authored by Wendy Chisholm and Matt May." Keep reading for the rest of Michael and Laura's review.
Universal Design for Web Applications
author Wendy Chisholm and Matt May
pages 198
publisher O'Reilly Media
rating 5/10
reviewer Michael J. Ross with Laura Andres
ISBN 9780596518738
summary An introduction to accessible Web design.
The book was published by O'Reilly Media on 26 November 2008, under the ISBN 9780596518738, and weighs in at a slender 198 pages. The publisher offers a Web page for the book, where visitors will find a detailed description, a customer review, errata (there are none listed, as of this writing), a sample chapter (the 11th one, "The Process") in PDF format, and other items that may be of interest to the prospective reader. The authors as well have a website for the book, which offers the 20 accessibility checklist questions from Chapter 11, as well as slides from the authors' presentation at the Web 2.0 Expo on 17 September 2008 in New York City.

In the preface to their book, the authors explain that the purpose of universal Web design is to make Web content "work as efficiently as possible across the range of capabilities exhibited by both people and their chosen browsing technologies." While it has little to do with efficiency per se, maximum Web usability is a laudable goal for every designer and developer of a website or Web-based application. The consensus in the Web design community is that the most effective way to achieve this goal is through adherence to accepted usability standards and design practices, and those are the topics that the authors explore in the eleven chapters that compose this book: an introduction; selling universal design; metadata; structure and design; forms; tabular data; video and audio; scripting; AJAX and WAI-ARIA; Rich Internet applications; and the universal design process.

The first chapter serves as a brief introduction to the concept and overall purpose of universal design (UD), which the authors consider to be "the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design" (as defined by architect Ron Mace). In view of the brevity and preliminary nature of this chapter's material, it should have been labeled as an introduction, and not a chapter. More importantly, the discussion is rather choppy, jumping among topics such as architecture, grocery stores, unemployment rates among the blind, and mobile phones. Readers will likely be confused by the authors' statement that "mobile and accessible design are also at opposite ends of the spectrum when it comes to meeting our stated goal," as that suggests that the more mobile the device, the least accessible platform it can ever be. Yet the gist of the discussion is clear: The need for maximally accessible websites is quite important — critical to those with various disabilities — and will become more so with the proliferation of Web-enabled mobile devices.

If any chapter in this book is going to raise hackles, it is surely the second one. It focuses on how to sell Web accessibility to decision-makers, such as convincing management that compliance with universal design standards — in creating a new site or re-creating an existing one — is worth the investment. This position could easily be supported with a thoroughly positive mindset, such as showing how enhanced accessibility for some is beneficial to all. Instead, the authors initially take a more negative approach, and begin the chapter with somewhat hostile descriptions of what it is like to not understand a movie, and the resistance the authors have encountered in selling accessibility to clients. The authors clearly want the reader to empathize with such people, but the methods employed are questionable — such as asserting that all of us can face a handicap at some point, and thus we can all be lumped together as "disabled." While the authors' passion for online resources being made available to everyone, is certainly laudable, there is nothing to be gained from making sweeping generalizations or lecturing the reader. (Overstating one's arguments tends to turn off listeners, and provides fodder for counterarguments.) The authors go on to define the four major categories of physical and situational disabilities, as they relate to website usage. They cite statistics for deafness and hard of hearing, but neglect to include tinnitus, which apparently has more sufferers than those first two conditions combined. Next, the authors provide selling points for employing universal design to increase a site's potential audience — humans and search engines — thereby increasing financial results and adhering to legal restrictions. Readers are referred to a number of pertinent resources, including the Web Content Accessibility Guidelines (WCAG), the Authoring Tool Accessibility Guidelines (ATAG), the User Agent Accessibility Guidelines (UAAG), the Accessible Rich Internet Applications Suite (WAI-ARIA), and the Mobile Web Best Practices (MWBP). Nearing the end of the chapter, the authors return to the minefield of how to convince the "prejudiced developer" and manager that they should learn and utilize accessibility best practices in creating websites for which they are responsible, especially when they see no value or need for it. Lastly, excellent arguments for the product benefits of continuous accessible design are briefly presented.

By the third chapter, Web designers and developers who purchased this book to learn specific accessibility techniques, may become a bit impatient, since nothing concrete has been presented up to that point (despite the claim later in the chapter that "We've devoted three chapters to making web applications accessible."). Fortunately, this chapter gets things going by addressing metadata and how it can be leveraged to increase content accessibility. The specific techniques discussed include the alt, height, and width attributes for image tags; document-level metadata, including title tags; and link text. The guidelines are definitely worthwhile, but the presentation could have been better edited. For example, the authors state that the alt text for a linked image is "a verb and represents where the link will take you" (page 27), but a destination is not a verb, and neither is the example provided ("next page").

Chapter 4 addresses the structuring and design of Web pages, and covers important topics of semantic markup, headings, links, lists, forms, tables, colors, layout choices, text sizing, fonts, and images. For some reason not explained to the reader, forms are discussed first, even before semantics, which is odd. Nonetheless, all of the suggestions provided are well worth learning and incorporating into one's own repertoire of Web coding and design principles. The authors rightly teach the maxim "separate structure and presentation," and demonstrate how to do this throughout the discussion of the aforesaid topics. Also addressed are flickering images — and one of the dangers thereof, photoepilepsy — and HTML e-mail messages.

Web forms possibly compose the most problematic type of page element, especially in terms of usability and accessibility, because they involve for more user input than any other. This is especially true with forms that use CAPTCHAs in an attempt to defeat form spam. Chapter 5 encompasses a useful discussion, with illustrative sample code, covering the key considerations for coding accessible forms — including labels, fieldsets and their legends, accesskey attributes, and tab order among elements. The authors state that a block of sample form code (page 54) is available on their website, but, as of this writing, it could not be found. Yet readers may not want to use that code anyway, since all of the labels and all of the input fields are separated, into two divs; no explanation is given as to why this nonstandard structure was chosen. Error handling is a subject that stymies countless inexperienced Web programmers, as evidenced by the oftentimes useless messages displayed on the sites that they have created, and the authors provide solid advice, with emphasis on client-side error handling. The chapter concludes with a somewhat short discussion of what they consider "Public Enemy #1 for blind, low-vision, and dyslexic people," the dreaded CAPTCHA, with links to two publications that propose alternatives.

Accessibility abuses are especially prevalent with three types of Web content: HTML tables and multimedia. These are the topics of chapters 6 and 7, respectively. Semantic use of HTML tables for tabular data is seeing a resurgence with the growing interest in accessible design, and Chapter 6 explains how to implement them properly. However, Figure 6-3 purportedly contains blue shading, but it is effectively invisible on the black-and-white printed page. Chapter 7 explains how to add captions and audio descriptions to audiovisual files, or outsource the work. But first the reader slogs through a detailed history of Web-based video that is unneeded, despite the authors' claims that knowledge of the history is important.

The next two chapters discuss the use of JavaScript and AJAX as they pertain to site accessibility, and could be combined into a single chapter. The first one briefly addresses a number of related topics: progressive enhancement, Unobtrusive JavaScript (again with an unnecessary history), keyboard activation of pop-up menus, limitations of :hover pseudoselectors, two recommended drop-down menu scripts, and tabbing order. One of the scripts is an open-source script that the authors claim can be downloaded from their website; but, like the form sample code mentioned above, the promised script is missing from their site. The authors later declare (page 107) that in this chapter they show "you how to add JavaScript to your HTML and CSS to make a web application," when in fact they do nothing of the sort. Entire books explain how to make Web applications — not something accomplished in a 15-page chapter. Chapter 9 focuses on AJAX and WAI-ARIA — specifically, the ways that the AJAX paradigm clashes with the current state of assistive technologies, and how ARIA may prove the best solution — resolving the keyboard activation problem covered in the previous chapter, and handling tab ordering in a more elegant manner — though still not ubiquitously implemented. The narrative's flow is interrupted with almost three pages of JavaScript that the reader is apparently not expected to implement as-is or even use as sample code to learn from, and thus looks suspiciously like padding.

In Chapter 10, the authors discuss the unfortunate lack of Web accessibility guidelines for Rich Internet applications (RIAs) developed using technologies such as Java, Flex, and Silverlight. To remedy this, the authors promise "a crash course in software accessibility as applied to Flex and Silverlight," but only deliver on the second half of that promise. For illustrating Silverlight development, they provide some of the code for creating a custom Digg button (although the term "buttons" is also confusingly used). The chapter concludes with mention of some tools from Microsoft for testing RIAs that utilize Microsoft Active Accessibility (MSAA).

The last chapter begins with a brief high-level perspective on the importance of baking accessibility into any new application or site from the start, and then explores numerous development and testing tools and other resources. Perhaps the material that will be most referenced in the future by readers, are the 20 key questions that a designer can use as a valuable checklist for evaluating a site she has created. The chapter concludes with some thoughts on strategies for successful universal design, for four different team sizes. The book's sole appendix consists of a table relisting the 20 key usability questions, and for each one, the specifications of the WCAG 2.0 Proposed Recommendation, the MWBP 1.0, and the UD4WA. This is followed by an index that proved quite disappointing, as it contains almost none of the entries that I attempted to look up.

Universal Design for Web Applications has numerous relatively minor flaws that could be fixed in a future edition: Some of the chapter summaries comprise only one or two sentences, and add no value to the book, since the chapters themselves are so short. Other chapter summaries contain new material not even mentioned in the respective chapters, and should be renamed as final sections. Many of the URLs are wisely presented as footnotes — instead of embedded in the text, as is done in many other technical books, which impedes reading flow. Unfortunately, this practice was not followed consistently throughout the book. In some passages, the writing style is rather unpolished; for instance, "mobile and accessibility as our criteria" (page 2), mixes adjective and noun. In other passages, the statements are hyperbolic; for instance, a reporter "found himself a hair's breadth from being eviscerated" (page 4). Some unexplained phrases will prove cryptic to many readers; for instance, "content adaptation" (page 24), "lolcats" (page 26), and "antipattern" (page 37). The use of a shortened URL (page 23) is inadvisable, since it depends upon the longevity of the particular service provider and the short URL that the service generated. Some of the terminology is inconsistent, e.g., the Enter key referred to as a "Return" key. The book contains a couple erratum: "to to" (page 12), and a sentence missing a verb (page 111, beginning with "Layering").

A visually annoying problem with this book is the manner in which, on far too many lines in the text, there is an inadequate amount of space between the words. Consequently, distinguishing individual words — particularly when trying to read at a fast pace — is made much more difficult. While skimming, each line begins to look like one extremely long word. There is no excuse for this, since there is plenty of space in the outer margins to have expanded the lines, and the number of pages is far less than in a typical computer book. This is not the first of the most recently published O'Reilly books to exhibit this problem, but I certainly hope it is the last. It is rather ironic to see this readability mistake in a book devoted to usability and accessibility. (Note that production decisions such as whitespace are not decided by the authors.)

Perhaps the most exasperating defect of all is that both instances of code that supposedly can be downloaded from the authors' website, are nowhere to be found, as of this writing — nor is the code available on the O'Reilly page for the book. In fact, a reader comment on that O'Reilly page indicates that the script code wasn't available on 30 December 2008, just weeks after the book's publication. This is quite unlike the level of follow-through typically seen with O'Reilly authors.

In some respects, the book could have been far better than the final product. It gets off to a weak start with a non-chapter, and then in several sections spends pages discussing the history of various technologies, but then fails to go into enough detail so the reader could use the current state of those technologies to implement what is promised in the book. It also could have been improved with much more detailed and usable discussions of such topics as scrolling, bypassing blocks of content, session time limits on forms, site maps, breadcrumb trails, usable CAPTCHA alternatives, typography, text case, paragraph justification, sign language, text direction, and techniques for providing text for image-heavy websites — as well as more complete code examples.

Nonetheless, Universal Design for Web Applications provides some valuable recommendations and pointers on how website designers, developers, and owners can greatly increase the accessibility of their sites to the growing variety of human and search engine visitors on the Internet.

Michael J. Ross is a freelance Web developer and writer. Laura Andres is a Unix administrator, Oracle DBA, and programmer.

You can purchase Universal Design for Web Applications: Web Applications That Reach Everyone from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.


This discussion has been archived. No new comments can be posted.

Universal Design for Web Applications

Comments Filter:
  • A visually annoying problem with this book is the manner in which, on far too many lines in the text, there is an inadequate amount of space between the words. Consequently, distinguishing individual words -- particularly when trying to read at a fast pace -- is made much more difficult.

    Maybe they'll come out with a "large print edition".

  • It is great that the book includes accessibility issues, too often that is an after thought. 3 cheers for the author.
  • The teaser paragraph on slashdot starts espousing about how the web is being used on all sorts of browsers and devices. Then it goes on to discuss webdesign for disabilities (blind, deaf, etc.). The two are basically unrelated.

    This reminds me about how Bush started off talking about 9/11, and ended up calling on the USA to invade Iraq.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      The teaser paragraph on slashdot starts espousing about how the web is being used on all sorts of browsers and devices. Then it goes on to discuss webdesign for disabilities (blind, deaf, etc.). The two are basically unrelated.

      I beg to differ. Both are about showing the same content, but with different presentation. They both leads to seperating content from presentation. They both leads to letting the client (browser, ...) having some control over presentation.

      For example a person with bad eye-sight want bigger fonts, so you website should not look like shit if somebody sets a minimum font-size of 15. And by "look like shit" I mean something like part of the text being unviewable, because it is hidden under some menu.

      For a smart

    • We need to design web pages properly, because Iraq has weapons of mass destruction!


  • Sorry, the book is already obsolete.

    • Re: (Score:3, Insightful)

      ...really on all those browsers designed more than a year ago on phones, PDA's, Playstations, most PC's etc ...

      Code to a standard and it will always be accessible, code to the cutting edge and only the cutting edge will see it properly ...

      • I really meant it mostly as a joke, but consider that punched tape and punched cards followed a standard but are mostly inaccessible today.

  • Could this be the executive version summary:
    They just took this relatively strong 20-question form at [] and tried unsuccessfully to build a book around it?

    • Re: (Score:3, Informative)

      by rhizome ( 115711 )

      No, the executive summary for this review reads like all the rest of Slashdot's book reviews:

      1. Preface says...
      2. Chapter 1 is about...
      3. Chapter 2 goes over...
      4. Chapter 3 introduces...
      5. ...
      6. The End
  • Trying to get people to agree on a standard for web development is like standing in the middle of the dessert screaming you want ice cream. Good luck with that.
    • Well, if you're already standing in the middle of your dessert, it probably means you dropped it. So naturally you'd scream for more!

      • Or maybe you don't have no ice cream, you didn't get none, you can't afford it, 'cos you are on the welfare, and your dad's an alcoholic!!"
  • Called Internet Explorer by Microsoft. Remember when this used to be so easy? :P
    • by jc42 ( 318812 )

      Called Internet Explorer by Microsoft. Remember when this used to be so easy?

      Yeah, back when only the first release of IE was out. Since then, it hasn't been easy even if you're just developing for IE, since every release of IE has had gratuitous inconsistencies with the previous release. Of course, to Microsoft, the current release is always the "standard", and previous releases are obsolete, so everyone is expected to change their sites accordingly. However, if you're working for a company whose manag

  • #1 there are no such thing as standards for new technology. no one is omnipotent enough to envision all of the popular use cases and all of the platforms. as such, we will code for a tower of babel for many years to come, with some parts of tech ahead of the standards, and different vendors delivering different patchwork solutions

    #2 stop complaining about how every browser and every platform has different quirks. if they didn't, your job would be replaced by a script

    #3 at some point, as the tech becomes sta

    • > no one is omnipotent enough to envision all of the popular use cases and all of the platforms.

      I strongly disagree.

      Yours truly

  • by toejam13 ( 958243 ) on Monday April 27, 2009 @02:19PM (#27733691)

    For every website I've ever created, I include a link in the top left corner that points to a text-only version of the same page. When you bring the main page up, the text-only link is the first one available.

    According to my web stats, the most common user of the text-only pages are people from third world countries, as well as a significant number of mobile users. I have also seen a large number of legacy browsers, such as Lynx, Netscape 4 and IE 4.

    The text-only page is the ultimate fail-back option. Every single web browser can handle it. Text to speech devices can handle it. People with vision problems can read it more easily.

    I'm actually surprised that they've not been made mandatory in the US due to ADA (Americans with Disabilities Act) requirements. As somebody who suffers from vocal Tourette syndrome when my page is overloaded with crappy Flash content, I think such a requirement would be a great idea.

    • by Chysn ( 898420 )

      > I'm actually surprised that [text-only pages have] not been made mandatory in the US due to
      > ADA (Americans with Disabilities Act) requirements.

      You're surprised that the ADA doesn't require more compliance than it requires? I'm glad we have the First Amendment to save us from reverse tautologies.

    • But yours is the wrong approach.
      As soon as you look at the visual layout while writing HTML, you do something fundamentally wrong.
      I write my pages in a semantically and structurally proper way. So they look good in Lynx as they are.
      Then I add browser-dependend CSS (with server-side detection for older systems).

      Works well.

      But I will not ever support legacy HTML again.
      Other types of output, like text-only, voice, or whatever, yes.
      Outdated code? Only if I have no choice. And then only as a server-side switch.


  • Rather than web design standards I would rather see a bunch of browser standards:

    - Make all browser's css W3c compliant standard stuff, no quirks mode.
    - Make Javascript syntax and behaviour universal.
    - Have W3c come up with a lightweight css and script standard for browsers on smaller devices.
    - Make all browsers render the page *the same*.
    - and finally, shoot everyone on the IE development team.
    • by hplus ( 1310833 )

      - Make all browsers render the page *the same*.

      Use PDF if you want all of your pages to look the same. One of the great benefits of HTML/CSS is that a user can configure pages to work differently based on their needs. Users on low bandwidth connections can eschew graphics. Those with poor eyesight can up the font size, and so on.

      • heh? pdf??

        That's the most retarded suggestion ever.. How do you suppose I should go about pdf'ing my dynamic application? generate every page and run it through a pdf convertor and present a download to the user??

        The point I was driving at was that the same element e.g. a fieldset renders a lot differently in IE, Firefox and Safari. I want to see the same basic size and shape in every browser that my app is opened on, just for the sake of my sanity.. currently every web app I write has to be tested te
  • While I don't have anything against taking the time to make your app accessible if you need to hit that market, it would be nice if there were 3rd party additions for the client browser that kept pace with the app technologies.

    I don't think it's fair to blame AJAX and other schemes for lack of accessibility. Accessibility tools need to keep up with the technology. Web developers should be able to specialize in web technology, and accessibility tool developers in their niche.

    • Re: (Score:3, Insightful)

      by Jaime2 ( 824950 )
      People still aren't used to the fact that their apps can be de-skinned and re-skinned. Too many web developers think they are developing a pretty GUI when they are really creating hypertext. If you "think HTML", you will end up fully describing the page and adding tweaks for browser quirks after the fact. If you "think presentation", then you will hack away at a page until it looks good on the platforms you choose to test it on, but few others. Accessibility, mobile browsers, and security add-ons are ju

"I prefer the blunted cudgels of the followers of the Serpent God." -- Sean Doran the Younger