Practical Plans for Accessible Architectures

Written by: Frances Forman

If the relationship between accessibility and architectures intrigues you, see the Editors’ Note at the end of this article for more information about what we’re doing and how to get involved.

The United Nations recently commissioned the world’s first global audit on web accessibility. The study evaluated 100 websites from 20 different countries across five sectors of industry (media, finance, travel, politics, and retail). Only three sites passed basic accessibility checkpoints outlined in the Web Content Accessibility Guidelines(WCAG 1.0), and not a single site passed all checkpoints.

These guidelines are well established and were first advocated by the W3C in 1999. They simplify the knowledge required to produce accessible code and content. Despite developments in assistive technologies and web content, these guidelines are still invaluable today. They provide developers and editors with a foundation for creating accessible design, which is essential to people who have different access requirements. A second version of the WCAG is now available as a public working draft (WCAG 2.0).Nevertheless, a challenge remains in determining which members of the design team are responsible for accessibility. As more people are involved in the design, development, and editorial process, there needs to be agreement on how to best design for content management and customization, while also allowing for greater accessibility.

Accessible design requires a deeper understanding of context. It’s about providing alternative routes to information, whether that route is a different sense (seeing or hearing), a different mode, (using a tab key or a mouse), or a different journey (using an A to Z site index instead of main navigation). However, accessibility is much easier to achieve when the right foundations are put in place as prerequisites during site planning and strategy.

Approaches to Designing for Accessibility


Labeling and controlled vocabularies

Controlled vocabularies can have a positive impact on accessibility by supporting the development of contextually relevant navigation and consistent, understandable labeling. The WCAG 1.0 , Guideline 13 in particular, is written to ensure that navigation is meaningful to people who process information in different ways.

A person using a screen reader can call up a link summary for a given page or tab through links to obtain a general gist of the site. These browsing methods requires web developers to create navigation link descriptions that can be understood without reference to surrounding page context. For example, the purpose of a link should be clear. A user should not have to rely upon nearby visual elements or textual content to understand its meaning.

A dialog showing an automatically generated list of links over the Boxes and Arrows events page

Image 1: A link summary from a Boxes and Arrows page.

Different types of navigation taxonomies allow pages to be defined using both concise and longer contextual link names. This allows naming conventions to retain their consistency and ensures that the right amount of context is displayed across the entire site, not just in the main navigation. For A to Z indexes and site maps, more context is needed to distinguish choices presented to the user. Using contextual names in an index ensures that users are not confused by identical labels that might lead them to different destinations.

Navigation frameworks and wireframe design

When designing indexes and supplementary navigation, it is important to consider how different HTML elements can help shape information. Sometimes headings are a useful way to cluster menus, but it’s often more helpful to make headings active links to prevent important information from being lost.

An easy way to evaluate the hierarchy or order of page elements, such as headers and lists, is to use the “Firefox Accessibility Extension;”: its navigation tool displays the underlying semantic structure and ordering of HTML elements.

A headers dialog showing the structure of the Boxes and Arrows events page

Image 2: Selecting the navigation menu from the Firefox toolbar to display a list of page headers.

When developing a framework for navigation, it’s important to consider how users move between different menu systems. A front end developer will need to determine whether a skip link should read “skip to main menu” or “skip to content”. However, if IAs choose to use several different menu systems—perhaps to maintain organization—they should document the priority of menus and suggest practical uses for skip links. This will help developers define document structure and effectively use skip links. The structure of information elements depends on whether the page is high level and navigation-focused, or low level and content-focused.

The diagram below shows how the tab key allows users to move between links on the Boxes and Arrows events page. The heading levels serve as a guide so users can access menus (with the aid of shortcut keys). This type of semantic markup helps users of assistive technologies navigate more easily. Even if they are using a linear form of access such as audio, it’s possible to skim the page for information.

A page with styling removed and the order highlighted between different structural elements
Image 3: A wireframe illustrates page order and structure, as well as ideas for skip links

Ready deliverables

These diagrams can help web developers define and optimize page structures by organizing information elements early in the design process. Dan Brown’s page description diagrams demonstrate an effective way of communicating information elements, rather than using a set layout to display them.

When wireframing, IAs can use annotations to support designers and developers in meeting accessibility checkpoints. Nick Finck’s wireframe stencils can be used to identify Headings 1, 2, 3, etc., and illustrate how they should be ordered to display a logical hierarchy on the page. For example, the events list above is structured using the H3 tag. Describing each event as a list item conveys that the section is an index of upcoming events. This is beneficial to people who use assistive technologies, as there are commands that allow users to to skim the page from header to header or list to list.

While these approaches are helpful, they are not panaceas. There is ambiguity regarding correct semantic markup for complex pages. Consider homepages, where one may have top story headings, event listing headings, page section headings, and menu headings. How does the developer or designer determine the proper hierarchical structure for headings; how should they simplify the page so its purpose and structure are more understandable?

Widgets vs. Browser functionality

Another debate centers on how and where accessible design should be implemented. Consider text change widgets that enable users to enlarge or decrease font size. Resizing text is better left to user agents and browsers so that content displays more consistently. However, text widgets have become common page tools, as browser-based text resizing is hidden from users and most are unaware of this feature. Solutions to this problem include creating a user help page explaining how browser functionality works, or referring users to sites that explain browser customization and the benefits of assistive technologies. The BBC’s My Web My Way offers such examples. This site provides instructions on changing browser settings, text-background color, font size, and explains how to use assistive technologies.

However, one needs to consider whether its more beneficial to provide instructions, which may eventually become outdated, or direct users to an external site to learn about a particular technology.

Alternative ways to view content

An important aspect of accessibility is providing alternative ways to use and view information. Presenting information in a user’s desired format (indicated by his or her profile) would increase accessibility. Strategies to deliver alternative views include the following:

  • Reuse of information through alternative formats. For example, the ability to change the format of a document on the fly from PDF to RTF or XML is supported by some CMS systems.
  • Google Map’s HTML view conveys information about geographic locations in a format that can be read aloud by a screen reader.
  • Multimedia resources can be made more accessible through the addition of captions or transcripts. Inexpensive, “automated captioning web-based services”: and websites that enable users to “tag video content”: are making translations of this sort easier to implement.
  • Leveraging application programming interfaces (APIs), as “demonstrated by T.V. Raman”: of Google, can produce mashups, which offer alternative ways to view a particular data source. They enhance accessibility by providing customized views when a one-size-fits-all solution does not work. For example, services that offer map data at two times the normal magnification could be a resource for users with poor or corrected vision.

These examples demonstrate that accessibility is not just about compliant code. It requires an understanding of how information can be structured and transformed to make user interaction more flexible.

Customization strategies

Taking the idea of tailoring information access one step further, there is also scope for implementing user profiles or customization strategies to meet a specific audience’s needs. Imagine a website where navigation, search results, and content can all be accessed dynamically according to a user’s barriers to information, content needs, or disabilities.

Hildegard Rumetshofer and Johannes Kepler explore requirements (paid download) for providing comprehensive accessibility as part of a tourism information service. They illustrate how a system could deal with four distinct questions about a person’s information and service needs:

1. Does the tourism service meet individuals’ access requirements? (medium profile)
2. Is the tourism service able to meet individuals’ specific interests? (user profile)
3. Is information presented in an accessible, barrier-free format? (WAI guidelines)
4. Can search or access services be specifically tailored to individuals’ disabilities? (search and metadata strategy)

Accessibility is becoming more dependent on the design of an information system’s components, and no longer a simple question of how content is presented. This is an arena where IAs excel.

Getting started

Understanding the importance of accessibility in the design process is only the beginning. Information architects need to understand accessibility considerations so they can design practical, inclusive solutions. A good starting point is the Web Accessibility Initiative’s (WAI) website and its guidelines and techniques page. The following guidelines provide additional information and resources.

  • Web Accessibility Content Guidelines : 1.0, 2.0 in draft)
    Established checkpoints written for designers and developers to help them create accessible code and content.
  • Authoring Tool Accessibility Guidelines:
    Useful for projects that concern requirements for information management or the procurement of a new CMS.
  • User Agent Accessibility Guidelines: (UAAG)
    Intended for the developers of assistive technologies and browsers, these recommendations can help IAs understand the interplay between different sets of guidelines. For example, some information design problems are better handled by browsers and assistive technologies, while others are better handled by individual sites.


Accessibility audits and benchmarks remind us of the difficulties disabled people encounter when attempting to negotiate their way through today’s online media. Information architects need to think about representing pages of information as linear streams, not just wireframing a collection of adjacent menus and content.

Creating an accessible web experience requires the coordination of independent groups. Initiating, managing, and designing for accessibility starts with strategy and ends with site evolution, content creation, and quality assurance. As IAs we should be advocating, designing, and supporting teams that provide equal access to information, as well as easier access for our primary personas. We should be looking for practical, design-driven ways to make accessibility a consideration through every phase of a project, and not just an afterthought.

While accessibility requires expert web developers to maintain high levels of access (especially on larger sites), it still needs the help of IAs who understand the scope and constraints that lead to accessible design, and who are conscious of the duty to prevent discrimination when making information management decisions.


“BBC’s My Web My Way”:
“W3C Web Accessibility Initiative”:
A to Z Site Indexes

“Somerset County Council”:

Alternative Views on Content

“Google Blog: Web APIs, Mash Ups and Accessibility”:
“Google Video Help Center”:
“Semantic Maps and Meta-data Enhancing e-Accessibility in Tourism Information Systems, IEEE Computer Society”:
“Tagging Multimedia Content”:


“Accessify Forum”:
“Dublin Core Accessibility Metadata Community”:

Debates and Futures

“Accessibility Panel, UK”:
“The Great Accessibility Camp-out”:

Standards and Guidelines

“Introduction to WCAG Samuri Errata for Web Content Accessibility Guidelines (WCAG 1.0)”:
“Web Standards Project”:


Editors’ Note


Our “podcast with Derek Featherstone”: marks the start of a theme for Boxes and Arrows. Accessibility guidelines are not only beneficial to those who need special affordances to experience our products more fully. Taking these recommendations and “web standards”: into considerations will guide what you build, strengthen its inherent structure, and help to encourage the development of better products for everyone.

Over the next several months, we’re looking to further explore these ideas as they apply to designers and the designer-developer relationship. Contribute to the series by sending an idea. (Eds.)