Tag: Web Accessibility

Cognitive Web Accessibility Assessments: 2 UK Sites With Top Scores

~ John Rochford

I performed cognitive Web accessibility assessments on five more sites.  Two of them, both of organizations located in the United Kingdom, received all possible points.  The results for the rest were varied.

Assessed Sites and Scores

View detailed results, assessment criteria and methodology.

Site Highlights

People First

The People First site features a large site-navigation menu (pictured below). For menu options, there are contextually-relevant icons, which are also used throughout the site.

People First Site Navigation Menu

Mencap

The Mencap site incorporates many captioned videos (example pictured below) as an alternative to text content, and relevant images to augment it.  The site’s My Life section is specifically designed for constituents, with plain language; simple navigation, and lots of images and videos.

Man pictured with a quote, "We work in partnership with the parents".

Conclusion

Though the Web sites of Mencap and People First have minor problems, it is apparent the two organizations expended great effort to make them accessible to their constituencies.  I offer my congratulations.

Note: This post is part of a series on cognitive Web accessibility assessments.

Draft Database of Results from Cognitive Web Accessibility Assessments

~ John Rochford

I now have a database of results from my assessments of cognitive Web accessibility.  It is a work in progress.

I am displaying the database data on The Clear Helper Web site.  Because, to date, I have assessed only 2 of my planned 100 Web sites, few data are presented.  Yet it seems a good idea to start the database development and the data presentation now, partly in hope of soliciting feedback from followers of this project.

The assessments home page references two pages that display the same database data differently.  Its main purpose is to describe the assessment criteria and methodology.  I will use it to record any related changes I make as a result of what I learn from performing subsequent assessments.

Via table and pie chart, the first page shows Results By Numbers of Web Sites that meet the assessment criteria.

The second page shows summaries of Results By Web Site.  Each has the criteria met, the number of points recorded, and the conclusion. Seven of the criteria are based upon the sections of WebAIM’s Cognitive Web Accessibility Checklist.

A future page will show results by the guidelines that form the checklist’s sections.  It might be interesting to create a page of results by country.  It may be, for example, that cognitive-disability organizations in the countries of the U.K. are more likely than those in other countries to make their Web sites accessible to their constituencies.

I would like feedback.  If you have suggestions for how I can improve my related efforts, or for other ways to display the results, please post a comment or contact me.

People with Intellectual Disabilities at the Boston Accessibility Unconference

~ John Rochford

The Boston Accessibility Unconference is Saturday, May 15, 2010, from 10 AM to 5 PM at the Adobe facility in Waltham, Massachusetts.  (Please join us!)

I invited a couple of people from the focus group that is assisting me with the Clear Helper project.  They may learn valuable information that would help them navigate the Web better than they can now.  While I hope that happens, I confess I have another hope.

I think it would be great if the Web accessibility community gains personal experience with people who have intellectual disabilities.  I have noticed the community, in general, lacks interest in cognitive Web accessibility.  I have multiple theories about the cause.  Among them is that developers have little exposure to people with cognitive disabilities, in particular folks with intellectual disabilities.

The people in the focus group are great self-advocates.  I don’t think they would be shy about telling people at the unconference how they find Web sites to be inaccessible.  Perhaps this would help motivate attending developers, for example, to produce Web sites more accessible to them.

Cognitive Web Accessibility Assessments: Lessons Learned So Far

~ John Rochford ~ 1 Comment

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.

Cognitive Web Accessibility Assessment, Second Attempt: Site Failure

~ John Rochford

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

home page of 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.

Upcoming Web Site to Include Accessibility for People with Cognitive Disabilities

~ John Rochford ~ 1 Comment

I am working on a Web site that will incorporate two significant features with which I have experimented: text-to-speech (TTS) and plain language. The site will have other accessibility features for people with cognitive disabilities, text enlargement and text highlighting among them.

The site will be a report for The Massachusetts Department of Developmental Services (DDS).  It will be published by The Eunice Kennedy Shriver Center, for which I work.  Because the constituency of The DDS is people with intellectual disabilities, Shriver project staff would like the report to be as accessible to them as can be afforded at this point.  I have thus been in discussions with representatives of Web-accessibility technology companies.

Web Accessibility Technologies

An accessible content management system (CMS) from WebCredible has been purchased for the Web site. WebCredible reports that, in addition to its purpose of creating accessible Web pages, the CMS includes two other features, ones that attracted me to it.

  • Its back-end, content-management interface is itself accessible; and
  • “… content editors are forced to … produce accessible and well-written page content …”.

I will begin using the WebCredible CMS next week.  Future blog posts will describe what I learn about it.

The Shriver project staff and I are considering two other products from The United Kingdom: BrowseAloud and ROKTalk.  Each provides TTS and text-accessibility features for Web sites. I have mentioned both products in previous blog posts, and reviewed the one from ROKTalk.  A future post will describe which we choose, and why.

Plain Language

The report to be published is long and contains complex information.  For the home page of each section, we plan to write a plain-language version of the section’s main points.  I am concerned about doing this well because, as I have said before, writing “easy” text is not so easy.  Our related efforts will also be the subject of future blog posts.

Note: No endorsement of the above-mentioned products is expressed or implied.

50 Web Accessibility Blogs

~ John Rochford ~ 2 Comments

On The Clear Helper Web Site, I published a list of

Web Accessibility Blogs.

At the time of this writing, there are fifty.  More will be added to the list as I find them.

Selection Criteria

  • Each is either a blog that focuses on Web accessibility, or is the blog’s Web-accessibility category.
  • All are active; they have articles published this year (2010).
  • All in the list, at least as of now, are written in English.

Description

Every listing has a link to the blog’s home page and is annotated with an edited quote from a top-level page.

I have started a list of cognitive Web-accessibility blogs.

Suggestions Desired

I would like to include blogs written in other languages.  If you have a suggestion, please comment or contact me.

Note: No endorsement of the blogs is expressed or implied.

Sources of Research Articles on Cognitive Web Accessibility

~ John Rochford ~ 3 Comments

On The Clear Helper Web Site, I published my

Sources of Research Articles about Web Accessibility for People with Cognitive Disabilities.

Most are vertical search engines of research from related fields.

Each listing is annotated with an edited quote describing the source.  At the top of the page, I note the approximately twenty search terms I used.  The following blog posts are about the results of this effort.

Since I published the above, I have significantly increased the number of articles for each list.

First Experiment with MAGic for Web Accessibility Testing

~ John Rochford

I and another developer recently performed a preliminary experiment using MAGic with Speech to determine its suitability for Web accessibility testing. This work is part of my effort to find alternatives to using JAWS for the same purpose.  See my previous, related post,”Stop Using JAWS for Web Accessibility Testing?“.

[Note: I would like to hire, as a consultant, an experienced user of MAGic with Speech. Please contact me.]

Description of MAGic with Speech

MAGic is a screen magnifier for people with low vision or learning disabilities.  It not only enlarges screen imagery up to 36 times, but also enables setting of tinting-, brightness- and contrast of foreground- and background colors.

Three important features for our test:

  • many of the same reading commands as JAWS;
  • reads aloud in a voice the text displayed on the screen; and
  • can highlight words as they are read aloud.

Specific Test Purpose

I want to determine if using MAGic would solve a significant problem JAWS presents for accessibility testing.  The Web content JAWS reads can not be visually tracked.  This confounds sighted developers and people to whom JAWS is being demonstrated.

Background & Setup

I am sighted.  Rich, the other developer and a long-time JAWS user, is not.  We conducted the test in a quiet office on The MIT campus.  Installed on Rich’s computer were MAGic Standard with Speech 11 and NVDA.  On mine were JAWS 11 and, later, the same version of MAGic that Rich was using.  Both of us had previously tried MAGic, with Rich having become more-familiar with its functions and use.

Procedures

We focused our test on three home pages: www.mit.edu, www.disabilityinfo.org and www.clearhelper.org.  We  are familiar with them and know their accessibility to be good.  We simultaneously navigated each page multiple times.

The test had four phases:

  1. Rich used MAGic while I watched;
  2. Rich used MAGic as I used JAWS;
  3. Rich used JAWS while I used MAGic; and
  4. Rich used JAWS and MAGic together as I used MAGic.

With MAGic’s configuration tool, we enabled and disabled sets of primary functions.  Two we invoked often were speech only and speech with word highlighting.

Results

The first two phases proved problematic because Rich was unable to navigate page headings with MAGic.  To find a page’s main content, screen-reader users can look for a level-one heading.   They can then move from heading to heading to find sections of important content.  Though MAGic produces a list of headings, we could find no way to make it navigate headings as Rich is accustomed with JAWS.  We then switched computers so I would be the primary MAGic user / tester.

In the third phase, as in the previous two, we tried to invoke MAGic’s word highlighting.  It did not work consistently.  When it did work, I could visually track the content MAGic was reading.  Because Magic also spoke the content, Rich could track where I was in a page while he navigated the same one with JAWS.

For the fourth phase, I installed MAGic on my computer running JAWS.  We conjectured that using them in concert might enable extra functionality in MAGic.  This was due to statements by Freedom Scientific, maker of both products.

  • “MAGic adds visual enhancements when used in conjunction with JAWS.”
  • “MAGic is fully compatible with our JAWS screen reader …”.

Retrieved from: http://www.freedomscientific.com/products/lv/magic-bl-product-page.asp

We had hoped the extra functionality would include page navigation via headings.  If it did, we could not find it.

Conclusion

Results from the third phase were promising when the word-highlighting feature functioned.  It is likely our testing would have been more fruitful had we been more familiar with MAGic. Additional testing will be needed to determine how well MAGic mimics a screen-reader’s page navigation.

Next Steps

  • I plan to hire, as a consultant, an experienced user of MAGic with speech.  That person and I will conduct future tests.
  • I will contact Freedom Scientific to address directly the issues encountered.

Notes

  • Rich had NVDA rather than JAWS installed on the computer he used because he was borrowing it for our testing.
  • The issue of JAWS cost I noted in my previous, related post would be partially ameliorated with MAGic.  Its cost is about 55% that of JAWS.
  • Eric Damery of Freedom Scientific, at a JAWS 11 demonstration I attended, suggested using MAGic instead of JAWS for accessibility testing.
  • No endorsement of Freedom Scientific or any of its products is expressed or implied.

Cognitive Web Accessibility Assessment: First Attempt, Part 3 of 3

~ John Rochford

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
    • 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.