Sakai 2.9 Comprehensive Firefox WCAG 2 Accessibility Evaluation Protocol

Owned by Former user (Deleted)
Last updated: Jul 17, 2012 by Former user (Deleted)Version comment
21 min read

This is the protocol for evaluating Sakai 2.9 accessibility using a PC or Mac OS X with Mozilla Firefox and a suit of free accessibility plug-ins in Firefox. Please follow the instructions listed in the "Workflow / Process" section below.

Background

This is a protocol for performing a comprehensive technical accessibility evaluation of Sakai 2.9 (according to WCAG 2.0 Level AA Guidelines and Techniques) using the Mozilla Firefox Web Browser and assorted accessibility add-ons.

If there are any questions or concerns on using this testing protocol, please email the Accessibility Working Group, or the group lead in charge of the testing (currently Brian Richwine (brichwin@indiana.edu)) - please be sure to start the subject line with "Sakai Accessibility Testing".

Required Skills

To use this protocol and report the results effectively, requires knowledge and expertise across many areas, including:

  • Experience configuring and using the Mozilla Firefox Web browser
  • Experiences configuring and using accessibility evaluation tools, Web validation tools, and approaches for evaluating Web accessibility
  • Knowledge of (X)HTML, CSS, JavaScript, and related Web technologies
  • Knowledge of Web accessibility issues, especially of the barriers facing people with disabilities
  • Knowledge of Adaptive/Assistive Technologies (AT) and strategies for overcoming barriers
  • Knowledge of Accessibility Laws, Guidelines, Standards, and Best-Practice Techniques. Particularly:
    • Web Content Accessibility Guidelines (WCAG) 2.0 and the associated Techniques for meeting Level AA compliance
    • Section 508 Standards § 1194.21, § 1194.22
  • Sakai 2.9 Functionality and Operation

Required / Recommended Tools

The following tools will be used in this protocol:

Workflow / Process

This workflow was developed to support the Sakai 2.9 Accessibility Review. As part of that review, the process for using this protocol is as follows:

  • Sign up:
    • Add your name to the participants section of the Sakai 2.9 Accessibility Review page.
    • Indicate the tool you are evaluating and that you are using the Comprehensive Firefox Accessibility Protocol (record "CFAP") on the table.
  • Get a reporting template:
    • Create a copy of the Sakai 2.9 Firefox Comprehensive WCAG 2 Protocol Results Template (it is a child page of the Sakai 2.9 Accessibility Review Results page) for recording the results.
      • Log into Confluence
      • Browse to the Sakai 2.9 Firefox Comprehensive WCAG 2 Protocol Results Template page.
      • From the "Tools" menu at the top of the page, select the "Copy" option.
      • Rename the page title (in the textbox at the top), use the format: "Sakai 2.9 [TOOL NAME] Tool Comprehensive WCAG 2 Protocol Results".
      • Fill in the tool name, your name, the date, etc. in the header at the top of the reporting template.
      • Unless you are ready to enter issues, click "Save" to store the template for your work.
  • Get server access and prepare the tool:
    • In most cases, to perform the testing a username and password for a user account that has been given access to a course or project site is needed. Frequently, the tool may need to be configured in advance with some content to work with.
    • If an accessibility walkthrough script is available for the tool, use the walkthrough script to help you more fully exercise the tool (if needed). Walkthrough scripts can be found on the Sakai 2.9 Accessibility Walkthrough Scripts page and are linked to from the tools list table on the Sakai 2.9 Accessibility Review page. The walkthrough script will have details on any pre-walkthrough configuration that needs to be performed.
    • If you don't know the usernames and passwords to use, contact the Accessibility Review Lead (Brian Richwine: brichwin@indiana.edu).
    • Be sure to use the appropriate Sakai 2.9 QA Server. (To be determined).
  • Perform the evaluation:
    • Go through the steps in the following protocol for each page, or new page configuration (for dynamically updating pages).
    • When an issue is found, record the issue on the results page created above.
      • Record the category name for the issues (category names are listed in each step of the protocol).
      • Describe the issue
      • Record the steps required to both reproduce and to detect the issue (if not relatively obvious).
      • Record the severity of the issue (see list of severity ratings and their definitions on the reporting template/page).
  • Once complete:
    • Indicate that the evaluation is complete by entering the word "Yes" next to the "Evaluation Complete Yes/No?" entry in the recording page template.
    • Place a link to the results page in the Tools Listing table on the Sakai 2.9 Accessibility Review Page.
  • After the completed evaluation results are posted, the Accessibility lead will review the results, search for existing JIRAs on the issues, and create any new JIRAs as required (JIRAs for each issue will be listed on the results page next to the issue).

Note: If you can't or don't feel comfortable using the JIRA system for recording the results, a word file version of the template is available for downloading. Place the results in that template and mail them to the Accessibility Review Lead (Brian Richwine: brichwin@indiana.edu). Please be sure to use the subject line "Sakai 2.9 Accessibility Review Results" so the email will get noticed!

Getting Set-up for Testing

These instructions are for reviewing Sakai 2.9 accessibility using a PC or Mac OS X with Mozilla Firefox and associated accessibility plug-ins.

Configuring Mozilla Firefox

  1. If Mozilla Firefox Web browser version 6.0.x is not installed, download and install it from here: http://www.mozilla.com/.
  2. If the Firefox Accessibility Extension version 1.5.58 (or higher) is not installed, install it using the directions here: http://firefox.cita.uiuc.edu/
  3. If the WAVE Firefox Toolbar version 1.1 (or higher) is not installed, install it using the directions here: http://wave.webaim.org/toolbar
  4. Other than the above Firefox add-ons, please try to have Firefox running in as close to the default settings as possible.
    1. Make sure JavaScript is enabled (Choose Tools, Options from the menu. The Enable JavaScript checkbox is on the "Content" tab in Firefox's "Options" dialog box).
    2. Make sure no security plug-ins (such as noscript, ad blockers, etc.) are running that might interfere with accessing and using Sakai.
    3. Reset Firefox's Text Zoom (Choose View, Zoom, Reset from the menu or press Ctrl+0)

Accessing the Tool to Test

Please follow the instructions listed in the Workflow / Process section above.

Accessibility Evaluation Protocol

1. Text Alternatives for all non-text content - Images (WCAG SC 1.1.1 - Level A), (WCAG SC 1.4.5 - Level AA)

  • Protocol:
    1. Using the Accessibility Evaluator for Firefox toolbar, click on the "Text Equivalents" icon and select "List of Images".
  • Criteria:
    1. Every non-decorative image has alternative text that conveys the image's content
      1. Alternative text succinctly that describes the image's content without being too vague
      2. Images that have a function have alternative text that describes the function
      3. Images that have meaningful (non-decorative) text must repeat that text in the alternate text
      4. Images of text are not used where text can be styled to match the visual presentation (WCAG SC 1.4.5)
    2. Decorative graphics should be background CSS images or have empty alt attribute values (alt="" - no space) and empty or absent title attributes.
    3. Images placed next to text content that describe the image should have empty alt attributes and empty or absent title attributes to avoid redundancy.
    4. Make sure the alt attribute on an image is not being used to provide "tool-tip" text. (Tool-tip text goes in the title attribute.)
  • Record Results under "Images" on the Reporting Template

2. Linearized Content - Meaningful Sequence (WCAG SC 1.3.2 - Level A)

Make sure the programmatically determined order (usually the source order) of the content is the correct reading sequence needed to understand the page's meaning.

  • Protocol:
    1. Web Developer Extension Miscellaneous > Linearize page
  • Criteria:
    1. Verify that page content appears in an order that preserves the original page's meaning and structural relationships.
      1. If a page contains independent pieces, the relative order of those pieces may not affect their meaning (the order of independent content pieces is not always meaningful).
      2. The order of the main content, navigation, sidebars, etc. many not affect a page's meaning, but it should be consistent across different pages/tools.
  • Record Results under "Linearized Content" on the Reporting Template.

3. Reliance on Sensory Characteristics (WCAG SC 1.3.3 - Level A)

  • Protocol:
    1. Read through page content.
  • Criteria:
    1. Check that instructions don't rely on sensory characteristics such as shape, size, visual location, orientation, or sound. Any references to sensory information must contain additional information that allows the item to be located and identified without any knowledge of its shape, size, or relative position.
  • Record Results under "Reliance on Sensory Characteristics" on the Reporting Template.

4. Use of Color (WCAG SC 1.4.1 - Level A)

  • Protocol:
    1. Read through / examine the page content.
  • Criteria:
    1. Make sure color is not used as the sole method of conveying information.
  • Record Results under "Use of Color" on the Reporting Template.

5. Sufficient Contrast (WCAG SC 1.4.3 Level AA)

  • Protocol:
    1. For testing contrast of text elements:
      1. On the Accessibility Evaluator for Firefox toolbar, click on the "Style" icon and select "Colour Contrast". Note: The tool often is fooled by complex CSS and can mislead you. Double check all results and manually check any questionable text elements.
    2. For testing images of text, differences between icons and their background, manual testing of text elements, etc.:
      1. Use the color picking tool to determine the foreground color and the background color. (You may find it helpful to use the browser's page zoom to magnify the page).
      2. Enter the color values into the Juicy Studio's online luminosity contrast calculator (http://juicystudio.com/services/luminositycontrastratio.php)
  • Criteria:
    1. Text, images of text, and icons have a luminosity ratio with their backgrounds of at least 4.5:1
    2. Text or icons that are part of an inactive or disabled user interface component have no contrast requirement.
  • Record Results under "Sufficient Contrast" on the Reporting Template.

6. Resizable Text (WCAG SC 1.4.4 – Level AA)

  • Protocol:
    1. On the Firefox menu bar, click the "View" menu, then the "Zoom" sub-menu, and make sure the "Zoom Text Only" option is checked. Select "Reset" from the "Zoom" sub-menu, or press "Ctrl+0" to reset the zoom level. Then, select "Zoom In" (or press "Ctrl++") four times.
  • Criteria:
    1. all the text still visible. No areas overlap.
    2. the context of everything still visible?
    3. headings, labels, icons, and other visual cues are still correctly associated with their content
    4. columns shift and realign correctly
  • Record Results under "Resizable Text" on the Reporting Template
  • Select "Reset" from the "Zoom" sub-menu, or press "Ctrl+0" to reset the zoom level.

7. Semantics / Info and Relationships (WCAG SC 1.3.1 - Level A), and Name, Value, Role (WCAG SC 4.1.2 - Level A)

  • Protocol:
    1. Examine the content for variations in the presentation or structure of the text.
    2. Use the "Structure/Order" icon, the "Disable Styles" icons on the WAVE toolbar and the Firebug plug-in's Inspect tool (often by simply right clicking the content and selecting "Inspect Element") as needed to inspect the elements that are involved in the variations found .
  • Criteria:
    1. Headings
      1. Check that heading markup is used when content is a heading.
      2. Check that heading markup is not used for formatting (when content is not a heading).
      3. Check that heading levels are used appropriately to form an accurate hierarchy (h1, h2, h3, etc.)
    2. Lists as lists
      1. Check that content that has the visual appearance of an unnumbered list (with or without bullets) is marked as an unordered list.
      2. Check that content that has the visual appearance of a numbered list list is marked as an ordered list.
      3. Check that content is marked as a definition list when terms and their definitions are presented in the form of a list.
    3. Data tables as data tables
      1. Check that the content has a relationship with other content in both its column and row (that it is really a data table).
      2. Check that each occurrence of tabular information is marked with table markup of at least the elements table, tr, th, and td.
      3. Check that all table headers are marked with th elements.
      4. Check that all th elements have the appropriate scope attribute (row, col, rowgroup, or colgroup).
      5. Check that all td elements that act as headers for other elements have the appropriate scope attribute.
      6. Check that cells associated with more than one row and/or one column header contain a headers attribute that lists the id for all headers associated with the cell.
      7. Check the table summary and table caption
        1. If both a table summary and a table caption or a heading placed right before the table are present, make sure the summary attribute does not duplicate the caption and/or heading.
        2. If a table summary is present and needed, check that the summary describes the table's organization or explains how to use the table.
    4. Form Labels
      1. Check that form input elements are labeled correctly.
        1. Check that one of the following is true:
          1. Check that text labels are explicitly associated with form input elements using <label> elements that have "for" attributes which correctly indicate the id value of the input, textarea, or select element being labeled.
          2. Check that the title attribute is used to label form input elements that don't have corresponding label elements.
        2. Check that related form elements are grouped with fieldset/legend (especially radio button groups, checkbox groups, etc.).
          1. Check that each fieldset has a legend element
          2. Check that the legend element describes the group and that the combination of the legend and each the labels contained in it are all unique to the page.
        3. Check the the text label is in the correct position in the code relative to the form input element
          1. Check that the text label appears before input, textarea, and select elements
          2. Check that the text label appears after radio button and checkbox input elements.
    5. Layout tables as layout tables
      1. Check that no table caption or table summary is provided (i.e., no summary="layout")
      2. Check that all table cells are coded with td elements and that no th elements are used.
      3. Check that no table cells have a headers attribute.
    6. Emphasized or Special Text
      1. Check that the appropriate semantic markup (em, strong, cite, blockquote, sub, sup, etc.) has been used to mark the text that conveys information through variations in text.
    7. Indented / Offset Text
      1. Check that blockquote or other semantic markup has not been misused for formatting.
  • Click the "Reset Page" icon on the WAVE toolbar and turn off the Firebug plug-in as needed.
  • Record Results under "Semantics" on the Reporting Template.

8. Keyboard Operability (WCAG SC 2.1.1 Level A), No Keyboard Traps (WCAG SC 2.1.2 Level A)

  • Protocol:
    1. REWRITE THIS! Move through the page using a combination of the tab key and arrow keys. The convention for standard HTML pages is to cycle through each link one at a time using the Tab key. Controls such as buttons and links are activated using the Enter key. Selections such as setting radio buttons and checkboxes are made with the Spacebar.
  • Criteria:
    1. Make sure you can navigate and use/operate all elements on the page entirely with the keyboard:
      1. you can access all links, menu items, and other controls/functions on the page
      2. you can access all form fields, controls, and buttons
      3. you can activate all controls with either the space bar or enter key
      4. you don't get stuck or trapped and have to use the mouse
      5. Check that focus (including keyboard focus) on an option in a select element does not result in a context change
  • Record Results under "Keyboard Operatibility" on the recording template.

9. Provide users enough time to read and use content. Timing adjustable (WCAG SC 2.2.1 Level A)

  • Protocol:
    1. Determine if the page has a session timer or other time limit.
    2. Let the page be and observe what happens as the time limit approaches / comes close to expiring.
    3. Determine if users are warned in advance about the time limit.
    4. Determine if the users are warned that the time limit is about to expire (note how much warning they are given).
    5. Determine if the users are able to extend the time limit (for instance by checking a check box, by clicking OK on the warning dialog, etc.)
    6. Determine if the users can repeatedly extend the time limit.
  • Criteria:
    1. One of the following must be true:
      1. Turn off: The user is allowed to turn off the time limit before encountering it; or
      2. Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
      3. Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times.
      4. Exceptions:
        1. Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
        2. Essential Exception: The time limit is essential (for instance a set time limit in SAMigo Test & Quizes) and/or extending it would invalidate the activity; or
        3. 20 Hour Exception: The time limit is longer than 20 hours.
  • Record results under "Time Limits" on the recording template.

Notes:

The time limits for an assessment in the SAMigo Test & Quizes tool can be extended for specific users who need extended test taking time. This must be done in advance by arranging the users into groups and publishing the assessment to each group with the time limit setting set appropriately for each group. This fits the model used in most higher ed. settings where students with qualifying documented disabilities are given accommodations including extended test taking time. This accommodation is typically arranged in advance.

10. Pause, Stop, Hide blinking, scrolling, or auto-updating information. (WCAG SC 2.2.2 Level A)

  • Protocol:
    1. Examine the page for any scrolling, blinking, or auto-updating information.
    2. Determine if the page refreshes automatically.
    3. If any of the content updates or refreshes automatically, determine if there is a method to pause or disable the updates.
  • Criteria:
    1. If screen refreshes automatically there must be a mechanism to pause or disable the the automatic updates.
  • Record results under "Control of Updates" on the recording template.

11. Prevent Seizures (WCAG SC 2.3.1 Level A), (WCAG SC 2.3.2 Level AAA)

  • Protocol:
    1. Manually examine the page content.
  • Criteria:
    1. Make sure there are no more than three flashes in any 1-second period. (G19)
  • Record results under "Prevent Seizures" on the recording template.

12. Bypass Blocks - Headings (WCAG SC 2.4.1 Level A - H69)

  • Protocol:
    1. Inspect the headings using the Headings Map add-on for Firefox.
  • Criteria:
    1. Check that each section of the page starts with a heading.
  • Record results under "Bypass Blocks - Headings" on the recording template.

13. Bypass Blocks - "Skip to Content" Links (WCAG SC 2.4.1 Level A - G124)

  • Protocol:
    1. Use Firebug to inspect the body element of the main page (the portal, not the iFrame that contains the tool content).
  • Criteria:
    1. Check that no page content precedes the "Skip to Content" links.
    2. Check that the link text accurately describes its function.
    3. Check that activating the link moves the focus to the appropriate section of the page.
    4. Check that the link is either always visible or that it is visible when it has keyboard focus.
  • Record results under "Bypass Blocks - Skip Content Links" on the recording template.

Notes:

The skip-to-content links are primarily a portal issue, as that as where the Skip-to-content links come from. However, it is important to make sure no tool disables their functionality. Be sure to use the accesskeys for each Skip-to-content link on each tool page to make sure they function:

  • Accesskey 'c' should take you to the content.
  • Accesskey 'l' should take you to the tools list.
  • Accesskey 'w' should take you to the work-sites list.

14. Bypass Blocks - Using structural markup to group links (WCAG SC 2.4.1 Level A - H50)

A technique employed in Sakai CLE is to group links into logical sets using unordered lists (the ul/li elements). This is seen in the worksites list, the site's tools list, and the controls placed in a tool's action bar.

  • Protocol:
    1. Inspect the page for links that could be considered logical sets.
    2. Use Firebug to inspect the markup used to contain the links.
  • Criteria:
    1. Logical sets of links must be grouped using unordered list (ul/li) elements (unless they are actually visually rendered as a numbered list of links).
  • Record results under "Bypass Blocks - Group Links" on the recording template.

15. Bypass Blocks - Frame Titles (WCAG SC 2.4.1 Level A - H64)

  • Protocol:
    1. Using the Accessibility Evaluator for Firefox toolbar, click on the "Navigation" icon and select "Frames".
  • Criteria:
    1. Each frame and iframe element in the HTML or XHTML source code must have a title attribute.
    2. The frame and iframe's title attribute must contain text that uniquely identifies the frame and describes its purpose.
  • Record the results in the template under "Bypass Blocks - Frame / Page Titles"

16. Page Titles (WCAG SC 2.4.2 - Level A)

  • Protocol:
    1. Inspect the page's title using Firebug (the title element in the head section).
    2. Examine how the page title relates to the page's content/function.
  • Criteria:
    1. The Web page must have a non-empty title element in the head section of the (X)HTML.
    2. The title must describe the page content / function.
    3. The Web page must be identifiable by the title (practically speaking, this means it must be unique).
  • Record results under "Page Titles" on the results template.

17. Focus Order (WCAG SC 2.4.3 - Level A), Visible Focus (WCAG SC 2.4.7 Level AA), No Context Change On Focus Change (WCAG SC 3.2.1 Level A)

  • Protocol:
    1. Examine the page and identify all interactive elements.
    2. Determine the logical order of interactive elements.
    3. Using a keyboard, cycle focus through all content (using the tab key).
  • Criteria:
    1. Focus moves to controls in a logical fashion. (WCAG SC 2.4.3 Level A)
    2. Focus remains visible at all times (WCAG SC 2.4.7 Level AA)
    3. All interactive elements (links, controls, and other key items) receive focus (WCAG SC 2.1.1 Level A)
    4. No changes of context occur (form submission, pop-ups, focus jumps to another element, etc.) (WCAG SC 3.2.1 Level A). Note: Changes of content are not always a change of context.
  • Record results under "Focus" on the results template.

18. Link Purpose (WCAG SC 2.4.4 Level A)

  • Protocol:
    1. Go to the Accessibility Extension toolbar, click on the Navigation icon and select "Links".
  • Criteria:
    1. There should be no links with the same text (a redundant link) that go to different locations or perform different functions.
    2. The purpose of each links should be self-explanatory (can be determined from the link text alone - do not depend on the title attribute!).
      1. Check that text (or alternative text for non-text content) is included in the a element.
      2. If an img element is the only content of the a element, check that the alternate text for the image describes the purpose of the link.
      3. If the a element contains one or more img elements, and the alternate text for all of the img elements are empty, the text of the link must describe the purpose of the link.
      4. If the a element contains only text, that text must describe the purpose of the link.
  • Record your findings in the template next to "Links".

19. Descriptive Headings (WCAG SC 2.4.6 Level AA - G130)

  • Protocol:
    1. Go to the Accessibility Extension toolbar, click on the Navigation icon and select "Headings".
  • Criteria:
    1. Each heading must identify its section of the content.
  • Record results under "Headings" on the results template.

20. Descriptive Labels (WCAG SC 2.4.6 Level AA - G131), Consistent Labels (WCAG SC 3.2.4 Level AA)

  • Protocol:
    1. Identify the purpose of each component on the page.
    2. Determine which page components require a label.
    3. Go to the Accessibility Extension toolbar, click on the Navigation icon and select "Forms".
      1. Notes:
        1. This tool frequently mistakenly lists buttons and other form controls as being unlabeled.
        2. This tool is likely to completely miss elements with ARIA roles which serve as input/interactive interface elements and therefore require labels.
        3. This tool is likely to miss labels created through ARIA properties (aria-label, aria-labeledby, aria-describedby).
        4. When in doubt check manually with Firebug or have a screen-reader user check the results.
  • Criteria:
    1. Each user interface element that requires a label must have a label.
    2. Each label must make the user interface element's purpose clear.
    3. The label must be identical for each user interface component with the same function. (WCAG SC 3.2.4)
  • Record results under "Labels" on the results template.

21. Language Indication / Readability (WCAG SC 3.1.1 Level A), (WCAG SC 3.1.2 Level AA)

  • Protocol:
    1. Examine the html element of the document for lang and xml:lang attributes.
    2. Read through the content on the page and check for content that is in a different human language than the inherited human language for the element.
      1. For each change in the human language, use Firebug to examine all the parent elements for lang attributes up to and including the html element.
  • Criteria:
    1. The html element must have a lang and/or xml:lang attribute
      1. Check that the lang attribute's value conforms to BCP 47: Tags for the Identification of Languages (http://www.rfc-editor.org/rfc/bcp/bcp47.txt) and accurately reflects the primary language used by the Web page.
    2. For human language changes within the page:
      1. Check that the language of the content is the same as specified in the inherited human language.
      2. Verify that the lang attribute's value is valid according to BCP 47: Tags for the Identification of Languages (http://www.rfc-editor.org/rfc/bcp/bcp47.txt).
  • Record results under "Language Identification" on the results template.

22. Changing Context On Input (WCAG SC 3.2.2 Level A - G13)

  • Protocol:
    1. Locate content where changing the setting of a form control results in a change of context
    2. Check to see if an explanation of what will happen when the control is changed is available prior to the controls activation
  • Criteria:
    1. Changing the setting of any user interface component must not automatically cause a change of context if the user has not been advised of the behavior before using the component.
    2. If changing the setting of a user interface component causes a change of context, the instructions advising the user of this must explain how to accessibly use the control.
  • Record results under "Change of Context" on the results template.

23. Consistent Navigation / Consistent Structural Markup (WCAG SC 3.2.3 Level AA)

  • Protocol:
    1. List components that are repeated on each page / tool
    2. Note the relative order that the various components appear in on the page.
    3. Use Firebug to examine the structural markup used to layout the components (list, table, proximity of headings, ARIA landmarks, etc.)
  • Criteria:
    1. Each component must occur in the same relative order with regard to other repeated components on each page it appears.
    2. The structural markup used to layout a given component must be consistent across each page it appears.
  • Record results under "Consistency" on the results template.

24. Consistent Navigation: Access Keys Usage (WCAG SC 3.2.3 Level AA)

The accesskey attribute, introduced in HTML4.0, is intended to provide keyboard shortcuts in that they provide an alternative form of navigation. (Mac: Use the ctrl key rather than the option key to test accesskeys.)  The accesskeys currently contained in Sakai are:

  • Protocol:
    1. On the Accessibility Extension tool bar, click on the Navigation icon, and select "Access Keys."
  • Criteria:
    1. The following accesskey assignments must be present in each Sakai CLE page (in the portal):
      1. c = Skip to content
      2. l = Beginning of Tools list (the letter "l")
      3. w = Beginning of Worksite tabs
      4. 0 = Accessibility page
      5. 6 = Portal help page
    2. Tool-specific:
      1. Alt + e = Edit or Revise
      2. Alt + h = Tool help page
      3. Alt + s = Save
      4. Alt + u = Manual refresh
      5. Alt + v = View or Preview
      6. Alt + x = Remove, delete or cancel
    3. All accesskeys assigned to elements on the page must be unique.
    4. All accesskeys must be on labeled elements that are unique and describe the purpose / function of activating the element.
  • Record your findings in the template next to "Access keys".

25. Indicating Change of Context (WCAG SC 3.2.5 Level AAA)

  • Protocol:
    1. Activate each link on the page to check if it opens in a new window
  • Criteria:
    1. If a link opens in a new window, it must:
      1. Links that open in a new window must use the target attribute to do so (provides a machine readable indication that the link will open a new window) (H83).
      2. Links that open in a new window must have link text that indicates the link will open in a new window (H83).
  • Record results under "Change of Context Notification" on the results template.

26. Error Notices (WCAG SC 3.3.1 Level A)

  • Protocol:
    1. Fill out a form, deliberately leaving one or more required (mandatory) fields blank, and submit it.
  • Criteria:
    1. If an error is identified, the error must be described to the user in text.
    2. Error messages must have a text description identifying the any field(s) containing errors.
    3. Error messages must have a text description describing how to fix the error unless that information would invalidate the activity.
  • Record results under "Error Notices" on the results template.

27. Required user input is labeled (WCAG SC 3.3.2 Level A)

  • Protocol:
    1. Analyze each form's input controls to see which are required
    2. Examine the associated legend and label to see if an indication was made that input is required.
  • Criteria:
    1. For each required form control, check that the required status is indicated in the form control's label or legend.
      1. If the control is a member of a fieldset group, the required status must be indicated in the legend and not also in the label.
      2. If the control only has a label, the required status must be indicated in the label.
    2. Sakai CLE uses an asterisk placed inside and at the very beginning of the element's label or legend to indicate a required input control.
    3. Check that the meaning of the asterisk / required field indicator is explained before the form that uses it.
  • Record results under "Required Field Notification" on the results template.

28. Error prevention (WCAG SC 3.3.4 Level AA)

  • Protocol:
    1. Examine the actions/transactions users can make on a given page.
    2. Evaluate each transaction to see if it represents a significant action/transaction that could be error prone and/or have undesirable irreversible consequences if performed in error.
  • Criteria:
    1. Significant transactions must be either reversible, checked for errors, or confirmed (can review, correct, and confirm) before finalizing submission.
  • Record results under "Error Prevention" on the results template.

29. Help - Context-senstive help is available (WCAG SC 3.3.5 Level AAA)

  • Protocol:
    1. Activate the help features found in the tools list, in the tool's title bar, and any other help features found.
    2. Note the result of activating the help features.
    3. Examine the labels provided for the help features.
    4. Examine the help features and note if they are assigned an accesskey.
    5. Examine the help feature to see if a anchor tag is used and the target attribute is used to open the link in a new window.
  • Criteria:
    1. The help link in the tools list must bring up the Sakai Help tool in a new window to its default page.
    2. The help icon in the tool's title bar must bring up the Sakai Help tool in a new window with the main help page for the current tool as the default page.
    3. The link text / label for each help feature must indicate that it opens in a new window.
    4. The target attribute must be used to indicate the link opens in a new window (<a target="_blank" ...>).
    5. Accesskey '6' must be assigned to the help tool link found in the tools list.
  • Record results under "Help" on the results template.

30. Compatibility / Validation (WCAG SC 4.1.1 Level A)

  • Protocol:
    1. Use a built in code validation tool to validate the main portal page and each sub-frame's code.
  • Criteria:
    1. Elements must have complete start and end tags except where the specifications allow otherwise.
    2. Elements must be nested according to their specifications.
    3. Elements do not contain duplicate attributes.
    4. All IDs assigned must be unique.
    5. (X)HTML and CSS code validates to specified standard (in the DOCTYPE) as much as possible, except where required functionality or accessibility features prohibits (i.e.: ARIA attributes, embed / object elements, etc.)
  • Record results under "Validation" on the results template.

31. Check the Page with Automated Accessibility Checkers

  • Protocol:
    1. Run automated accessibility checker that is capable of checking the dynamically generated code in the main page and each sub-frame.
    2. If possible, configure the check to evaluate to Section 508 Standards and WCAG 2 Level AA Guidelines.
    3. Recommended accessibility checkers:
      1. The following accessibility checkers can be used to evaluate a given page including all the updates scripting has made to the Browser's DOM, check all frames / iframes, etc.:
        1. Deque Fireeyes (http://worldspace.deque.com/FireEyes/login/auth)
      2. The following checkers will require manually capturing (X)HTML code the current DOM representation of the page using Firebug, and then pasting the (X)HTML code into the checker's online form. It is likely that each frame's code will have to be checked individually.
        1. aChecker (http://achecker.ca/checker/index.php)
  • Record any other accessibility issues that are caught in the appropriate category on the reporting template.

Notes:

  • Be sure and both how to configure and the limitations of the automated accessibility checker(s) you use.
    • Some tools will not evaluate content in frames, iFrames, nested frames, etc.
    • Some tools will be confused by advanced CSS and not accurately report color contrasts
    • Most tools do not ignore content that is being hidden from both sighted and adaptive technology users (CSS: "display:none", "visbility:hidden", ARIA: aria-hidden="true", aria-disabled="true", etc.). This is especially a problem with hidden content that is only partially populated until use (DHTML Pop-ups, dialogs) and hidden error messages that only appear when needed (blocks of code hidden with "display:none").
    • The FAE add-on likes to report buttons as unlabeled even though they obviously have button text (the value attribute).

32. Go to the next page, function, or feature of the Sakai tool being evaluated.

33. Repeat steps 1 through 32 until the tool has been completely exercised and evaluated.

34. Save your review by attaching it to the Sakai 2.9 Accessibility Review Results (2011) page of confluence using a description such as "Resources_2.9_FirefoxToolbars_Review".