Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Image

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 amazon.com. 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:
  • Web "applications" (Score:2, Insightful)

    by devloop ( 983641 ) on Monday April 27, 2009 @01:34PM (#27732891)

    This should have been a one page book reading : "DON'T".

    Webapps are the most evil thing that has happened to software
    development in the last decade.

    AJAX, Silverlight, JScript are all 1990s state of the art technologies
    that accomplish nothing new in terms of innovation or functionality.

    The resulting applications bring nothing new to the table and are bloated
    and unmantainable compared to their circa 1996 network enabled desktop application cousins.

    Web apps are a historical regression.

  • Re:OT (Score:3, Insightful)

    by RobBebop ( 947356 ) on Monday April 27, 2009 @01:40PM (#27732965) Homepage Journal

    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.

    With a glowing review like that? I'd bet they're paying TOP DOLLAR.

  • by Anonymous Coward on Monday April 27, 2009 @01:41PM (#27732997)
    A few thousand highly intelligent and influential people who make billions of dollars based on decisions on where to move the industry think otherwise. I wouldn't be so quick to dismiss the idea simply because *you* think that this is a historical anomaly.
  • by Anonymous Coward on Monday April 27, 2009 @01:54PM (#27733215)

    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-phone you want to be able to present some text in a very small area. That again, means that your presentation should be adaptable and not look like shit even though the screen resolution is only 300x200.

  • by afabbro ( 33948 ) on Monday April 27, 2009 @02:07PM (#27733469) Homepage

    A few thousand highly intelligent and influential people who make billions of dollars based on decisions on where to move the industry think otherwise.

    Shit, you could say the same thing about any given U.S. presidential administration and I don't think anyone thinks any of them were right.

  • by JasterBobaMereel ( 1102861 ) on Monday April 27, 2009 @02:11PM (#27733541)

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

  • by _bug_ ( 112702 ) on Monday April 27, 2009 @03:13PM (#27734501) Journal

    AJAX, Silverlight, JScript are all 1990s state of the art technologies that accomplish nothing new in terms of innovation or functionality.

    You and I and most web developers know this. The end user does not. And the end user drives the decision maker which drives the design. So you should start asking why the end user doesn't see this as nothing new.

    The resulting applications bring nothing new to the table and are bloated and unmantainable compared to their circa 1996 network enabled desktop application cousins.

    Except that

    1) you have a broad platform that doesn't require a separate compile for each architecture it operates on. this results in lower maintenance and support costs

    2) there's no "downloading" and "executing". this is seamless to the end-user.

    3) if you update the application on the web server (a single point of maintenance) it's immediately updated for every instance, unlike a download-and-run application (including those that have a "check for updates" feature)

    4) processing is shared between client and server, allowing for lower operation costs (at least from a hardware perspective)

    5) there's a perceived "speedyness". ajax requests don't require transition to a new web page. to the end user this is a powerful and positive step forward from the forms and web page-based stuff you saw back in the 90s.

    6) yes, JAVA offered much this in the early 90s, but it was slow and it took (and still takes) forever for the browser's JAVA plugin to load the first time a JAVA application is accessed. thus if feels laggy and slow, which the ajax app doesn't.

    The CON to this is privacy, security, and accessibility. And honestly, nobody outside the industry cares about that. It's not the end-user's problem. So what if you're handing out a browser to every desktop that allows system-level access to the computer? And who cares if anyone can create a web page and embed whatever they want and make your computer do whatever they want. Who cares if your information can traced and siphoned off to some unknown third party. It's all under-the-hood. The end-user doesn't experience anything "bad". Out of sight, out of mind.

    It's all about the user majority experience.

  • by Sinistar2k ( 225578 ) on Monday April 27, 2009 @04:28PM (#27735965)

    Those restrictions aren't forced on the web, unless your site falls under the jurisdiction of Section 508 requirements because it is used by a government entity.

    So exercise your freedoms all you want. Nobody is stopping you.

  • Re:3rd party (Score:3, Insightful)

    by Jaime2 ( 824950 ) on Monday April 27, 2009 @10:40PM (#27740713)
    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 just skinning techniques.

    So -- yes, it is fair to blame people who hack together AJAX apps that barely work on the tested platforms and lack accessibility. Most web development I have seen resembles programming by permutation (http://en.wikipedia.org/wiki/Programming_by_permutation [wikipedia.org]).

    I'm not suggesting that adhering to some "one true way" of web development is a magic bullet to solve anyone's problems. But I am saying that if you take the shortcut to get to a high-level goal you are bound to create an end product that is difficult to maintain and/or has some deficiencies that are hard to diagnose or address, like accessibility. If a desktop application developer delivered a perfectly functional application that had no separation of code into layers of responsibility, it would be seen as amateur work. Web development has a different set of technologies and a different set of rules. A web page needs to be well though out at the markup layer because that is one of its integration points. Imposing presumed control over the browser agent with statements like "best viewed with Flash 9", or "please enable javascript to experience this site" simply create friction between the user and service provider. People use the web because it works for everyone. If I have to install a specific piece of software to visit a specific website, I may as well download a desktop app.
  • by Jaime2 ( 824950 ) on Monday April 27, 2009 @11:09PM (#27740891)

    1) you have a broad platform that doesn't require a separate compile for each architecture it operates on. this results in lower maintenance and support costs

    Bytecode base platforms solved this problem at about the same time the web became popular. See Java and .Net. If the world would stop trying to make the web everything to everybody instead of leaving it a really good hypertext platform, then we could get back to the business of solving the application distribution problem properly.

    2) there's no "downloading" and "executing". this is seamless to the end-user.

    This is an illusion. There certainly is "downloading", the only difference is that the app is downloaded incrementally. Most modern websites use a lot of javascript, so there is a lot of "executing".

    3) if you update the application on the web server (a single point of maintenance) it's immediately updated for every instance, unlike a download-and-run application (including those that have a "check for updates" feature)

    There are alot of download-and-run applications that do a pretty good job at this. Any application as trivial as the majority of websites would have no problem doing this well. But, I'll conceded this point based on a dearth of real world application that self update well. If the web was never invented, we would likely all be running Java applications from URLs. Sprinkle in some caching and this would give the same single point of maintenance experience to desktop apps.

    4) processing is shared between client and server, allowing for lower operation costs (at least from a hardware perspective)

    Welcome to the 1990s. Client server computing was not invented on the web. In many cases, web apps cause far more traffic and client processing than should be necessary, making them less efficient than well-designed desktop applications. Look at the javascript in a browser based drag and drop library some day, that's far too much code for a fairly simple effect.

    5) there's a perceived "speedyness". ajax requests don't require transition to a new web page. to the end user this is a powerful and positive step forward from the forms and web page-based stuff you saw back in the 90s.

    There is a real "speedyness" to desktop apps. AJAX simply put web apps into the same ballpark. BTW, how many AJAX apps discard all of your current data when you hit the "back" button. Real speedy when you have to do it twice. Related anecdote: Our timesheet software at work is web based. If you fill out a time sheet on a computer you haven't used before, as you get near the bottom, the default IE 7 popup blocker kills one of the key AJAX interactions. When you disable the popup blocker, IE is nice enough to reload the page, erasing the entire 90% filled out form.

    6) yes, JAVA offered much this in the early 90s, but it was slow and it took (and still takes) forever for the browser's JAVA plugin to load the first time a JAVA application is accessed. thus if feels laggy and slow, which the ajax app doesn't.

    Java is quite snappy nowadays. Not Java applets, Java applications. There is a big difference. Real desktop developers don't embed their applications in web pages if they can avoid it.

Work is the crab grass in the lawn of life. -- Schulz

Working...