Prometheus results

• Fall 2001 Version ** [skip to Spring 2001]
  • Modified SNOW method
  • Accessible browsing
  • Validation
  • Section 508
  • What the company has to say
  • Is this LMS accessible?
• Spring 2001 Version **
  • Modified SNOW method
  • Accessible browsing
  • Validation
  • Is this LMS accessible?

Fall 2001 Version **[table of contents]

Modified SNOW method [table of contents]

Accessible browsing [table of contents]

After requesting to set three cookies, Promethues via Lynx announced simply "Prometheus requires a frames-capable Web browser such as Netscape Navigator, Microsoft Internet Explorer, or Opera." Prometheus also requires Javascript. It does have a feature that allows some class information and assignments to be downloaded to any PDA running the Palm OS. This is a step towards being able to access the class through a text-based browser.

Validation [table of contents]

What the company has to say [table of contents]

As of November 15, 2001, I could find no statement on accessibility on the company website.

Is this LMS accessible? [table of contents]

Spring 2001 Version ** [table of contents]

Modified SNOW method [table of contents]

Spring 2001 Excel spreadsheet with complete data for Prometheus. All SNOW spring 2001 Excel files in zip file.

Accessible Browsing [table of contents]

Few problems in any program were discovered while using JAWS. There were some errors reading the Prometheus page with JAWS. The biggest problem was in tabbing to the submit button in the page creation dialogues. On most of these pages, the button was in a frame of its own that is not part of the tab order. The only way we found to get to the submit button was to mouse to it, not something many, if any, JAWS users would be able to do.

An additional error was missing alt text on linked images in the top frame; the browser read the URL of the linked images instead. These URLs were very lengthy.

JAWS was able to read between the frames without difficulty, starting with the Navigation frame on the left, then the main frame.

For Prometheus, HPR 2.5 revealed poorly named frames, which were not intuitive. When using HPR, which does not display the content of the entire frameset, the user must rely on the frame name to navigate. If the name is not intuitive, it takes extra time as one guesses what content the frame contains. An incorrect guess means backing up and trying another link. HPR also revealed a large number of redirects while logging in. This can be problematic for browsers that do not support redirects. A redirect is automatic script on a page that tells the browser to go to another location. We do not know why the redirects appear in Prometheus.

Prometheus had a tendency to make HPR forgetful, for lack of a better term. HPR had problems recognizing that the user was logged in. We entered our username and password many times while in Prometheus. The most prevalent occurrences of this were when navigating with HPR's back button. When using other browsers, such as Internet Explorer, we did not have this problem. The submit button problem mentioned above in the JAWS section showed up here as well. In this case, we were unable to find a work-around (even a sighted cheat like a mouse click) to the missing submit button. We were unable to create any content using HPR.

No navigation problems discussed here were present with HPR 3.0.

Prometheus was virtually unusable with Lynx. The login would not process without JavaScript. We found a solution by generating a URL from logging into Prometheus using a Java-enabled browser. We typed this URL into Lynx, and received access to the course site. Unfortunately, this URL is long and dynamic. It would not be practical for a user to manually enter this URL every time she needed to enter her course. Prometheus's reliance on a JavaScript-based login rendered it useless in Lynx and, by extension, most other lower end text-to-speech or text-only browsers.

Validation [table of contents]

Our A-Prompt evaluation highlighted errors that were difficult to determine in the other parts of the review. It also confirmed some errors that we had already found.

It was difficult to evaluate a set of pages that were the same across all programs; instead, we reviewed a sample content page from each program. Content pages are the most important aspect of LMS packages, as these are most likely to contain vital course information.

A-Prompt revealed a number of similarities across the products. The same seven errors occurred in each course package. A-Prompt reported missing DOCTYPEs, fixed font sizes, missing descriptive text for images, link text that is not meaningful, missing captions, and missing summaries for tables.

A-Prompt found unique errors in the products as well. Two products, Blackboard 5 and Prometheus, do not identify the language of the page. All products save Blackboard 4 had JavaScript problems. These products provided no alternative to JavaScript-based functions, such as login and chat forums. This issue is reflected in the reader tests we did with these products.

The sample syllabus page had the follow errors

• DOCTYPE missing
• Font size or color should not be set
• Image missing descriptive text
• Language of document should be identified
• Link text must be meaningful
• SCRIPT section must have a NOSCRIPT section
• TABLE (layout) should linearize
• TABLE should have a caption
• TABLE should have a summary

Prometheus did not meet the following W3C/WAI checkpoints. (Text below is from the checkpoints page.) There were four priority one failures, 13 priority two failures, and 13 priority three failures, a total of 30 failures. Multiple occurences of the same checkpoint are considered as one failure.

Priority 1 (4 failures)

• 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
• 5.1 For data tables, identify row and column headers.
• 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
• 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

Priority 2 (13 failures)

• 3.1 When an appropriate markup language exists, use markup rather than images to convey information.
• 3.3 Use style sheets to control layout and presentation.
• 3.5 Use header elements to convey document structure and use them according to specification.
• 3.6 Mark up lists and list items properly.
• 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
• 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.
• 13.2 Provide metadata to add semantic information to pages and sites.
• 13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).
• 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.
• 6.4 For scripts and applets, ensure that event handlers are input device-independent.
• 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]
• 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.
• 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.

Priority 3 (13 failures)

• 4.3 Identify the primary natural language of a document.
• 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.
• 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.
• 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)
• 13.5 Provide navigation bars to highlight and give access to the navigation mechanism.
• 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.
• 13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.
• 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
• 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.
• 5.5 Provide summaries for tables.
• 5.6 Provide abbreviations for header labels.
• 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.
• 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.
  
  

Is this LMS accessible? [table of contents]

Prometheus is not accessible given W3C/WAI Priority 1 guidelines. It had four Priority 1 errors. Therefore, it is also not Section 508 compliant.

Content authored by AnnMarie Johnson and Sean Ruppert. ©2001
last updated November 20, 2001 by AnnMarie Johnson.