The University of Washington Home Page was recently designed with a new look for external audiences. What many people notice as different is the background and the lack of a cambot. However, there are many more changes behind the scenes.
With the previous home page, the goal was to make sure the page looked its best on all browsers that were version 4 or more recent. For the current home page, the bar has been raised to browsers that can support Cascading Style Sheets (CSS) level 1, which means that version 4 browsers get a usable page which is very plain with no styling. However, new features were not used if they caused older browsers to become unusable.
The UW Home Page implements features for accessibility, such as text labels for all pictures and summaries for all tables. Two strategies were used to ensure accessibility. First, tools were used for evaluation, and then manual checklists were used to catch issues that can't be sufficiently evaluated by tools. The automatic checks by the software tools all passed, so most of the time was spent doing manual checking.
Several software programs were used. The first was Wave 3.0. Several elements required manual checking, including layout tables, alt text, null alt text, mouse-overs, and Javascript elements. These elements are all used appropriately. In the future, we hope to have "onFocus" working (consistently on all major browsers), so that the flyout menus are accessible to keyboard-only use, but for the meantime, we have a redundant alternative, given that the main topic page contains all links in the flyout menus.
The second software program was UsableNet tool, UsableNet's Accessibility Suite extensions. The free LIFT online report was used. Manual checks were required for a number of items. These were for the need of longdesc (long descriptions when alt text is not sufficient - not necessary for the photos we have), use of null alt text for images used for arrows and flyout triggers, Javascript elements, layout tables, alt text for images, possible use of Javascript for causing the screen to flicker (not the case), possible need for NOSCRIPT with the flyout menus (not necessary because the content is repeated on the main topic page), the ability to use the page without stylesheets, any changes in language (not the case), the use of clear language (with the dark background, text is kept short), color contrast between text and background (checked by printing to a black and white printer and then copying the printout three times), that information on the page does not rely on colors, that the NOSCRIPT used for the images was equivalent (it loads one image, rather than a rotation).
Obviously this was a large number of manual checks, and we met these as we were able. The color contrast check was less successful on the 2nd and 3rd copies of a black and white printout, especially for visited links. We did have Dan Comden, our accessibility expert, review the colors, and he said they were fine, and that it degrades well when style sheets are turned off. However, we then also made the topic menu fonts bold, as well as the Quick Links fonts. This did improve the results of the color contrast text. Otherwise there were no major or minor issues found by the program.
Finally, Bobby was used. Many of the manual checks had already been required by Wave and Lift, so only those that were different are mentioned here. These include the use of relative sizing and positioning (absolute sizing was used for padding and images and does not interfere with scaling the page layout), link titles (titles were added to graphics, but didn't seem necessary for text links), a site map or table of contents (we don't have, but we'll need a sustainable way of creating one), that the document validates to a formal, published grammer (XHTML 1.0/Strict), related elements are grouped (global tools, main topics, quick links), a consistent navigation structure (header with global tools and footer), to use ABBR and ACRONYM elements to denote abbreviations and acronyms ("UW" is used, but "University of Washington" is also spelled out in the signature and the footer), a way to bypass grouped links (we're looking at this one), identified groups of links (done with div and table tags), keyboard shortcuts for frequently used links (this seems problematic for a site with so many occasional users), distinguishing information at the beginning of headings, etc, different types of search available (Google has simple and advanced features), navigation bars (we have one), customization of page (we don't have this, but it's possible with MyUW), consistent style of presentation between pages (administrative pages have a common header with logo, navigation bar, and footer, but subelements can vary greatly).
Of the three programs used, Bobby had the widest-reaching and most difficult-to-assess requirements, especially for priority 3 guidelines. However, it was also the most complete in its manual checks. A final note on accessibility software programs: it's likely easier for the casual developer to use a manual list, such as found at the UW Accessible Web Sites page. Any software evaluation will require manual checking in any case.
To summarize, the UW Home Page has been coded to be as accessible as we can make it, given the constraints, and we'll continue to review any specific issues as they come up.
All positioning, spacing, fonts, colors, and decorative lines are done with CSS. The drop shadows on the main, landscape picture, as well as the news item, are also achieved with CSS.
The home page uses the same style sheet as other pages on the site, but it overrides the colors of the main text style since the background is dark rather than light.
The UW logo is made up of multiple images, and the hover effect for the Bothell and Tacoma campuses is achieved with CSS.
CSS is also used to style the two lists of links (the main links under the logo, as well as the Quick Links). Browsers not supporting CSS see an unordered list, including the contents of the flyout menus.
The style sheet is disabled for browsers which do not support at least a minimal amount of CSS level 1. These older browsers also see a warning box explaining why the page looks unformatted.
The new home page validates as XHTML 1.0/Strict.
Javascript is used in many different ways on the home page. The landscape and portrait pictures are randomly selected each time the page is displayed, utilizing Javascript to choose the images. If Javascript is not available, a static image is displayed. This script is custom-designed for the UW Home Page and its environment. If you wish to have this functionality on your own page, you will want to do an internet search on "javascript random image". One example is at ComputerHope.
Javascript is also used for the flyout menus. If Javascript is not available, the links still work. If the browser also does not support CSS, then the contents of the flyout menus will appear as lists.
On the server side, PHP is used to generate the Javascript that displays random images. The PHP script reads a file that defines each image and which images go with others, and emits Javascript that defines tables with the images listed, as well as Javascript functions to randomly select and display the images. This method was used because the list of images can be updated without actually updating the home page.
The UWIN page currently fetches an XML news feed from News & Information, and the Home Page news item is automatically selected from those items. If a special alert is posted, that overrides the news item.
While chtml is not used by web servers to serve the home page, it is used to generate that page on a periodic basis after the news items are automatically inserted. This means that the home page uses the same header and footer files as all other pages.
The home page is functional on all tested browsers, but it has its best appearance with browsers built on the Gecko engine (such as Mozilla), browsers built on the KHTML engine (such as Safari and Konqueror), and Internet Explorer version 6 and up (although version 5 should also look correct.)
Those browsers which do not support at least a minimal amount of CSS level 1 (such as Netscape 4 and below, and Internet Explorer 4 and below) are still fully functional, but show a plain, non-styled page.
Browsers with smaller installed bases should work depending on their level of CSS support. For example, Opera 5 and up displays as intended, but OmniWeb 4.1.1 does not show the complete wrapping line.
The flyouts work with DOM-based browsers, IE 4 and up on Windows (IE 5 and up on the Mac), Netscape 4, and Opera. For the home page, the flyouts are disabled for non-CSS browsers.
