Sakai 2.9 Quick Firefox Accessibility Evaluation Protocol

This is a work in progress and doesn't yet represent the intent of this page. Please check it again in a couple of days.

This is an easy to use (hopefully!) protocol for performing a quick evaluation of a Sakai 2.9 tool's accessibility. The protocol works with either the Windows or Mac OS X operating systems and the Mozilla Firefox Web browser and a suit of free accessibility plug-ins in Firefox. Please follow the instructions listed in the "Workflow / Process" section below.

Note: it is advisable to also perform keyboard accessibility testing using Internet Explorer. Internet Explorer handles keyboard interactions and event firings for the standard form controls differently than Safari and Firefox. The most common OS/Browser/Screen-reading software combination used is Microsoft Windows + Internet Explorer + Freedom Scientific's JAWS screen-reading software. Due to these differences, and since users with low-to no vision cannot see to use the mouse, "keyboard-only" testing cross the Web browsers, and especially with Internet Explorer, is essential.

Background

This is a protocol for performing a quick technical accessibility evaluation of Sakai 2.9 and was designed with the Sakai CLE developer in mind. For a more comprehensive technical accessibility evaluation protocol, please use the Sakai 2.9 Comprehensive Firefox WCAG 2 Accessibility Evaluation Protocol instead.

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
  • 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 Quick Firefox Accessibility Protocol (record "QFAP") on the table.
  • Get a reporting template:
    • Create a copy of the Sakai 2.9 Quick Firefox Accessibility 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 Quick Firefox Accessibility 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 Quick Firefox Accessibility 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)

Quick Sakai CLE Tool Accessibility Evaluation Protocol

1. Check Page Structure Markup

Understanding why to check page structure markup.

Watch a video on how to check page structure markup.

  • Check the Page Title
    • Protocol:
      1. Inspect the page's title.
        1. Use one of the following techniques:
          1. Use Firebug to view the title element in the head section.
          2. Hover the mouse over the browser tab and see if the whole title appears.
          3. Right click in the page and select the "View Page Info" option in Firefox. The title is listed in the resulting dialog box.
          4. Select "Navigation > Title" on the Firefox Accessibility Extension toolbar.
      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 (X)HTML head section.
      2. The title must describe the page content / function.
      3. The Web page must be identifiable by the title (this means it must be unique).
      4. Notes:
        1. For Sakai CLE the page title is probably set by the portal and not the selected tool's code, however it is important to always check it is working correctly.
        2. The page title format in Sakai CLE should be as follows:
          1. Not Logged In:
            1. (Sakai Server Instance Name) : Gateway : (Tool Name)
          2. When Logged In:
            1. (Sakai Server Instance Name) : (Site Name) : (Tool Name)
    • Record your findings under "Page Titles".
  • Check Frame Titles
    • Protocol:
      1. Select "Navigation > Frames" on the Firefox Accessibility Extension Toolbar.
      2. Examine each frame listed for an appropriate title.
    • 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 under "Frame Titles".
  • Check the Headings
    • Protocol:
      • Inspect the headings using the Headings Map add-on for Firefox.
    • Criteria:
  • Check that heading markup is used when content should be a heading (make sure all text that should be a heading is listed in the headings map).
    1. *## Check that heading markup is not used for formatting when the content is not actually a heading (look for entries in the headings map that shouldn't be there).
      1. Check that heading levels are used appropriately to form an accurate hierarchy (h1, h2, h3, etc.)
      2. Check that each section of the page starts with a heading that identifies/describes the section of the page.
    2. Record your findings under "Headings".

2. Check Link Texts

Understanding why to check link texts.

Watch a video on how to check link texts.

  • Check the Link Texts
    • Protocol:
      1. Select "Navigation > Links" on the Firefox Accessibility Extension Toolbar.
    • Criteria:
      1. All links should have link text (none with missing (empty) link text).
      2. There should be no links with the same text that go to different locations or perform different functions.
      3. 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.
        5. ASCII symbols alone (i.e.: "<", ">", etc.) are not sufficient for describing a link.
    • Record your findings under "Links".

3. Form labels, required field indication

Understanding why to check page structure markup.

Watch a video on how to check page structure markup.

Check the Link texts

  • Protocol:
    1. Select "Navigation > Links" on the Firefox Accessibility Extension Toolbar.
  • 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.

4. Alternative text for images

Understanding why to check page structure markup.

Watch a video on how to check page structure markup.

  • Protocol:
    1. Select "Text Equivalents > List of Images" on the Firefox Accessibility Extension Toolbar.
  • 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

5. Keyboard accessibility

Understanding why to check page structure markup.

Watch a video on how to check page structure markup.

  • 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
  • *# 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.
    1. 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.
    • 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".
  • Record Results under "Keyboard Functionality" on the recording template.

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