WebAIM Site Redesign
A case study in accessible design

Site Redesign Overview

WebAIM is pleased to present a new web site design, structure, and functionality - launched in June 2006. We hope this site will be more useful to you. Much of the site content has been updated and we now offer additional community tools, such as our online forums and our blog. The WebAIM site has changed significantly since 1999 when our first site went online. This can be seen in archived site versions from the years 2000 - external link and 2002 - external link and from our previous site design - external link which had been in use since Fall of 2003.

This article highlights the process and decisions we went through during our site redesign process. We hope it may be valuable to you in the design or redesign of your accessible web site.

Our Goals

In setting out to redesign the WebAIM web site several months ago, we had a few primary goals in mind:

• Ensure the end result is accessible.
• Provide a visually appealing and easy-to-use site.
• Provide tools and resources that would be useful to end users and help build a stronger accessibility community.
• Maintain standards compliance with XHTML, CSS, and accessibility standards.
• Highlight WebAIM's products and services.

While it's hard to measure success for most of these, we feel that the new site design meets these goals. We view accessibility as a goal that is never fully reached. We know that there is probably much more that we can do to make our site more accessible, usable, and informative. If you have recommendations, please contact us.

The Design Process

The site redesign process has been a long, drawn out endeavor. This is mostly due to other obligations and projects that core WebAIM staff have been involved in. Also, the WebAIM site is a large, complex site with thousands of content pieces, multimedia, interactive functionality, and much dynamic content.

We began by separating out content pieces into individual elements. This allowed us to treat each tutorial or article individually, separate from the rest of the site. This content library was modified to ensure that it was XHTML compliant and properly categorized by topic. We then structured each and every document with semantic elements (headings, lists, code blocks, blockquotes, content elements, etc.) to allow better navigation and later styling. Media elements (images, audio and video files, example files, and downloadable files) were associated with their respective content documents. We now had a library that contained most of the site content in a format that could be 'plugged' into our site template.

Our site templating system was developed in PHP. This template forms the shell which surrounds the content of most every page. The page title, meta information, header, logo, navigation, breadcrumbs, left hand column, and footer are all managed by this templating system. In developing this template, we focused on the semantic structure and accessibility of this template - ensuring that lists and headers were used appropriately and building a navigation and search system that was useful. We also identified content categories, as identified by the tabs at the top of the page. This template system allows us to define basic information about each document (page title, section of the site, breadcrumbs, etc.) and the template system generates the final XHTML code while inserting this information into the appropriate places. This allowed us to begin styling the site without requiring changes on each page. We could make changes in the template in one place and those changes were immediately reflected throughout the entire site.

Once the site content was structured and the site template had been built, we then focused more on styling the site itself - applying the visual design. This involved ensuring that the site was presented visually in a useful and accessible way - that the site was usable to screen enlarging and other assistive technologies. This was done with CSS while only minimally changes were made to the underlying structure of the site or individual content pieces. Because the site template and all articles had been programmatically identified with semantic elements and XHTML classes and ids, it was simply a matter of applying styles site wide. The homepage, having a more complex layout than other pages, was styled separate from the rest.

Design Decisions

Throughout the design process, we were faced with many issues and questions. Often in design and accessibility, there is more than one 'right' way to do things—it is often a judgment call in determining what will result in the 'best' or 'most accessible' product. Here are a few of the decisions that we made regarding our goals, accessibility, and design that were either difficult to make or implemented for specific reasons.

Visible "skip to main content" link

Our previous site design implemented a link to skip navigation that was read by screen reader users, but was not visible on the screen until it received tab focus from the keyboard. This allowed keyboard users to use this functionality, but without impeding on the visual layout of the site for non-visual users. Based upon user testing and a discussion on our e-mail list, we decided to make the skip navigation link visible in our current design. This made it more readily available to ALL users. We also chose to use the wording "skip to main content". We felt that this wording more accurately described the function of the link and would be more understandable to those not familiar with the 'skip navigation' functionality. And because our content articles also contain internal navigation in the form of a Contents section, we decided that 'Skip Navigation' might not be the most accurate way of presenting this functionality.

Using CSS background images

While CSS background images are used fairly extensively in the site template, we tried to use them in only two cases:

1. For non-content elements, such as decorative borders, corners, or other decorative purposes.
2. To provide a more visually appealing alternative to textual content.

In other words, if the site is viewed with styles disabled, all of the content is still visible. Images that convey content are still visible. Images that are purely decorative or do not convey content are not visible as they are applied to element backgrounds in the CSS files. For the navigation tabs, background images were used for visual styling, but the links themselves are actually real text in the source code. When styles are disabled, the navigation appears in plain text. This allowed us to maintain a separation of content from visual display - maintaining logical, structured, semantically useful code while still applying visually appealing graphical elements to the page.

Page navigation

Beyond the option to skip to main content, the site also features breadcrumbs, 'Article Contents', and 'Next' links. The breadcrumbs are presented in the following format:

You are here: Home > Articles > Introduction to Web Accessibility

The "You are here:" text is visually hidden, but is read by screen readers. Because the placement and formatting of breadcrumbs is visually apparent and familiar to most web users, we felt that the information might be visually redundant or distracting, so we hid the text so as to only provide this important context only to screen reader users.

While some argue that an ordered list (perhaps styled to display as shown above) would provide a more semantic structure to breadcrumbs, we decided to maintain a linear presentation and use the > (greater than sign) to designate the hierarchy of elements - Home is greater than Articles or Articles is subordinate to Home. Of note, the > character is read as "greater than" by common screen readers. In the absence of a more formal standard for breadcrumb navigation (or any navigation for that matter), we determined that this format would provide the best user experience.

The 'Article Contents' section at the top of each page provides one click access to any section within the current page or any other page within multi-page articles. While visually displayed with 'block' bullets, the underlying code is an ordered list with nested ordered lists, providing an important semantic hierarchy. The currently viewed page of multi-page articles is identified both visually with an arrow and bold text. Hidden "Current Page: " text, which is read by screen readers and is visible if styles are disabled, also identifies the current page in the Article Contents list.

'Next' links are provided at the bottom of multi-page articles to facilitate easy navigation to the next page. While we debated implementing Previous, First, and Last links as well, we found that the overhead of implementing and using these links was not worth it when the Article Contents provided this functionality in a way that was more useful - these links provide the page title rather than just the word 'First'.

We also simplified the Articles and Resources pages to provide a more useful index of the content available on the site. While the pages are somewhat lengthy, we believe this is easier to use than multiple indexes spread across multiple pages.

No Site Map

While a site map is often a very useful tool, we felt confident enough about the structure and navigation of the site that we believe a site map would just provide an extra level of complexity. Nearly all content is accessible within 2 or 3 clicks of the homepage and we hope the site is structured in a way that a site map is not needed.

No accessibility options

Many sites provide specific accessibility options to give the user the ability to change font sizes, enlarge the page contents, or change contrast settings. While these options may benefit some users, we recognize that they may also be a hindrance and add an additional level of complexity to some user, specifically those with some cognitive disabilities and screen reader users (for whom these options provide no assistance anyway). For these reasons our site does not provide these options. Instead, we have tried to design the site so that it is easily read by those with low vision by using scalable fonts and large line spacing, allows scalability of the text and/or the page itself, and is easily styled by user style sheets. We feel that those that absolutely must have inverted contrast, large fonts, or scaled content will have the ability to do so - and our site fully supports technologies that provide these features without providing them ourselves in a cumbersome or interfering way.

The site also does not have an accessibility statement. While such a statement may be an important legal requirement on some corporate sites, we believe the accessibility of our site and the work we provide provides a stronger statement than we could provide in text.

Page layout

We chose a two column, scalable layout. This layout provides easy access to important page navigation, facilitates better reading with shorter line lengths, and is scaleable in width based upon the viewport width and screen resolution of the end user's browser. It scales downward to 800X600 pixels without horizontal scrolling and allows font size increases of up to around 400% without significant problems in readability or layout. The site uses a Modified Jello Mold - external link type layout, modified to allow greater expandability to the viewport size.

Multiple CSS files

The template system can serve out up to 5 individual CSS files, depending upon which page you are viewing and your browser. The available style sheets are:

main.css

Defines global site settings and layout. It sets the general site design for the template and applies generic styles to things like images and links. It is served to on all pages.

documents.css

Sets all visual styles for the content sections of the site. It defines font styling, line spacing, inline elements, content colors, formatting, etc. It is served to all pages except the home page.

home.css

Defines the more complex layout found on the homepage. Served only on the home page.

ie.css

Fixes some inconsistent styling behavior and fixes a bug that facilitates keyboard navigation in Internet Explorer. Served only to Internet Explorer as detected by a server-side PHP script.

print.css

Print styles that remove non-critical page elements from the print display and formats the page for better printing. Served on all pages, but only applied when printing.

Serving the multiple CSS files allows us to easily make changes that affect only the portions of the site in question. Separating styles for home and documents into separate files saves unneeded styles from being downloaded for pages that do not need those styles.

With the exception of one statement in the ie.css file, we are proud to exclaim our CSS files as 'Hack Free' and standards compliant. While there are plenty of CSS tricks for fixing display issues across various browsers, we spent countless hours in structuring the site and the CSS files so that the site renders almost identical in all common, up-to-date browsers without using hacks or other non-standards compliant code to 'trick' browsers into reading some styles while ignoring others. While some minor discrepancies in visual layout exist, we feel confident in the compatibility and compliance of our CSS files for current and future web browsers.

We made a conscious decision to not take the countless hours to fix all Internet Explorer 5 and earlier and Netscape 4 and earlier CSS display issues. The site is usable on these browsers, but there are some obvious display issues that have not been resolved and probably could only be resolved through CSS hacks.

Target Highlighting

In searching for a way to provide better form error recovery for our contact form (go ahead and try to submit an incomplete form to see how it works), we discovered the Yellow Fade Technique - external link for highlighting and drawing visual attention to page elements. It highlights page elements whose id element matches any anchor name linked to. While using this to implement form error message highlighting, the script was accidentally applied to all pages on the site.

We were later navigating and were surprised to see that the target of Article Contents links were highlighted when those links were activated. Because our in-page navigation and Skip to content links target div elements with unique ids, any time an Article Contents link was activated, the section that was linked to was highlighted. If the skip to main content link is activated, the content area of the page is highlighted. Go ahead and try it by clicking an Article Contents or Skip to content link at the top of this page.

This accidental discovery resulted in some testing and our decision to leave this target highlighting feature active across the site. We believe that it can make the page easier to use, especially to those with certain cognitive disabilities who may have difficulty in identifying the area to which the in-page links are jumping. While this highlighting uses JavaScript, the functionality of the page is not dependent upon it.

Overcoming IE's keyboard navigation bug

Internet Explorer has a well documented bug - external link that in many circumstances breaks the logical keyboard navigation of a page. If an in-page link, such as our skip to main content link, is activated using the keyboard, the browser does not set the tab order to continue from the target of that link. In other words, developers could implement a Skip Navigation link, but keyboard users would still have to navigate through all of the navigation links even after activating the link to skip them.

There are many methods of circumventing this bug, but most involved setting a width to the parent container of the link target or putting the link target in an empty table in your page. None of these seemed appealing as they added unnecessary content or caused problems with the site layout.

While researching the problem, the comments on a page describing the problem - external link documented a CSS expression that sets the tabindex to -1 and triggers the property (hasLayout) in Internet Explorer which enables the tab order to continue from the target of activated in-page links. In our style sheet, it is applied as

.section and #maincontent are the areas which would contain the target id's for in-page links.

While this expression is not standards compliant, neither is IE's bug that causes this problem. The expression is served to Internet Explorer only in the ie.css file and allows proper keyboard navigation to all page anchors.

Conclusion

Accessible design is not a cut and dried process. There are often many difficult decisions to be made - decisions that can affect the ability for potential site visitors to access your site. Perhaps all of our decisions could be improved upon, but we have designed the site with the end user and accessibility in mind. If you'd like to discuss the accessibility of this site or comment on the site design, please do so at our blog posting.