This is a follow-up to my previous post that described my second structured assessment of cognitive Web accessibility.  The work’s progression can be seen via this blog’s Category of Cognitive Web Accessibility Assessments.

Assessment Scoring System Needed Revision

The result of the second structured assessment was that the Web site was inaccessible to people with developmental disabilities.  Had I followed my original assessment plan, the result would have been the opposite.  This is because of the plan’s scoring system.

I had intended to score one point if any Web site feature met even one guideline of each of the sections of WebAIM’s Cognitive Web Accessibility Checklist. While following this system during my second structured assessment, I realized it was too generous.  Points were adding up although it was obvious to me the site was likely inaccessible by people with developmental disabilities.

Consequently, I decided to average the number of guidelines that were met (successes) with those that were not (failures) for each checklist section.  Arbitrarily but within reason, I also decided an average success of 80% or higher would score one point.  I will apply this standard to future assessments unless I learn it is unworkable.

Assessments Require Significant Effort

When I developed my original assessment plan for 100 sites, I had been hoping the work could be performed quickly.  That was naive.  I now recognize much more work is needed.  Every relevant guideline in all of the checklist sections must be evaluated to portray a site’s cognitive Web accessibility as well as possible.  Indeed, because I evaluated all the relevant guidelines in the last (and only) structured assessments, comprehensive portrayals of the sites’ cognitive Web accessibility were produced.

Assessments Should Be Performed By Users

The cognitive accessibility of Web sites would be best assessed by users with cognitive disabilities.  I was reminded of this by Joe Chidzik after I posted my second structured assessment.  Specifically, his message was, “A site may be *likely* to cause accessibility issues, but to claim it does so without user testing isn’t helpful”.  Point taken.

Yet this assessment work, in part, is an attempt to find a uniform way for developers to help determine the cognitive accessibility of Web sites.  Of the many automated tools that help assess general Web accessibility, none are focused on cognitive Web accessibility.  WebAIM is pursuing funding to incorporate such assessment into its WAVE Web accessibility evaluation tool.  My work is an unofficial precursor to that.  I hope it will be helpful.

That said, I would like to include people with cognitive disabilities in this work.  Honestly though, I don’t know how to do it simply and economically.  (This project’s work is performed primarily on my own time and is unfunded.)  I am open to constructive suggestions.  Please post a comment with one.

This post is my second structured assessment of cognitive Web accessibility.  I describe how it is performed in my assessment plan.  It is less-detailed than my first assessment, but it again addresses every relevant guideline of WebAIM’s Cognitive Web Accessibility Checklist.

Web Site: National Association of Councils on Developmental Disabilities

Assessment

• Consistency. One point is awarded.
  • Success
    • Navigation is consistent throughout the site.
    • Similar interface elements and similar interactions do produce predictably similar results.
• Transformability. No point is awarded.
  • Success
    • Images are readable and comprehensible when enlarged (scaled to 200% and 300%).
    • Color alone is not used to convey content.
  • Failure
    • Increased text sizes (200% and 300%) are not supported by the navigation menu.
    • The disabling of styles is not supported.  On the home page, Latin (Lorem Ipsum) text appears, as well as non-contextually relevant links (“Sub-Link 1”, etc.).
• Multi-Modality. No point is recorded.
  • Success
    • Icons of top menu are contextually-relevant.
  • Failure
    • No video- or audio alternatives are provided for textual content.
    • No images are used to convey or to enhance content.
• Focus and Structure. One point is awarded.
  • Success
    • Distractions are avoided.
    • Stylistic differences are used conservatively to highlight important content.
    • Content is organized into well-defined groups.  Headings and lists are used.
    • White space is used for separation.
    • Background sounds are not used.
  • Failure
    • White space and visual design elements are not used to focus user attention.  Particularly because of the red background color of the menus, attention is instead focused on them.
• Readability and Language. No point is recorded.
  • Success
    • There is no tangential-, extraneous-, or irrelevant information.
    • Grammar and spelling are correct.
    • Tables of contents are provided for complex or lengthy content.
    • Text-readability criteria are met.
  • Failure
    • Language is not as simple as is appropriate for the content.
    • The reading level is inadequate for the audience (assuming it is people with developmental disabilities).
    • Jargon is used.
    • Expansion of abbreviations and acronyms is inconsistently implemented.
    • Text is not succinct.
• Orientation and Error Prevention/Recovery. No point is recorded.
  • One form was found.  It has only one field (password).  It fails assessment of the related checklist criteria.
• Assistive Technology Compatibility. No point is recorded.
  • Success
    • A logical heading structure is used consistently.
    • The navigation order is essentially logical.
  • Failure
    • Use of alternative text is inconsistent.  There is none for the images of the text-size changer.
    • Form labels: the only field on the one form is missing a label.
    • Links do not make sense out of context.  There are multiple “Learn More” links on the home page.
    • Keyboard accessibility is problematic.  Navigation menus are not visible via keyboard navigation.
    • Descriptive and informative titles are missing from many pages.
• The site attempts to meet W3C accessibility standards. One point is awarded.
• There is no accessibility statement. No point is awarded.
• There is no explanation about how to use accessibility features. No point is awarded.

Results

Three of ten points possible are recorded.

Conclusion

The Web site of The National Association of Councils on Developmental Disabilities is inaccessible to people with developmental disabilities.

This post is the third part of my first structured attempt to evaluate cognitive Web accessibility.  I am using WebAIM’s Cognitive Web Accessibility Checklist and its WAVE accessibility evaluation toolbar to assess the Web site of Down’s Syndrome Scotland.  See Part 1 and Part 2.

This post covers the checklist sections of:

• Orientation and Error Prevention/Recovery;
• Assistive Technology Compatibility.

Assessment Related to Checklist

• Checklist Section: Orientation and Error Prevention/Recovery
  • Guideline: Give users control over time sensitive content changes
    • This guideline is not applicable.
  • Guideline: Provide adequate instructions and cues for forms
    • Title attributes of tags are used to provide instructions.  There are cues for required fields.  Form labels are inconsistently used. Example: Feedback. Fieldsets are not used, but are not required.
  • Guideline: Give users clear and accessible form error messages and provide mechanisms for resolving form errors and resubmitting the form
    • There are accessible form-error messages.  They could be more clear.  Perhaps “The field ‘Your name’ is required” could be “Type your name” or “Enter your name”.  A submitted form without text in a required field reproduces text entered in other fields when it is refreshed.  Example: Make a Donation.
  • Guideline: Give feedback on a user’s actions
    • Field-specific error messages are prefaced by “Please correct the following errors before trying to submit this form:”.  Example: Make a Donation.
  • Guideline: Provide instructions for unfamiliar or complex interfaces
    • It is possible people with intellectual disabilities would find the site’s short forms to be complex.  User testing would indicate this.  (It may already have been done).  One way to reduce any perceived complexity would be to present users each field step-by-step.
  • Guideline: Use breadcrumbs, indicators, or cues to indicate location or progress
    • Breadcrumbs are used throughout the site.  One point is recorded.
  • Guideline: Allow critical functions to be confirmed and/or canceled/reversed
    • This guideline is not applicable.
  • Guideline: Provide adequately-sized clickable targets and ensure functional elements appear clickable
    • Many links, including those of the sidebar menu, are not underlined.  Some button-images are clickable, some not.  There is no differentiation between them.
  • Guideline: Use underline for links only
    • This guideline is met throughout the site.
  • Guideline: Provide multiple methods for finding content
    • There is a top menu; a sidebar menu; a site search feature; a site map; and links within body text.
• Checklist Section: Assistive Technology Compatibility
  • Guideline: Appropriate alternative text
    • Some images do not have it.  Other images do, but it does not describe their content well.  Example: Fantastic Fundraisers (body of page).  This is not a guideline.  It can not be tested by WAVE.
  • Guideline: Form labels
    • I am ignoring this guideline because its criteria are the same as those for the one (above): “Provide adequate instructions and cues for forms”.
  • Guideline: Tables and table headers
    • Table headers are used. Example: Make a Donation.
  • Guideline: Logical heading structure
    • A level-one heading is used on all assessed pages except the home page.  Of those with additional headings, many have a logical structure. Some do not.
  • Guideline: Links make sense out of context (avoid “click here”, etc.)
    • This guideline is met throughout the site.  One point is recorded.
  • Guideline: A logical, intuitive reading and navigation order
    • On assessed pages, this guideline is met.
  • Guideline: Full keyboard accessibility
    • Access keys are implemented.  On assessed pages, structure is not missing and event handlers are keyboard accessible.  Tabindexes are not required, but one should have been employed, for instance, to make the “Viewing Options” accessibility feature the first link on pages.  A skip link is on all pages, but it would have been better if it were visible.  There are empty links.
  • Guideline: Descriptive and informative page titles
    • This guideline is met throughout the site.
  • Guideline: Frame titles
    • This guideline is not applicable.
  • Guideline: Captions and transcripts
    • This guideline is not applicable.

General Accessibility Assessment

• The site does attempt to meet W3C accessibility standards. Many pages have no accessibility errors detected by WAVE.  One point is recorded.
• The site does not have an accessibility statement.
• No explanation is provided about how to use accessibility features, such as Viewing Options or access keys.

Results

Three of five possible points are recorded.  For the entire, three-part assessment, the total is seven of ten points.

Conclusion

Down’s Syndrome Scotland has made a readily-apparent effort for its Web site to be accessible to its constituency.

Notes

• All “Viewing Options” function in Internet Explorer 8.  All but “Large Text” do in Firefox 3.6.
• E-mail Link To Page employs an inaccessible CAPTCHA.
• Some of my descriptions are disjointed.  This is due to my attempt to address, generally, all the potential errors listed for each guideline of WebAIM’s checklist.  It is also because I tried to make the descriptions brief.

This post describes my first structured attempt to evaluate cognitive Web accessibility.  I expect to learn about related best practices with my Plan to Assess Web Accessibility of 100 Cognitive Disability Organizations.  My working hypothesis is that their Web sites are more likely to implement accessibility features for people with cognitive disabilities than the Web sites of any other organization.

Assessment Tools

• WebAIM’s WAVE accessibility evaluation toolbar;
• WebAIM’s latest Cognitive Web Accessibility Checklist with instructions on how to use WAVE to test a Web site’s implementation of the checklist’s guidelines;
• Firefox 3.6;
• Default Full Zoom Level 4.3 (Firefox Extension); and
• Internet Explorer 8

Summary of Assessment

My assessment uses a ten-point scale.  I record a point if even one guideline in each of the seven sections of WebAIM’s checklist has been met.  Yet, because I am just starting, I would like to see now how practical it is to find and to evaluate a feature representative of every guideline.

I have thus divided the assessment into three parts.  This blog post is the first.  It covers the checklist sections of:

• Consistency; and
• Transformability

In future blog posts, the remaining checklist sections will be assessed:

• Multi-Modality;
• Focus and Structure;
• Readability and Language;
• Orientation and Error Prevention/Recovery;
• Assistive Technology Compatibility.

As well, I will record up to three points if the Web site attempts to meet W3C accessibility standards, if it has an accessibility statement, and if it explains how to use accessibility features.

Web Site Description

The Web site of Down’s Syndrome Scotland is the subject of my first review.  I chose it simply because I have noticed many U.K. Web sites make an effort to be usable by and accessible to people with cognitive disabilities, particularly intellectual disabilities.  The Web site is bright and cheery. Pages have big photos and colorful elements. The home page is pictured below.

Assessment: Consistency & Transformability

• Checklist Section: Consistency
  • Guideline: Ensure that navigation is consistent throughout a site
    • On every page, the options of the top menu are the same.  It, the site search box, and the sidebar menu are always in the same place.  The sidebar menu’s options do necessarily change because they are related to each site section’s content.
  • Guideline: Similar interface elements and similar interactions should produce predictably similar results
    • Such elements include “Print this page”, “Email to a friend” and the search box. All produced predictably similar results. I could find no related inconsistencies elsewhere.  One point is recorded.
• Checklist Section: Transformability
  • Guideline: Support increased text sizes
    • When text size is increased to 200% and to 300%, the text in the content section of the site’s pages looks fine.  Menu-, header- and footer text have an overlapping problem, causing illegibility.
  • Guideline: Ensure images are readable and comprehensible when enlarged
    • Most images are big. All of them and the smaller ones, with the exception of a Scottish Consortium logo, meet this guideline.  One point is recorded.
  • Guideline: Ensure color alone is not used to convey content
    • A red underline in the navigation menu is the only visible site-section indicator. There is no such indicator when styles are disabled.
  • Guideline: Support the disabling of images and/or styles
    • Site-content layout is logical and navigable with images and/or styles disabled.

Results

Two of two possible points are recorded.

Notes

• I tested each guideline on at least three pages with Firefox.  I used Internet Explorer a few times to determine if effects were Firefox-specific.  (None were.)  To take less time, I will likely use Firefox exclusively for subsequent assessments unless a Web site or a feature is incompatible with it.
• I tested the text-size and the image-enlargement guidelines with the Default Full Zoom Level 4.3 Firefox extension to assure that text sizes and zoom levels were increased to 200% and to 300% precisely.