Evaluating Content Management Systems

October 22, 2009 AccessibleWeb@U meeting notes, prepared by Rick Ells

Following the morning's presentation by the Content Management System Working Group at the Web Council meeting, it seemed appropriate for the topic of today's AccessibleWeb@U meeting to be a quick assessment of the accessibility of UW sites discussed in the presentation.

Criteria

Evaluations were done with the FireFox browser equipped with the Web Developer Tools add-on (WDT). In addition, the UW HTML Tidy Web Interface and the Paciello Color Contrast Analyzer were available.

Criteria	Explanation	Procedure (most involve using Web Developer tools)
Presence of Skip to Content or similar method	Help non visual or mouse only visitor get directly to page content	By tabbing and by inspection of page HTML
Use of semantic heirarchical headings to identify page topic, subtopics, subsubtopics, etc.	Voice browsers often can use headings to navigate page	WDT: "Outline -> Outline Headings" and "Information -> Display Element Information"
Linearization,. does sequence of page content make sense to a person encountering the content linearly?	When using a voice browser or navigating a page without a mouse, the sequence in which content will be encountered can determine whether the page is usable.	WDT: "CSS -> Disable All Styles" Turn off CSS and evaluate what displays
Use of semantic markup to enable more meaningful interpretation of content	Semantic element types (paragraph, heading, list, etc.) can be used to better present and navigate through the content.	Visual inspection of content HTML. WDT: "View Source"
Keyboard navigable - Can you effectively navigate the page content without using the mouse	A person with limited dexterity or poor (or no) vision will not be able to use the mouse. Can they still use the site?	Set aside the mouse and try to navigate through site content just using the tab, arrows and space keys
Focus highlighting to make it apparent which element has focus is on the screen	A person navigating without a mouse has to tab to the link they want. Without focus highlighting, knowing where the focus is can be difficult.	Tab through the pages trying to identify where the focus is
Menu functionality without using mouse	Menus that require use of the mouse to select are unusable by people who have vision limitations or dexterity problems	Attempt to navigate menus using tabs, arrow keys, and cursor
Validated HTML	Syntax errors in HTML can produce unpredictable behaviors in assistive and adaptive technologies, not to mention CSS and scripts	Process page with a validator or HTML Tidy
Alternative text associated with graphics, particularly when graphics are used as buttons	Alternative text is displayed or read when the graphic itself cannot be displayed or seen. Purely decorative images can have empty ALT attributes (alt="")	WDT: "Images -> Display Alt Attributes"
ALT Text and Visible text congruence	Voice controlled browing is becoming common. If the text on a graphical object (for example, "Contribute Today") is different from the ALT text for the object ("Give by Friday") the user has no way to go directly to that object.	WDT: "Image -> Display Alt Attributes" and compare text in the graphic to ALT text
Contrast of color combinations	Contrast between text and background should be at least 4:1 for it to be readable by most people. A higher contrast is even better	Evaluate with the Color Contrast Analyzer

Our Procedure

At our October 22 meeting we visited seven Web sites mentioned in the panel presentation, walking through the above criteria with each. The sites visited were the following:

• http://www.uwb.edu/ - University of Washington Bothell home site (CMS: Kentico)
• http://www.foster.washington.edu/ - Foster School of Business home site (CMS: Sharepoint)
• http://wiaproject.org/ - World Information Access project (CMS: WordPress)
• http://ethnomed.org/ - EthnoMed site - Integrating cultural information into clinical practice CMS: WordPress)
• http://www.rad.washington.edu/ - Department of Radiology home site (CMS: Plone)
• http://engr.washington.edu - College of Engineering home site (CMS: Drupal)
• http://f2.washington.edu- UW Finance & Facilities home site (CMS: Drupal)

Important!

The critiques below relate to specific implementations done on the CMS systems, not necessarily to the CMSs themselves. Most CMSs offer many themes, skins, CSS stylesheets, and templates that have widely varying degrees of accessibility. All of these sites reflect a large amount of careful, professional work, often done under considerable time pressure, and we have deep respect for their work. The goal here is to highlight the issues in selecting among all those alternatives for your CMS.

How Did We Do?

• General observations
  • Implementations of Skip-to-Content links varied greatly. The Engineering, Radiology, EthnoMed, and Bothell sites had Skip-to-Contents (EthnoMed and Radiology also defined access keys). The WIA and Foster sites did not have any Skip-to-Content implemented in their headers.
  • Use of semantic heirarchical headings was spotty. The WIA and Engineering sites made good heirarchical use of headings. The Facilities site was inconsistent in its use of headings across pages within the site, with some pages have good h1-h2-h3 heirarchies, some having all h1 headings, and some having no headings in their content.
  • Linearization was good (you could generally view the content only and make good sense of what was going on) but the sites tend to have large amounts of navigation in their headers that would have to be tabbed through if no Skip-to-Content link is provided. The Foster site uses tables for layout, but only at a simple level, providing reasonable linearization.
  • Use of semantic markup varied. The Drupal, WordPress, and Kentico sites made reasonable use of a variety of semantic types. The Foster site pretty much only used tables and unordered lists, with most other content being enclosed in divs identified with the site's own arbitrary system of id and class names.
  • Keyboard navigabiity varied greatly, with several sites have black holes that would swallow anyone trying to use the site without a mouse. In the Foster site, scripting relies on mouseover events. No allowance is made for onfocus events. The EthnoMed and Radiology sites had a common problem: As you tab into the page you reach the Search button. When you trying to tab beyond the search it evokes the search producing a Live Search pop-up box that you can't get out of with just keyboard commands. Search should only be evoked with a Return, not with a Tab.
  • Focus highlighting is turned off on the WIA and Bothell sites (which is done with outline:0 or outline:none styles on anchors), making them difficult for people navigating without a mouse or by voice command to know where they are on a page. The other sites all had focus highlighting on.
  • Menus were variable. Those menus built with simple links worked well. Menus involving scripted or CSS pulldowns had shortcomings. Engineering's menus are almost keyboard navigable, but not quite. Engineering and Foster both have menu systems that work for mouse users but not so well for no-mouse people. Both however have maintained consistent structure within each of the topics so that the items in the left nav of a topic page are the same was in the pulldown menus for the topic. Both sites can therefore be navigated nicely without using a mouse. In that sense you could consider their approach a good example of progressive enhancement methods.
• Recommendations
  • The importance of Skip-to-Content links: Evaluating the sites did make clear the fundamental importance of Skip-to-Content links as the first links on the page. Many of these sites have large sets of navigation links in their headers (one has more than fifty links in its system of pulldown menus). A keyboard user would have to click through all fifty ON EVERY PAGE to find the page content.
  • Focus highlighting is important: Turning off highlighting makes it hard for keyboard and voice command users to know where they are on the page. We are designing dynamic interfaces here, not hardcopy books.
  • We can do better on menus: Good accessible menu systems are available out there that we can use in our CMSs. A good example of a progressive enhancement menu system that works well without a mouse is the Yahoo User Interface library's "Website Top Nav With Submenus Built From Markup" at http://developer.yahoo.com/yui/examples/menu/topnavfrommarkup.html

Accessibility Talkabout

AccessibleWeb@U Meeting, July 23, 2009, Allen Auditorium

This meeting was a Talkabout; an agenda created on the spot (and modified dynamically) and discussions that go where they needed to go.

• Reviewed new DOIT video about accessible design
  • Draft version is at http://uwtvftp.cac.washington.edu/3267DOIT?login=UWTVFTPUser:getmyfile
  • We felt it was a good overall statement of what accessible design is about
  • The final movie will be available through DOIT and UWTV soon
• New UW templates are coming
  • The Web Council met this morning to hear progress on the new Web look for UW sites. HTML and CSS should be available by sometime in September.
• Puzzle of site design development process: Why are accessibility considerations coming so late in the process?
  • Professional design process now often involves doing mockups with Photoshop, getting approval, then handing the Photoshop file to a coder
    • A variety of PSD to HTML conversion software and methods are available. See... http://net.tutsplus.com/site-builds/from-psd-to-html-building-a-set-of-website-designs-step-by-step/
  • The method can work if both the designer and the coder are knowledgeable in accessibility and usability considerations in Web design
  • On the other hand, the process can produce fiat accompli designs that are hard to make usable or accessible
    • Narrow scope thinking in each step can miss opportunities for better design or deliver non-negotiable features to the next stage in the process
    • Design thinking insensitive to Web technology can result in features that can only be created with coding kludges (non-semantic markup, place-holder objects, complex div structures, etc.) which defeat accessibility and usability goals
    • Design conventions (habits) tend to be used to justify less usable/accessible design; it is safer to do what other people are doing (such as fixed width, fixed font-size, low contrast design) rather than use a goal-oriented criteria-based design process
    • Best design process has the following:
      • Clearly stated usability and accessibility goals, such as contrast, semantic markup, intelligible flow of content, and simple structure
      • Good, on-going communication between customer, designer, coder, and tester
      • People in the team with good knowledge of usability/accessibility who are empowered to direct attention to any problems and work with team toward good solutions
• "Flexible Web Design: Creating Liquid and Elastic Layouts with CSS" by Zoe Gillenwater
  • Dylan is currently working his way through the book and recommends it
  • Flexible designs work better on a wider range of devices and allow the user more control of how they interact with the site, such as by scaling to an appropriate font size for their needs
• Scripting issues and developments
  • Designing for mobile devices
    • Good structural flow helps; zooming in and out and scrolling around is time consuming
    • Buttons and other clickable areas should have sufficent size
    • Scripting needs to consider limited scripting feature set of many phones
      • Google is now offering the iPhone User Interface (http://code.google.com/p/iui/) to faciliate creating sites with Google features for iPhones
  • Progressive enhancement (PE) scripting has major accessibility benefits
    • PE methods usually involve scripting that operates on html content, such as displaying content in an unordered list as a menu. If the scripting cannot be read, the content is still available in the HTML, which everything can read
    • Yahoo User Interface library (developer.yahoo.com/yui) offers PE versions of many of its scripts for menus, collapsible lists, and other functionality
    • JQuery (jquery.com) has PE methods (for an example, see http://www.kelvinluck.com/2009/02/progressive-enhancement-with-jquery-example/
• Future AccessibleWeb@U Meetings
  • August - No meeting currently planned
  • September - Libraries AccHack
  • October - Accessible scripting principles and examples
  • Social Networking with Accessiblity people

AccessibleWeb@U — June 25, 2009

• Special thanks to Christine Tawatao and University Libraries for making the Allen Auditorium available for our meetings. The Auditorium is reserved for AccessibleWeb@U the fourth Thursday of each month, 11:30am to 1:00pm.
• Projects
  • Dylan looking into use of ARIA in pulldown menus. Hopes to be able to report by Fall
  • Dan interested in testing scripting packages, such as menus, with JAWS

---

Making Accessible Drupal Sites

Rick Ells UW Technology

About Drupal

• Standards Based; xhtml, css, PHP
• Large user community
• Many templates to choose from
• Many modules to choose from

Drupal Is Cool

• Centralized management
  • Templates and modules
  • Styles
  • Scripting
• Content creation, editing, and maintenance can be done without technical Web knowledge
• Changes in styles, layout can be done across the site without content maintainers involvement

More Cool

• Information management
  • Categories
  • Taxonomies
  • Keywords
• Navigation structures generated for you
• Easy to add Web2.0 features

Even More Cool

• Authentication, roles
• Workflow
• Customization based on default designs, templates, styles
  • Intercepts, overrides, and subthemes

Being Accessible

WCAG 2.0 Guidelines

• Perceivable
• Operable
• Understandable
• Robust

Web Content Accessibility Guidelines (WCAG) 2.0 http://www.w3.org/TR/WCAG20/

Accessible Design Efficiency

• Templates, stylesheets, modules can address many aspects of accessible design
• Content authors and editors do not have to know as much about?
  • Skip to content
  • Font sizing
  • Color choices
  • Labeling, Alt texts
  • Semantic markup
  • Page layout

Steps to Accessible Design

1. Install
2. Update
3. Select theme
4. Add modules
5. Build blocks
6. Apply your design

1. Install

• Installing Drupal http://www.washington.edu/computing/web/publishing/drupal.html
• SQL Database http://www.washington.edu/computing/web/publishing/mysql.html

2. Update

• Updates are essential
• Each time the administrator logs in Drupal will display messages of needed updates
• Do them promptly

3. Select Theme

Tables or tableless?

• Tableless layouts best, especially if fluid
  • Controllable with CSS
  • Reading order can be independent of layout position
  • Fluid sizing allows scaling by user as needed
• Table layout not so good
  • Imposes reading sequence
  • Presentation only somewhat controllable with CSS
• Nested tables bad
  • Navigation nightmare
• Many theme design philosophies, which is why so many themes are available

Managing Themes

Accessible Themes

Box_grey Theme, Blue Bars Theme, Blue Lake Theme, Celju Theme, Clean Theme, CWS Theme

The Eleven Most Accessible Drupal 6 Themes http://openconcept.ca/blog/mgifford/function_assessment_of_valid_drupal_6_themes

Theme Problems

• Non-nested use of h-elements
  • One h1 per page; main topic
  • h2; subtopics
  • h3; subsubtopics, etc.
• Inconsistencies among modules in how headings are done
• Deeply nested tables
• Not specifying default language

4. Add Modules

• Hundreds of modules are available
• Offer a wide range of functionality
  • Editors, games, feeds, tools
• Most are standards compliant
  • Problem: Inconsistent implementations among modules
• Frequently updated

Managing Modules

5. Build Blocks

• Blocks contain the code fragments for the different areas of your layout
• Blocks are placed in page regions
• Must be well-formed and strictly compliant to fit in context
  • Structured, semantic markup very desireable to get CSS to work
• How you add things like "Skip to Content"

Semantic Markup

• Use elements according to their logical type
  • Make headings with h-elements, not big bold paragraphs
• Properly nest h-elements
  • H1 is the main page topic, h2s are subtopics, h3s are subsubtopics, etc.
• Choose a content editor that makes semantic markup possible, even if you have to go into html mode sometimes

6. Apply Your Design

• Use subtheme, intercept, and override methods
  • Never modify original templates, stylesheets
• Customize templates
• Customize CSS
  • Layout adjustments
  • Color scheme
  • Font size
  • Contrast

Color Scheme

Color Selection

• Consider the colorblind; about 9% of men and 1% of women are colorblind in some way
• Wickline Colorlab makes it easy to see hour your color set will appear to people with different kinds of colorblindness — http://colorlab.wickline.org/colorblind/colorlab/

Color Scheme

Contrast

• 5:1 contrast ratio between text and background is recommended
• Paciello Group Color Contrast Analyzer can be used to quickly evaluate color combinations — http://www.paciellogroup.com/resources/contrast-analyser.html
• Minimum Color Contrast Ratio — http://www.joedolson.com/articles/2008/12/minimum-color-contrast-ratio-changed-in-wcag-2/

Maintaining Accessibility

Do

• Validate all modifications — be sure everything is strictly compliant
• Choose editor that makes semantic HTML
• Consider content flow in page structure
• Add aids such as "Skip to Content"
• Use semantic markup
• Use scripting libraries and methods that support accessibility

Don't

• Invent non-semantic elements (divs) when appropriate semantic elements are available
• Use fixed sizes
• Reduce contrast for artistic effect
• Put essential content exclusively in media
• Have visual media without captioning

Drupal Accessibility Activity

• Accessibility Group — http://groups.drupal.org/accessibility
• The Eleven Most Accessible Drupal 6 Themes — http://openconcept.ca/blog/mgifford/function_assessment_of_valid_drupal_6_themes
• Accessibility Best Practices in Drupal Theming — http://szeged2008.drupalcon.org/program/sessions/accessibility-best-practices-drupal-theming

Evaluating Your Drupal Site

• WAVE — http://wave.webaim.org/
• Functional Accessibility Evaluator — http://fae.cita.uiuc.edu/
• WebAnywhere — http://wa.cs.washington.edu
• Yellowpipe Lynx Viewer — https://addons.mozilla.org/en-US/firefox/addon/1944
• Wickline Colorlab — http://colorlab.wickline.org/colorblind/colorlab/
• Paciello Group Color Contrast Analyzer — http://www.paciellogroup.com/resources/contrast-analyser.html

Discussion

• Editors available for Drupal
  • A variety of editors are available as modules that are easy to add to Drupal.
  • FCKedit — http://drupal.org/project/fckeditor
  • YUI Ric Text Editor ‐ http://drupal.org/project/yui_editor

Visual Cues for Keyboard Users, Higher Education Web Pages

AccessibleWeb@U - April 29, 2009
Present: Terrill Thompson, Bill Corrigan, Wendy Chisholm, Chris Whip, Dylan Wilbanks, Ryan Benson, Karen Rosenstiel, Rick Ells

Quick Items

• We need a larger meeting room for our monthly AccessibleWeb@U meetings. MGH 015L is central, well equipped, free thanks to UW Technology, and usually available, but attendance has been up and we need more space. If you know an appropriate room we can reserve, or if your department is interested in sponsoring the AccessibleWeb@U meetings, please send a message to the rells@u.washington.edu or to the accessibleweb@u.washington.edu list.
• May's AccessibleWeb@U topic will be "Creating Accessible Sites With Drupal." If you are interested in the topic and want to participate in the discussion as we develop the talk, send email to rells@u.washington.edu.

Visual cues for keyboard users

Ryan Benson demonstrated CSS methods for highlighting links when they have focus to help keyboard-only users know where they are on a page.

• Most designers have some kind of highlighting when mouse users hover over a link, but do not provide highlighting for keyboard who tab to a link
• CSS style could be
  a:hover, a:visited:hover, a:focus, a:visited:focus, a:active,
  a:visited:active { whatever style makes anchor clearly visible }
• Highlighting effect for hover and focus can be different since hover is for mouseovers and focus is for keyboard users who tab through anchors.
• IE behavior for focus different
  
  
  • Focus works on most browsers, active is what works on IE
  
  
  
• Border of an anchor that wraps looks broken - border is open at end of one line and beginning of next line
  
  
  • Could add more padding so that the text can wrap within the anchor
  • Could enclose anchor in a div and put the border on that
  
  
  
• Dan Comden prefers use of a border instead of a background for the focus effect because other access technologies use a border to highlight your location on a page.
• Keyboard users could have their own stylesheet with styles for their particular needs
  
  
  • Wayne Dick offers stylesheets for people with disabilities http://www.calstate.edu/Accessibility/webaccessibility/evaluation/lowvis.css
  
  
  
• How visible should the border be
  
  
  • Strong or dark color?
  • Subtle color?
  • Looking for an effect that is not jarring to non-keyboard users but works well for people who are keyboard users
  
  
  

Longitudinal Research Project Looking at Home Pages of Higher Education Institutions - Terrill Thompson

Terrill is looking at Higher Education home pages as a followup to a study he conducted in 2004-2005.

Issues

• Alt tags for images; Menus built with images that have no alt text become unnavigable if images cannot be displayed
  
  
  • DreamWeaver now prompts for alt text
  • Evaulation Method: Used Web Accessibility Toolbar (WAT) on IE http://www.paciellogroup.com/resources/wat-ie-about.html to generate a list of images and their alt texts; critiqued the use of alt texts for meaningful texts, proper use of null texts. (A similar toolbar is available for FireFox at http://firefox.cita.uiuc.edu/)
  • Survey of alt text usage in 2004-05 was 27% proper; current survey found rate of proper use has risen to 41%
  
  
  
• 'Skip Navigation' link
  
  
  • Western Washington University (http://www.wwu.edu/) has a 'Skip to News' link
  • Skip-to's usually are styled to become visible when they have focus
  • How many skip links do you want (Skip to menu, skip to content, skip to news)? Too many skip-tos become a menu to the page content structure.
  • Many people do not know that some browsers have skip navigation built in (such as skipping to headings)
    
    
    • Good heading structure helps meets the need for people finding different parts of the page, even if there are no skip-to links
    
    
    
  • Evaluating Coded Navigation (navigation within the page)
    
    
    • Used WAT to show internal links, display heading structure
    • In 2004-05 7% had skip to content; In current survey 19% of home pages had skip to content
    • 'Skip to Main Content' is apparently the preferred phrasing
    • In current survey 45% of sites are correctly using html headings (using headings in logical structure way)
    
    
    
  
  
  
• Navigation
  
  
  • Evaluation - Using IE, mouseover controls to see if there are dynamic behaviors, is there a visible effect to help mouse users, is there a visible effect for keyboard users
  • Menus created with Javascript may not be identified as links in assistive technologies
  • In original study, 78% if pages were keyboard accessible; in this study 65% were keyboard, if visual focus is not considered
  • 13% of sites provided visual focus for keyboard users
  • 39% of home pages have dynamic scripted menus; often implemented without evaluation of accessibility impacts
  
  
  
• Use of Flash
  
  
  • Can be accessible, if you know what you are doing
    
    
    • Go to an object, press Shift-F11, enter label
    
    
    
  • JK Rowling site: http://www.jkrowling.com/accessible/en/ Entirely done with Flash. Nice accessibility features
    
    
    • sounds have accompanying texts
    • clues of what to do next
    • accessibility tools, gives keyboard controls for JAWS, WindowEyes
    • exploration model, lots of stuff that you can explore
    
    
    
  • Not so good Flash example
    
    
    • Lower Columbia College http://lowercolumbia.edu/ Has nav with buttons buttons to advertise events, but does not say what ad you get to if you click a button. Lots of buttons, no labels
    
    
    
  • In this study, 38% of home pages included Flash; only one site labelled the objects (Lane Community College http://www.lanecc.edu/) but the pages lack a heading structure
  
  
  

Summary

• Fewer than half of web pages are accessible by any measure
• Accessibility is improving in some areas (alt texts, headings, validation)
• Accessibility is getting worse in other areas (navigation)

Discussion

• Navigation accessibility problems often appear when site uses packaged menu scripts and (1) selects a package not designed for accessibility, (2) improperly configures the menus even if it is, or (3) breaks the accessibility features as the menus are evolved over time.
• AccessibleWeb@U could hold sessions on accessible menus, accessible use of Flash and SilverLight, and creating accessible sites with content management systems.

Building an Acessible Site From the Ground Up

AccessibleWeb@U Meeting Notes, March 25, 2009

• Building an Accessible Site From the Ground Up
  
  • Goal is to create a new Web site for the Development & Behavioral Pediatrics, currently at http://depts.washington.edu/dbpeds
  • Current site was developed by Dr. Samuel Zinner
    
    • The site built on SimpleSite, which is going away, prompting the need to build a new version.
    
    
  • Want an improved site
    
    • More usable
    • More visually pleasing
    • More compliant to ADA
    • Take into consideration people with cognitive disabilities
    • Sites Dr. Zinner likes
      
      • http://youthhood.org/
      • The http://dictionary.com/ family of sites
        
        • In set of sites, each has a different color
        • Each page is entirely viewable without scrolling
        
        
      • http://cshcn.org/ - Children with Special Needs
      
      
    
    
  • Development work on the site will be done by Yuka Tsukamaki and Preethi Dutta, graduate students of the U.W. Information School, as part of the Capstone program (http://www.ischool.washington.edu/msim/capstone/)
    
    • Working with Yuka and Preethi are Faye Louie (CHDD) and Seiya Urae (Medicine)
    
    
  • The current site has many links in the left column. Key features of the site are the following:
    
    • Clinics and Activities
    • Schedules
    • Advocacy Opportunities
    • Training Modules at other sites
    • Featured Articles
      
      • Commenting on how press has spun stories, linking to more valid articles
      
      
    • Resources for Community
    • Screening & Surveillance Tools
      
      • Want to teach physicians better earlier screening and identification
      • Some are copyrighted, protectd by password
      
      
    
    
  
  
• Discussion
  
  • Find out how the current site is being used
    
    • Catalyst system gives you number of site visits but not page stats
    • People not necessarily going through home page
    • 2/3 of School of Public Health site visits do not go through home page
    
    
  • Could add Google Analytics (http://www.google.com/analytics/) to the current site to collect data until the new site is built
    
    • Requires adding Javascript at the bottom of each page you want to collect visit data on.
    • Goal is to find out who actually is visiting the site and what they are looking at
    • Google Analytics not only gives page visit counts but also gives breakdowns of who is visiting
    • Who is your real audience at present? How does the current audience compare to the audience you want to reach?
    
    
  • Evaluate your content
    
    • What are the unique things people might look for on your site?
    • How good is your site technically. For example, are there dead links?
      
      • Xenu's Link Sleuth (http://home.snafu.de/tilman/xenulink.html) is a free tool that can check links
      
      
    • How well written, edited, and polished is your content
      
      • Is the style consistent throughout the content?
      • Is there consistent voice and role in the writing?
      
      
    
    
  • Define the purpose of site
    
    • Be clear about priorities and audiences
      
      • Work on a statement of Priorities and Audiences; put it in writing, pass it around
        
        • Clarify what parts of content are for the department and what parts are for outside audiences (audiences, therapists, parents)
          
          • Separating departmental/staff content from content for outside audiences might be a basic concept in your design
          
          
        • What types of user needs do you most want to support
        • Articulate priorities and rank them relative to each other
        
        
      
      
    
    
  • State any considerations
    
    • Do HIPAA health information privacy laws apply (http://www.hhs.gov/ocr/privacy/)?
    • Intellectual property ownership
      
      • Is any content on the site copyrighted? Do you have permission to distribute the content (you do not need permission to just link to things on other sites)
      
      
    • Privacy
      
      • Doctors' schedules; can they be public?
      • Doctors' contact information; can it be public?
      
      
    
    
  • Assess the resources available to maintain the site
    
    • How much manpower will be available to maintain the site once it exists?
      
      • About four people maintain the content of the current site. All four have lots of other things they are involved in.
      
      
    • What implications does the amount of manpower have on what you want to try to do in building the site?
    
    
  • Consider a Content Management System
    
    • Drupal (http://drupal.org/) is used by many groups at the UW, including Facilities
      
      • Free, has a good, active support community
      • Relatively simple to install, comes with a variety of designs (themes) which can tweaked easily
      • Drupal can be installed and run on the depts.washington.edu server
        
        • Instructions are at http://www.washington.edu/computing/web/publishing/drupal.html
        • Requires MySQL, which is also available on the depts server (http://www.washington.edu/computing/web/publishing/mysql.html)
        
        
      • Drupal is not a centrally supported service. Once it is up your are on your own to maintain it
        
        • Periodically updates must be installed
        
        
      • Several groups on campus can do Drupal themeing
        for you (for a fee)
        
        • UW Creative + Communications; http://www.washington.edu/admin/pubserv/
        • UW Creative; http://www.uwcreative.com/
        
        
      
      
    
    
  
  
• Designing a Web site for people with special needs
  
  • Good accessible design resources at on the UW IT Accessibility site at
    http://www.washington.edu/accessibility/
  • Topics
    
    • Font size
      
      • Flexible web page designs (sizes and dimensions are set with relative measures such as percents and em-spaces) allow the user to adjust the font size to what is comfortable for them
      • Fixed font sizes, especially if the size is small, can be a big obstacle
      
      
    • Colors
      
      • Be wary of red/green color combinations; 10% of men are red/green
        color blind. You can check color combinations with VisCheck (http://www.vischeck.com/)
      • Provide sufficent contrast (at least 5:1) of words on their background. You can evaluate the contrast of color combinations with the Colour Contrast Analyzer (http://www.visionaustralia.org.au/info.aspx?page=628)
      
      
    
    
  • Basic steps
    
    • Choose a version of html or xhtml and stick to it
      
      • We suggest XHTML
      • Write to the standard, not to a specific browser
      
      
    • Write compliant code; code that is correct according to the version of html/xhtml you are using. Validate your code frequently as you work on it.
    • Use semantic markup; XHTML has predefined logical element types such
      as paragraph, h1 headings, and ordered lists. Using these elements as they are intended to be used means each block of text has a declared logical type that can be help assistive software interpret the page and present it intelligibly to the user.
    • Use a simple page structure; pages are made up of a number of divisions such as header, left-column, content, right-column, and footer.
    • Separate content from presentation; put page content into semantic xhtml and control presentation on the page with CSS stylesheets
    
    
  • Methods
    
    • Avoid opening in new window
    • ALT tags on each graphic, alt="" (an empty ALT) for non meaningful graphics
    • In forms, use LABEL to relate titles to form fields
      
      • See
        http://www.webaim.org/techniques/forms/controls.php
      
      
    
    
  • Cognitive disabilities
    
    • General information is available from WebAIM http://www.webaim.org/articles/cognitive/
    • Spacing between lines can help readability; tight text and long text
      lines can make reading difficult
    • Addressed in Web Content Accessibility Guidelines v.2 (WCAG2)
      http://www.w3.org/TR/WCAG20/
    • Use of language; use simple language with words with few syllables
      
      • Good guidelines on simple writing are on the Plain Talk Web sites
        
        • http://www.accountability.wa.gov/plaintalk/ptguidelines/ and http://www.plainlanguage.gov/
        
        
      
      
    • Use ABBR element (http://www.w3schools.com/tags/tag_abbr.asp) to spell out what an abbreviation stands for, text appears when you hover over the abbreviation
    • Different parts of site may be developed for different audiences, with different vocabularies
    
    
  
  
• Search engine optimization
  
  • Meta elements (http://www.w3schools.com/tags/tag_meta.asp) in Head of a Web page helps searches recognize what the page is about, but you want to have the right vocabulary and not too much of it
    
    • Google Search penalizes pages with too many Meta words, particularly if they repeat
    
    
  • Recognize that Headers (h1, h2, h3, etc.) have significance to assistive technologies, which will interpret
    them as the topic, subtopic, subsubtopic, etc. of the page content
    
    • Voice browsers allow the user to navigate the page by the headers. Logical headers help the user go quickly to the content they are looking for
    
    
  
  
• Common problems
  
  • Pages do not have navigation; not clear who owns it, what context it is in
    
    • Have information in page, such as in the header
    • Identification does not have to take up much space; a linked logo in an upper corner may be sufficent
    
    
  • Important to have consistent layout so people have an idea of what to expect
  • Important information is only in graphics, such as PowerPoint slides; have the information in the page HTML too.
  • When people print a page, is it readable; have a print stylesheet that formats it for hardcopy use
    
    • Be sure the printout has the URL of the page
    
    
  • Drop down menus can be inaccessible
    
    • There are methods for doing drop-down menus that are accessible and methods that are not accessible
      
      • Generally the most accessible drop-down menus use progressive enhancement coding techniques, such as the Yahoo User Interface (http://developer.yahoo.com/yui/menu/)
      
      
    • How do people with cognitive difficulties work with menus is an open questions; research needed!
    
    
  
  

WebAIM Screen Reader Survey

Many of you know WebAIM (Web Accessibility in Mind) as one of the most complete and best maintained sources of good information on accessible design topics. In December and January, WebAIM conducted a survey of preferences of screen reader users relating to Web design and Web technologies. The survey collected 1121 responses from people with various disabilities. See WebAIM: Screen Reader Survey Results I found the results to be quite useful:

• Headings really are important: "It is clear that providing a heading structure is important to screen reader users with 76% always or often navigating by headings when they are available." 90% of the expert users used headings always or often.
• Site maps were not particularly useful: "The majority of respondents seldom or never use site maps."
• Pop-up windows are difficult for less proficient screen readers to deal with. More proficient users had much less difficulty.
• Photos should be identified as such in their alt text, rather than just described with brief text: "It was very clear that the vast majority of screen reader users prefer to have photos identified as such. Interestingly, those that do not have a disability were three times more likely to prefer the briefer alt text than those that do have a disability."
• Flash is difficult for screen reader users: "71.5% of screen reader users reported that Flash is difficult while only 14.2% reported that it is easy."
• Frames are not that big of a problem. "While the majority (58%) of users reported that frames are easy, those that are blind were 3 1/2 times more likely to indicate that they are easy than those with no disability."

Clearly, Web accessibility evaluator's rules of thumb (i.e., Frames are not accessible) can be simplistic or misleading . I encourage everyone to read through these results carefully. And I would like to send a hearty thanks to WebAIM for conducting the survey!

First Access Hack Session

For our first Access Hack Session, Dylan Wilbanks of the School of Public Health gave us a tour of their site, explaining its design and accessibility features. A lively discussion followed about the methods used, issues they raise, and other methods the Dylan might want to explore for the next site update. Detail discussion minutes are available.Take a look at the site, review the minutes, and add your thoughts.