|
Article:
The Top 5 Roadblocks To Web Accessibility by: Karl Groves Introduction Accessibility is often the last thing on a web designer's mind when creating a website. This is not a trait unique to newbies or people working on a personal page. It is also a trait common to professional web designers (large and small) and even multinational corporations. In fact, most web designers have no clue about what accessibility is. Many who do know what accessibility is will often treat it as though it is brain surgery. Nothing could be further from the truth. In fact, all that it takes to create an accessible site is some forethought and understanding of the kinds of mistakes you're likely to make so you know how to avoid them. What is Accessibility? For those with no knowledge of accessibility, I usually like to use the following analogy: The building you work in probably has at least one handicapped parking space. If it has more than one floor, it probably has an elevator or escalator (or both). It has railings on the stairs, and probably has a dip in the curb. Your workplace has these items in order to facilitate access to the business by disabled customers and/or employees. Accessible web design is nothing more than an electronic equivalent of this effort toward equal access to your resources. The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect - Tim Berners Lee, inventor of HTML and the HTTP protocol. Why A Complete Focus is Needed I will not venture into any discussion of the morality of why you should make your site accessible. Simply put, any argument (other than sheer ignorance) against accessible design is simply not worth having. Instead, let's focus on what sorts of special needs a user may have that can create problems in interacting with a website: Visual impairments, which can manifest themselves in color blindness, poor eyesight or complete blindness Hearing impairments in a wide range of potential severities Mobility impairments ranging from arthritis, multiple sclerosis, Parkinson's disease, paralysis, or other motor-control disorders Cognitive impairments such as cerebral palsy, Downs syndrome, Alzheimer's, dyslexia, or learning disorders Seizure disorders like epilepsy Ultimately, a complete approach is what is needed in order to create an accessible site. You cannot predict the user's needs or the severity of those needs. Misguided approaches such as browser detection or text-only alternatives betray a lack of understanding this fact. Text-only alternatives can only provide an accessibility solution for those with vision disorders, thereby disregarding millions of other disabled users with different needs. Browser detection is destined to fail, as disabled visitors use a wide range of adaptive technology, including user-agents that identify themselves as one of the major brands. Moreover, there is no way to detect the user's pointing device or any of the other items in the wide range of settings used to compensate for their special needs. Avoid The Most Common Mistakes In their ignorance and disregard, web designers are most likely to commit five mistakes that are roadblocks to accessibility. Avoiding these mistakes will take you far down the road toward accessible design. Your site won't be perfect just by avoiding these five mistakes, but committing these mistakes will likely mean the site is completely unusable a wide range of users with special needs. 1. Dependence upon client side scripting to present navigation or important content Among the ways you can make a website completely inaccessible to many types of impairments at once is to use client-side scripting in such a way that the entire site fails to work for users who have client side scripting turned off or who are using adaptive technology that does not recognize client side scripting at all. Such items would be things like: Event handled dynamic content (processed client side) Fly-Out (aka DHTML) menus Drop down menus that require the onChange event handler to operate Popup windows that do not work without JavaScript Reliance on scripting will have one of four possible results: The site will load but navigation will be impossible (it will either display and not work, or often just not display) Substantial portions of content will not display The site will load but absolutely no content will display In an attempt to circumvent "usability" problems created by their use of scripting, they will cluelessly detect the presence of scripting support by the browser and redirect the user to a dead end page, which attempts to teach you how to upgrade your software. I consider any of these results to be a complete accessibility failure. Unfortunately, even websites for multinational corporations and government entities fail under such criterion. The following sites lead to dead end pages asking you to upgrade your software New York Stock Exchange Time Magazine H&R Block Travelocity General Motors Toyota Porsche The following sites result in completely inoperable navigational elements Washington DC Water and Sewer Authority Volvo 1-800-Contacts The American Automobile Association Verisign The following sites will load, but the content will actually not display at all Chrysler Ford Chevy Visa The following sites have a Swiss-cheese effect with content sporadically missing on screen Dodge Jeep Baltimore Ravens Football Team The solution for these problems is extremely simple. Do not make anything completely dependent upon scripting. Interactive elements should add to the enjoyment of the website, not detract from it as often happens. I recommend against using "fly-out" (aka DHTML) menus and dropdown menus for primary navigation. While it is possible to create them so that navigation works with scripting turned off, that will only solve one set of problems. As a general usability issue, DHTML navigation is often described as "slippery" by able-bodied users, and can certainly create frustration among those with motor impairments. At the very least, you'll want to ensure two things when using fly-out menus for navigation: The menu (or a <noscript> alternative) actually displays when scripting is off/ unrecognized The first link in the menu functions and leads to an actual destination Create drop downs that function without scripting. You can choose one of about three approaches to this: First, it is OK to operate from an onChange event on these, provided of course, you supply a submission method that doesn't rely on scripting - in other words, a button and a server-side script Second, if you really want to get tricky, write the button based upon detection of scripting support. It's a bit too much needless effort in my opinion, but some might not think so. Third, write the list of links in your <noscript> element that have the same destination as the DHTML menu. The majority of users will get the nifty dynamic menu and those without scripting support will at least get an operational list of links that go to the same place. Other navigation I have even seen plain text links rendered inoperable without scripting support. The natural solution is just to not do that. There are no neat workarounds necessary. Event Handled Content Event-handled content is a bit trickier. In general, my argument is that there is nothing that client-side scripting can do that cannot be done with server-side scripting such as PHP. For small websites, this is the best approach. For a large website getting thousands of hits a minute, the back & forth trips to the server for each little request can become an overwhelming burden on the server. In the case of large sites, developers need to work with the person responsible for interaction design to come up with a way to avoid such a reliance on client-side scripting. Unfortunately, event-handled content is also likely to result in a blank, or Swiss-cheesed screen if handled client-side. In such a case, you're probably better off dodging the issue altogether by any means necessary. I'd rather have a website that worked properly for everyone than a website that had interactivity dependent upon something that completely failed for a potentially large number of people. Popup Windows For popup windows, you will need to make sure the link operates regardless of scripting support. If you're using popup windows for ads, they're probably tied to an onload (or onunload) event. That's fine, leave it there. Nobody except you and your advertiser likes them anyway; so don't bother making them accessible. But if you're using popup windows for supplementary content, you should not use "#" or "javascript:" as your hypertext reference. Use a real link, and set your JavaScript code to "return false". The link will operate properly regardless of scripting support. (See my article - "A More Accessible Pop-up Window") 2. Improper use of markup/ Invalid markup Much is thrown around in discussion groups about the value of valid markup - even by yours truly. Valid markup is easy to create, despite the fact that most people manage not to achieve it. The validity of the page's markup is important - from an accessibility standpoint - because adaptive technology may not be as forgiving of botched markup as the major browsers. What is more challenging, even among those who have valid pages, is the proper use of markup. Web designers say much about interactive, dynamic, and database-driven content. Ultimately, it doesn't matter one bit about how amazing the programming is that drives the site - what gets sent to the visitor's browser is HTML. HTML is a markup language Simply put, it was created with the express purpose of describing the structure of the information, NOT the presentation. Many web designers will use HTML to dictate the presentation by using deprecated or proprietary attributes, or by improperly using some elements to dictate presentation: Deprecated elements include <center>, <font>, <menu>, <s>, <strike>, <u> Deprecated attributes include align (in many cases), alink, background, bgcolor, height and width (for table cells), hspace, vspace, and many more Improper use of elements to dictate presentation would include use of tables for layout, use of <tbody> in layout tables, using <pre> or <blockquote> to control text positioning, or not associating data table cells with headers and defining relationships between headers and data rows/ columns. CSS is for presentation In every case where presentational effect is needed, you should use CSS to achieve the presentational effect. I cannot think of many presentational effects achieved by HTML attributes that do not have CSS equivalents. Some CSS properties have spotty support by major browsers, and for this reason you should always keep this issue in mind. This spotty support does not mean you should lazily resort to HTML's presentational attributes. Rather, it means you should either come to grips with the myth of "looking the same" to everyone or find another presentational effect to chase after. In my opinion, resorting to a workaround means the design is flawed, not the spec. Use appropriate markup Use appropriate markup for the document, before even involving yourself in presentation. This includes things like headings, paragraph tags, and break tags. Are you using <h1> to make a large, bold word? Are you using <b> to create a heading? Are you using <p></p> to create a break between paragraphs? Are you using <blockquote> to indent text? If so, you're using these elements improperly. Each of these elements has a purpose in dictating the structure of the document. For instance, <h1> is the element meant to dictate the heading of the document. <h2> is for sub-headings, such as main sections of text. <h3> is meant as a subheading of a section. <p> is meant to mark a paragraph, and so on. For more information on what the purpose is of the various HTML elements, visit the spec yourself. http://www.w3.org/TR/html401 To ensure greater accessibility: Use HTML to define structure only Use CSS to define presentation Always use the most appropriate element for the content. Do not misuse elements or attributes just to achieve your aesthetic vision. 3. Device dependence While many people tend to think of accessibility as efforts to make a site usable for the blind, this is simply not true. Creating a site that is dependent upon any piece of hardware is destined to fail for users with a wide range of potential special needs - most notably, the blind and persons with motor impairments. Device dependence is a bad practice from a general usability standpoint as well. More and more users are accessing the Internet with devices such as cell phones and PDAs. Creating device dependence can serve to alienate far more people, disabled or not. Device dependence can be seen as: onClick/ onMouseover/ onMouseout or other event handlers that rely on the user having a mouse in order to operate a link or form control. Server-side image maps that do not have a corresponding set of redundant links Navigation or forms that do not have a logical tab order I don't necessarily frown on device dependence in cases where the dependence is only an issue for things like rollovers, image highlighting, text color changing, or some other decorative change. The issue comes when the device dependence combines with a reliance on scripting (#'1
|
