AARP.org
Connect with the AARP Community, it's free. Log In Sign Up

The Blind Leading the Blind: Theorizing a Web for the Visually Impaired, February 28-29, 2004

AARP was pleased to present at the 2004 Information Architecture Summit in Austin, Texas.

Session Description

How do you plan a site for the visually disabled? Section 508 tells us what not to do, but it doesn't present a model for doing things right. This case study shows how AARP is planning a site for the visually disabled, and how the lessons we learned can work for you, regardless of your audience. Understand how browsing behaviors are similar for the average user and the visually impaired user. Learn how a linear underlying structure can improve the browsing experiences of both audiences, and simplify the web team's life by making content independent from visual design.

Speakers

  • Jessica Moore, Art Director Web/Online, AARP Services, Web Strategy & Operations. jmoore@aarp.org
  • Joseph Mathews, Senior Web Developer, AARP Services, Web Strategy & Operations. jmatthews@aarp.org

Presentation

You may read the presentation and descriptions of the illustrations below, or view the presentation with illustrations (pdf, 250k).

How the Project Started

  1. AARP has a higher percentage of older users than most web sites
  2. Visual impairment increases with age
  3. The national rate of vision impairment in adults over 40 is 2.85%, according to the NIH (2002, Prevent Blindness America); 30.7% of those adults are blind

What We've Done To Date

Beginning late 2000, AARP decided to try to adhere to Section 508 standards

  1. We are more strict with consumer-education content, but less so with content of entertainment value
  2. We're far from perfect: it's also been important to us to support a broad base of web browsing platforms, so we have made compromises

Supporting Initiatives

Older Wiser Wired community, formed 2003 by Beth Mazur and Amy Lee

  1. A community of those who use the web to provide information and services to older adults, those who write about this subject, or those who develop web content for clients with older adult audiences.
  2. The key purpose of this initiative is to encourage better understanding and awareness of the needs of older adults.

And then, we redesigned and created a style guide.

  1. Beginning in May 2002, we implemented a CMS, a new design, and a new strategy
  2. When the dust settled, we took our lessons-learned and created a style guide for future projects
  3. The style guide mandated some changes to our code and our CMS templates

The style guide offered more than visual consistency.

Having a consistent structure also made it possible to standardize our templates so that they could inherit structure and style based on their place in the IA

And Accessibility… Why Not?

Since we needed to revisit all of our code and our templates, we decided to make the pages 508 compliant and truly accessible at the same time

The Big Question: "How?"

  1. We quickly realized there were no examples for how to do accessible design
  2. Section 508 provides "Do's and Don'ts"
  3. W3C's Web Content Accessibility Guidelines provide more "Do's and Don'ts" elaborated with some specific techniques
  4. The ISO's technical specifications, "Ergonomics of human-system interaction — Guidance on accessibility for human-computer interfaces" again re-present "Do's and Don'ts"
  5. Available literature discussed isolated best practices
  6. An examination of government websites (those required to adhere to Section 508) revealed no common practices or themes
  7. People seem to agree on the standards, and all of this is useful if you're already on the right track, but how do you start? What are the proper steps?

Reading Behaviors for the Sighted: Traditional Elements

Use of traditional design elements to guide the eye: visual design helps drive people where you want them to look.

  1. White Space
  2. Color
  3. Contrast
  4. Leading lines
  5. Fonts and text treatments
  6. Graphics
  7. Appearance of mass texture

Browsing Behaviors for the Sighted: Reading on the Web

  1. Varies by age and culture
  2. Users can be "trained" by good and evil forces: by your site and others. Consistency within your site is important, and consistency with major trends in other highly-used sites is important
  3. NOTE: Some sighted users cannot see the whole page at once (either through technological problems, or through low vision — a separate design issue from blindness

Browsing Behaviors for the Sighted: Web Elements

  1. People love to skim.
  2. Special web design elements that help people skim, and so draw attention quickly:
    1. Headers
    2. Bullets and Lists
    3. Links
    4. Forms and buttons

Browsing Patterns for the Blind: What's Similar

Ability to skim through web elements offered by the major screen reader programs

  1. Link lists
  2. Header lists
  3. Page summary, including form fields
  4. Skip to lists

Browsing Patterns for the Blind: Enhancing Skimming

  1. We can enhance the ability to skim through web development
    1. "Skip to main article" and such links
    2. Semantically correct HTML
    3. Appropriate use of <ALT>, <TITLE>, <LABEL>… (see section 508)
  3. Also, through good copy and design practices
    1. Use elements that help people skim
    2. Use meaningful links

Browsing Patterns for the Blind: What's Different

  1. Environmental Obstacles
  2. Mouse use is not a realistic option for navigation
  3. Users are unable to respond to visual design cues which apply structure to the page
  4. Users cannot get an overview of the page without the help of the screen reader
  5. Screen readers allow someone to skim common elements like lists, links, headers, and form fields &dash; BUT they strip context, which a sighted reader can intuit (not fun for sighted users, either. Ask Krug.)

Designers and Developers Add to the Problem

  1. The issues outlined in Section 508 account for many of the major functional problems
  2. More subtle issues are being discovered with recent usability testing that observes blind users with screen readers (2003, Redish and Theofano)

Quick Summary: Assistive Technologies for the Blind

  1. The Big Players in Screen Readers:
    1. JAWS
    2. WindowEyes
  3. Many, many more screen readers and browsers designed for the blind are on the market:
    1. http://www.w3.org/WAI/References/Browsing
    2. http://www.afb.org/info_document_view.asp?DocumentID=1284
  5. Additional Tools:
    1. Refreshable Braille Devices

The Strategy: What You Need to Get Started

In order to develop a single page which serves both sighted and blind users, we needed the following tools:

  1. A broad and thorough view of the site (what content you have, what content you may have in the future)
  2. Information design underpinnings: an understanding of page types and content types
  3. Visual design decisions: page structure and content presentation
  4. Know what browsers you are building for: choose a support level for your user base

Plan of Attack…

  1. Step 1: Information Design
    1. Determine what needs to be on the page
    2. Organize that into blocks of content
    3. Identify the value of each block
    4. Determine the appropriate order for the blocks to be read (not necessarily the order that they appear on the page)
    5. Document that order as an outline for reference during coding and visual design
  3. Step 2: Visual Design
    1. Work with developer to avoid known complications and maintain the integrity of the outline
  5. Step 3: Develop and Implement Code
    1. Apply Section 508, W3C specs, and interim measures
    2. Apply the outline to make the page read linearly
  7. Throughout: Implement user-centered design and testing as time budget allows during the project

Step 1: Information Design

Determine what needs to be on the page, that is, identify your metadata. This will vary based on

  1. The type of site
  2. The audience
  3. The level of the page (topic, index, article…)
  4. Planned or possible development for the site

You can take your metadata…

  1. Organize that into blocks of content
    1. The blocks should be consistent.
    2. The kinds of blocks may also vary based on the level and utility of the page
  3. Identify the value of each block
    1. Decide what the purpose is for each block of content, and what value they offer to site visitors
    2. Keep in mind the various situations through your site visitors will encounter a page

Determine the Structure

Determine the appropriate order for the blocks to be read

  1. This is not always the order in which they appear
  2. Blocks of content should read logically if you read the whole page, ordered by context and not by the visual layout. For example:
    1. cross-promotional content shouldn't interrupt a story, even if it appears in the body of the page
    2. "print this page" and other article-associated tools should be associated with the article and not with supporting content

Rules, Rules, Rules

Whatever rules you come up with for structure must always be true, no matter the page level

Write It Down!

Document that order as an outline

  1. Whatever order you choose, write it down for reference as you design and develop pages
  2. Include your rationale and note what you want to test
  3. It will be very tempting to make exceptions or to evolve the rules, if you don't write them down

What order is logical?

  1. It may depend on the purpose of your site and your audience
  2. The following arguments are based on our experience managing a large, content-rich site for a broad audience

Some Common, High-Level Blocks of Content

  1. Header
  2. Context
  3. Main Navigation
  4. Body
  5. Sub-navigation
  6. Cross-promotion
  7. Footer

The Header

  1. Including: logo, home link, search, site map, language/country options, and other similar information that's valuable site-wide
  2. Where to put it: Always first
    1. At first blush, it's tempting to think this would be repetitive, BUT users can come into your site at any point.
    2. This information is valuable, and should be presented to blind users as it is to the sighted: at the header of the page.
    3. Tag the header properly, and offer clear tools so that people can skip this if they wish.

Context

  1. Including: page title, topic, "you are in", "see similar" and other such functions
  2. Where to put it: After the header (or possibly after the main navigation, depending on the site structure).
    1. If this is the first page someone sees on your site, context provides them with an understanding of where they are and where they might go from here. This helps folks decide whether this page or this site will serve their needs.
    2. If the user has been navigating through the site to this point, the context provides additional value as confirmation that they've arrived where they intended to by their last click.

Main Navigation

  1. Including: navigation across the site or — on dense sites — within a large topic and back to the main site
  2. Where to put it: After the header or after the context
    1. If the navigation is long or largely irrelevant, consider including it before the context and allowing users
    2. to skip it.
    3. If the navigation is shorter and more topical, then either position might work well.

The Body

  1. Including: article title, byline, date, the main story, supporting assets, pull quotes, footnotes, etc.
  2. Where to put it: After the main navigation and the context.
    1. Repeat the title of the page here, if it is not explicitly a part of the body (i.e., if it appeared separately in the Context part of the page, and the main navigation was listed after the context.)

Sub-Navigation

  1. Including: narrow navigation within the current area of the site
  2. Where to put it:
    1. After the context and the main navigation
    2. Either before, after, as a part of the body, depending on how it relates to the body of the page

Cross-Promotion

  1. Including: links to related information, advertising
  2. Where to put it: After the body, or as a part of the body
    1. On our site, cross-promotion is most often loosely related to the body of the article, and so listed separately after the body
    2. Some cross-promotion may have a particularly close relationship with the content, and should be paired with the body
    3. Commerce sites might mandate that cross-promotion occur in the body

The Footer

  1. Including: links to home, jobs, media, contact, site map, copyright, privacy, and so forth
  2. Where to put it: Last.
    1. This information is conventionally included (or repeated) last on the page, and is expected to appear here.

Building Blocks

  1. The major blocks of content will all be made up of smaller blocks
  2. The smaller building blocks should be defined in the same way
  3. If you explain the purpose of the block and why the information is grouped together:
    1. copy writers and editors will know how to write for the structure
    2. developers can choose the right code to express the structure

Sample Structure Outlines

Let's look at some sample structure outlines, diagrammed visually over existing pages…

  1. The illustrations show four diagrams of pages at different levels within the AARP site: the home page for AARP.org, an editorially managed topic page, an automatic index listing of all content on a topic, and an article page.
  2. On each page, the major blocks of content are identified by color and roman numerals. On each page, the blocks of content which are in use are bolded. The full list of content blocks which have been identified for AARP.org, in the order that they would appear in the code:
    1. Header
    2. Main Navigation
    3. Context
    4. Body
    5. Page Tools
    6. Topic Tools
    7. Cross-Promotion
    8. Advertising
    9. Footer
  4. The diagrams show that:
    1. Not all of the blocks of content are used on all pages: the home page does not use the context, page tools, or advertising blocks; also the topic page and the index page do not use the page tools box. However, they are always coded in the same order and labeled the same thing.
    2. The order of the content blocks does not necessarily correspond to their visual order or placement on the page. For example, even though the context block is visually laid out before the main navigation block on the topic, index, and article pages, the main navigation appears before the context block in the code. Also, in visual design, the "topic tools" block is separated from the cross-promotion block by the body of the page; however, in the code, the blocks are ordered adjacently to one another, both after the body of the page.

Step 2: Visual Design

  1. When you're applying visual design elements, document the purpose for the element so that it can be interpreted properly by your developers.
    1. The structure may be obvious to you, but not to them.
  3. Design to show proper use of links, styles, and copy to work for both sighted and blind who skim
  4. Advise content editors when copy is not accessible for blind users with readers

Designers Beware...

  1. Be aware of design paradigms that are difficult to translate into outline form
    1. Possible ways to handle eclipsed options and tabbed boxes
  3. Be aware of visual and design effects that can't be accomplished by current style specs
    1. Challenging visual design effects
    2. Prioritizing visual design, cross-browser and cross-platform issues, and accessibility
    3. Moving towards style-friendly visual design

Step 3 : Development

  1. Code the page in the order of the outline
  2. Each major section of the outline should be tagged and labeled properly to translate the structure of the outline to HTML
  3. Within each section, use Section 508 guidelines for accessibility
  4. The page should be readable and acceptable without applying a style sheet
  5. Again, warn content editors of inaccessible copy

Comparisons: Illustrations of the change…

  1. Slide one: Before and After (design changes). This slide compares two screenshots of the Older Wiser Wired page on AARP.org, one before the coding changes and one after the coding changes. The exact same visual design was accomplished using the new code. (Minor design tweaks were intentionally made, leveraging the style sheets to allow a more usable web site for the sighted, as well. There are slight copy changes that were made editorially between the two versions, but the copy changes do not change the visual design.)

  2. Slide two: Before and After (code weight changes). Before, the total page weight was 102k; after, the total page weight is 19k. This slide shows two blocks of code, one from before the coding changes and one after the coding changes, both accomplishing the same thing in the web page: a small contact us box, with a text link to email us with questions or comments. The "before" code was 40 lines long, with a complex series of nested tables shown by indentation with each level of nesting, and it included a lot of detailed pixel-level information about the dimensions and spacing of cells. The "after" code is 2 lines long, using only three sets of tags, reading:
    <h2>Contact Us</h2>
    <p><a href="mailto:webupdates@aarp.org">Email us</a> with questions or comments</p>
  3. Slides three and four compare the display of the Older Wiser Wired web page with the style sheet applied, and without the style sheet applied. The version without the style sheet applied reveals a basic, linear web page with black text and blue underlined links on a white background, jump links within sections of the page, the treatment of navigation as hierarchically bulleted links, and the treatment of headers, sections, definition lists, and other copy styles, which are set off by the web browser with white space and different font sizes.

Separation of Content and Design

  1. Now, if we want to update the visual design, all we do is change the style sheet: the code stays intact.
  2. Also, if we find that our arguments for the order of block level elements needs to updated, we simply update the order of the code through the CMS. (The style sheet may need minor updates in terms of relative and absolute positioning, but the design is still in tact.)

Coding Style Sheets…

  1. Build style sheets from the bottom up
    1. Carefully dissect the outline into block-level elements
    2. Use W3C standards for coding structural elements, like paragraphs, headings, subheadings, and lists
      1. Keep the structure transparent
    4. There shouldn't be anything you see visually that you're not coding structurally.
  3. Code it!
    1. Elements and entities can be styled with multiple classes.
    2. Effective use of multiple style sheets.
    3. Positioning hints for wider browser support
  5. See supporting resources for developers

Additional Benefits

  1. Our page size was cut by 80%, from 100k+ to 20k.
  2. 3/4 of our new page size is the style sheet, which is cached — users only download about 5k per page view of code
  3. Better search engine relevance rankings
  4. CMS uses only one template
  5. ANYONE can code these things (less specialized staff, less training with new staff)

Testing and Development

Planning to conduct testing on this

Where you can see it now...

  1. Currently applied to Older Wiser Wired: http://www.aarp.org/olderwiserwired/
  2. Being rolled out across the rest of the site over the next couple of months. See the resources for this presentation to track our progress.
  3. Planning to conduct testing over the summer

Discussion

Discuss issues on design, development, testing, and deployment.

Group Exercise

  1. On the printed web pages I hand out:
    1. Identify the large, high-level structures (starters: header, context, main navigation, body, sub-navigation, cross-promotion, advertising, footer)
    2. Agree on an order
    3. Identify the smaller blocks that make up the larger structures, and their parts, formats, and purpose
    4. Sketch it as an outline, and make sure the outline works with other pages on the site. Identify challenges.
  3. Share your results with another group, and brainstorm.

Resources

"Vision Problems in the U.S.: Prevalence of Adult Vision Impairment and Age-Related Eye Disease in America," copyright 2002, Prevent Blindness America; http://www.nei.nih.gov/eyedata/

Redish and Theofanos, "Guidelines for Accessible and Usable Web Site: Observing Users Who Work With Screen Readers," ACM, 2003. http://doi.acm.org/10.1145/947226.947227

Older Wiser Wired

Get Updates

Join our Older, Wiser, Wired email announcement list.

AARP Membership
About AARP

Policy & Research

Search Policy & Research for the latest AARP Policy and research reports.

Contact Us

Email us with questions or comments