Did you know...

Disability Inclusive Grantmaking is the mission of DFN: inclusion of disability in grantmaking programs and inclusion of people with disabilities in grantmaking organizations.

Accessible Web Design: An Introduction

Note: The following is written primarily for Web designers, although anyone interested in accessibility issues will find it useful.

Persons with disabilities confront an electronic barrier in the World Wide Web. Information on the Web, which has become a vital tool for education, research, employment and commerce, is still too often inaccessible to users with disabilties because designers have failed to take nongraphical browsers and alternative technologies into consideration when planning sites.

Section 508 requirements and overall increased sensitivity with regard to site usability and accessibility have improved the situation, and designers often discover that ensuring accessibility is not as artistically limiting or time-consuming as they had thought. Greater adherence to Web standards and increased browser support for Cascading Style Sheets have certainly contributed.

An ever-growing body of excellent published technical how-to texts follows this discussion. I will present here, instead, a somewhat different approach to achieving accessible Web design: a conceptual approach designed for designers and clients alike.


Concept 1: Think Linear

Blind and vision-impaired individuals use screen-reading devices to surf the Web. These programs scan the page and either a speech synthesizer “reads” the page aloud or a Braille device generates Braille so the user can read the page by that means. The first step, then, in designing an accessible Web page is to ask: How will this page scan? Do the copy and graphics flow logically from left to right and from top to bottom? Even if they “look okay” as you test them in various browsers, does the source coding flow equally smoothly? Remember that the screen reader is looking at the code, not at what a typical graphical browser renders.

Concept 2: Label Everything

This concept encompasses a wide range of subtopics, but in short: Label anything that is not text: images, tables, forms and form components.


Identify all images, including those used in graphical image maps, with alternative text, or “Alt-text.” Nongraphical browsers read these descriptions aloud, enabling low-vision or blind users to “see” pictures audibly.


Tables can be one of the most challenging aspects of the Web to someone using a screen-reading device, but with proper coding and labeling all users should be able to make sense of them.

  1. Include a summary with all tables, including layout tables. For the latter, write something like, “This table is for layout only.” In the more typical case of data tables, the summary tells users what information or data they can expect to obtain from the table that follows.
  2. Identify table column and row headers properly. This is critical to enabling screen-readers to interpret the tables so they make sense to nonsighted users
  3. Refer to the W3C’s guidelines and examples of how to create accessible tables at http://www.w3.org/TR/WCAG10-html-TECHS/#identifying-table-rows-columns.
  4. Test them! Ask some screen-reader users to put them to the test. Were the users able to follow the information? Did information occur out of sequence?
    • Where to find screen-reader users: Contact your local council for the blind, independent living center or vocational rehabilitation center.

One final comment: layout tables are not necessarily the worst evil a designer can unleash on an unsuspecting public. Because style sheets (see next section) are still not fully supported by all browsers, layout tables can still keep a page visually in check.


Creating accessible forms requires an additional two steps beyond “typical” form design: labeling each form element, which serves as a form control, and including default values in text fields. Refer to the W3C’s techniques to achieve this at http://www.w3.org/TR/WCAG10-html-TECHS/#forms-labels.

Concept 3: Use Relative, Not Absolute, Sizing

Fonts and Heads

Instead of specifying exact font sizes, express them in percentages or ems: 1.2em translates to “1.2 times the default font size.” If you must use absolute sizing to maintain a page’s visual appearance, encode these values within style sheets.


Express table and cell widths as percentages instead of fixed values. This will allow the tables to self-adjust to different viewing modes and provide users maximum flexibility. This also ensures tables will appear the same on monitors — and phones and PDAs — regardless of display size.

Concept 4: Use Cascading Style Sheets

Chances are you are already using style sheets, but in the event you aren’t, make life easier for yourself and users alike. Cascading Style Sheets (CSS), have been a boon to designer and accessibility for the simple reason that they separate content from presentation. This is consistent, as well, with XML programming.

Concept 5: Use Markup Code Logically and Appropriately

A text browser or screen reader doesn’t care what font size or color the text is, but does recognize head, paragraph, list and other block-level elements. Proper use of CSS allows the designer tremendous flexibility and creativity to create a visually interesting site while permitting the screen-reader user problem-free surfing. It is essential, however, to use code appropriately. For example, don’t use <H2> to make text larger just for effect: Restrict head codes to their proper descendancy. Create a div, id or class to accomplish the same thing.

Avoid deprecated tags

All languages are growing, living entities, and programming languages are no different. Screen readers and older nongraphical browsers often don’t recognize the <b> and <i> tags, but recognize <strong> and <em>. Few browsers of type would recognize <u>. As HTML has matured and its more sophisticated relatives have become more common, the use of many once-common tags is discouraged because they are no longer fully supported in modern browers. The list of these so-called deprecated tags continues to grow. It’s a good idea to visit the W3C site (www.w3.org) periodically and look under your favorite Web language (HTML, XHTML, XML, etc.) to see what’s new.

Concept 5: Test and Validate

Testing and code validation are essential to ensuring any Web site’s usability. Web folk are accustomed to testing sites on different browsers and platforms, but code validation further reassures the designer that nongraphical browsers will read pages as intended.

Links and Reference

Web Standards and Usability

  • Jeffrey Zeldman, Designing with Web Standards, 2nd ed., New Riders, 2006. The first edition of this book changed my life, along with Eric Meyer’s CSS texts, below. If your Web person hasn’t read it, buy it for her/him. Indispensible, and a genuinely good read, even for nontechies. Really.
  • Jakob Nielsen, Designing Web Usability, New Riders, 2000. The guru of Web usability preaches the gospel of visually clean, logical, speedy Web sites.

Accessible Web Design – General

Cascading Style Sheets

  • Eric A. Meyer, Cascading Style Sheets: The Definitive Guide, 2nd ed., O’Reilly, 2004.
  • Eric A. Meyer, Eric Meyer on CSS: Mastering the Language of Web Design, New Riders, 2002. Invaluable, as is the sequel (below).
  • Eric A. Meyer, More Eric Meyer on CSS, New Riders, 2004.
  • Dan Cederholm, Bulletproof Web Design: Improving flexibility and protecting against worst-case scenarios with XHTML and CSS, New Riders, 2006.
  • Eric A. Meyer, CSS Pocket Reference, O’Reilly, 2001.
  • Christopher Schmitt, Designing CSS Web Pages, New Riders, 2003.
  • A whole library of reference and training texts: http://www.w3.org/Style/CSS/learning


  • Chuck Musciano and Bill Kennedy, HTML and XHTML: The Definitive Guide, 5th ed., O’Reilly, 2002.

Testing and Validation

Free Accessibility Testing

  • Cynthia Says: www.cynthiasays.com
  • HiSoftware’s AccVerify free accessibility testing: http://www.hisoftware.com/accmonitorsitetest/
  • WAVE 4.0 (beta), sponsored by Temple University Institute on Disabilities, and powered by WebAIM (Web Accessibility In Mind):
  • Web accessibility checker from Adaptive Technology Resource Center (ATRC) at the University Of Toronto http://checker.atrc.utoronto.ca/index.html

Accessibility Testing Products for Purchase

Style Sheets

WorldWide Web Consortium’s CSS validator: http://jigsaw.w3.org/css-validator/validator-uri.html


WorldWide Web Consortium’s html validator: http://validator.w3.org/