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.
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.
| 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. |
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.
Web "applications" (Score:2, Insightful)
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: (Score:1)
Re: (Score:1)
...whatever that name is, that you're not supposed to say...
I think it's "Beetlejuice"
Re: (Score:2)
... Browsing at +2 revealed very few comments, so maybe I'll see what's happening at -1. Funny. And disturbing.
Re: (Score:2)
All the good stuff gets modded down. The trolls on slashdot are the greatest.
Re: (Score:2, Insightful)
Re:Web "applications" (Score:4, Insightful)
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.
Re: (Score:2)
"A few thousand highly intelligent and influential people who make billions of dollars based on decisions on where to move the industry think otherwise."
The fact that it is a wise movement *for them* to increase *their* profits doesn't immediatly make a wise decision for *you* to adopt.
Re:Web "applications" (Score:5, Funny)
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.
Posted on a historically regressive site.
Mod Parent Up! (Score:1)
I disagree about Silverlight, though. Providing a rectangular viewport for a virtualized computing environment, a la Flash or Java, is perhaps a good compromise for a web-delivered application. Of course, better yet is leaving the browser entirely via something like Java we
Re: (Score:1)
There are three layers.
Bottom: Data and semantics (HTML, semantic )
Middle: Layout and formatting (CSS)
Top: Post-load dynamics (JS)
If the lower-level layers operate without depending on the higher-level layers, no problem exists.
The problem is, people don't think of it that way, and keep designing pages which depend on javascript to work, or become horribly hard to use without stylesheets.
I wrote about this some time ago:
http://chjacobsen.blogspot.com/ [blogspot.com]
Re:Web "applications" (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Meaning that it's a web app.
Re: (Score:2)
Re: (Score:2)
unmantainable compared to their circa 1996 network enabled desktop application cousins. Web apps are a historical regression.
Well continue to develop 1996 applications while I develop 2009 web based applications. You will be right and out of job, I will be wrong and rich. It sounds like a good deal to me :-).
Re: (Score:3, Insightful)
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.
Unclear on the concept. (Score:2)
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".
That is Funny! (Score:4, Funny)
Maybe they did read the book on "Universal Design for Printed Media" :)
Re: (Score:1)
Come on, the book is on design, i.e. it's an art book. It is all in the eye of the beholder.
Making text hard to read is just another way of failing at design.
Re: (Score:2)
Dude. You've got some really weird fetish, there....
Re: (Score:2)
That's a reference to a music video from an episode of this year's Saturday Night Live in the states. If you havn't seen it you would think that's a pretty weird thing to post which is the crux of the video too.
Re: (Score:2)
Well, no...I haven't seen it.
I figured it was just some weird /. immature pervert comment. Which, considering it came from SNL, isn't really that much different.
Re: (Score:2)
Bad in the sense that the review was negative, or bad in the sense that the reviewer didn't understand the book? If it is the former, then "unfavorable" might be a better term.
accessibility (Score:2)
Browser compatibility? (Score:1)
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)
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
Re: (Score:1)
Re: (Score:2)
We need to design web pages properly, because Iraq has weapons of mass destruction!
Chewbacca!
26 November 2008? (Score:1, Troll)
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 ...
Re: (Score:2)
I really meant it mostly as a joke, but consider that punched tape and punched cards followed a standard but are mostly inaccessible today.
Built a book around the 20 questions? (Score:4, Interesting)
Could this be the executive version summary:
They just took this relatively strong 20-question form at http://ud4wa.com/ [ud4wa.com] and tried unsuccessfully to build a book around it?
Re: (Score:3, Informative)
No, the executive summary for this review reads like all the rest of Slashdot's book reviews:
Whaaa? (Score:1)
Re: (Score:1)
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!
Re: (Score:1)
A universal design does exist... (Score:2)
Re: (Score:2)
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
three things: (Score:2)
#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
Re: (Score:1)
> no one is omnipotent enough to envision all of the popular use cases and all of the platforms.
I strongly disagree.
Yours truly
God
Comment removed (Score:4, Informative)
Re: (Score:2)
> 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.
Re: (Score:2)
I'm really happy that I am not forced to actively counteract natural selection. Thank you very much.
Re: (Score:2)
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.
N
Re: (Score:2)
11011000 11111011 11010101
10101010 11000000 10101010
11010111 11111001 00001100
11101111 !!!!!
Re:Insentivie Clod alert (Score:4, Insightful)
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.
browser standards (Score:1)
- 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.
Re: (Score:1)
- 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.
Re: (Score:1)
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
Re: (Score:1)
If they drew naked chicks instead of the dog, no geek would be able to get past the cover. It'll sell pretty well though..
3rd party (Score:1)
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)