2.01 and 2.1 Accessibility Testing Protocol

Owned by Former user (Deleted)
Last updated: May 17, 2006 by Former user (Deleted)Version comment
5 min read

Background. This is a protocol for testing Sakai 2.0.1 RC3 accessibility, code accuracy, and, to a limited degree, functionality. In particular, Sakai will evaluated for compliance with Section 508 requirements plus WCAG 1.0 Priority One and Two guidelines, validated against XHTML 1.0 Transitional code requirements, and tested for accessibility-related functionality. Evaluators will provide developers with corrected code to facilitate repairs. It is anticipated that the next version of Sakai will be tested for adherence to WCAG 2.0 Level 2 requirements, however, at this time evaluation tools are not available that can effectively test password protected, iFrame applications.

Alternatives Explored. Several alternatives were explored in an attempt to automate the process and/or reduce steps.

o Bobby 5.0 (download): Could not access password-protected tools despite setting uniquename and password option.
o Bobby 5.0 from within Dreamweaver MX: Would not operate properly.
o Dreamweaver MX Accessibility Checker: Did not seem as thorough as other checkers.
o ATRC Online Checker for WCAG 2.0: Password protected pages could not be accessed. Downloaded html pages could not be accessed. Note: There will be a significant upgrade in September that appears very promising and will address these issues; I am concerned, however, that we will not be able to give developers enough lead time if postpone our evaluation until then.

Tools. Three tools will be used: A-Prompt (http://aprompt.snow.utoronto.ca/), a desktop evaluation and repair tool developed by the University of Toronto Adaptive Technology Resource Centre (ATRC), Firefox browser (http://www.mozilla.org/products/firefox/) with the FANGS extension added, and the online W3C HTML Validator (http://validator.w3.org/). It will be helpful to add the Validator to your browser as a bookmark. It is also helpful to use an html editor like Dreamweaver to review the repairs A-Prompt has made to code, and add heading or link tags.

Revisions to Sakai should be entered into a spreadsheet (attached as file), to facilitate developer repair and subsequent QA.

Methodology. The following sequence is recommended:

1. Open A-Prompt.
2. Set compliance settings by pressing the "Settings" button, go to the "Conformance Level" tab and choose "Section 508 Compliance."
3. Click on the "Advanced" button, go through the list of settings and turn on all Priority One and Priority Two settings. Press OK.
4. Go to the "Saving Files" tab, and choose the "Allow user to select a name for the repaired file" option. Press OK.
5. Open the Sakai 2.0.1 RC3 site: http://sakai-stable.mit.edu:8030/portal .
6. Login using the user name/password combination of admin/admin.
7. Go to your assigned tool(s). Some tools will appear on the first page. If not there, go to the "Accessibility Test" worksite in the tabs.
8. Go to the Tool section of Firefox, and click on Fangs
9. Go to the tab marked Headings list and check for: 1) meaningful heading labels, 2) an accurate hierarchy (h1, h2, h3, etc.), and 3) a thorough use of headings. Mark your findings and recommended changes on the spreadsheet in a category called "Headings" or "Labels," as appropriate.
10. Go to the tab marked Links list and check for: 1) redundant link names, and 2) meaningful link names. Mark your findings down in the spreadsheet under "Links."
11. Go back to the browser, and roll over links with your mouse. The title tag text will appear. Check this text to see if it provides sufficient and meaningful context. Supplement, as necessary, your findings under "Links."
12. Go back to the browser, and tab through the application. A dotted box will show you the focal point. As you tab through the application, check for the following: 1) tabbing moves in a logical fashion, and 2) all key items receive focus. Put any problems with the recommended changes into the spreadsheet.
13. Place your cursor over the content area (or frame portion) of the page (see Picture 1), right click your mouse, and open the frame in a separate window.
14. Save the frame as html code, giving it a name that describes tool content (such as "WorksiteSetupDefault" and save it in a folder such as "Worksite Setup Repairs." Note: You may find it easier to save all the frames at once, rather than one by one as you test.
15. Go to A-Prompt
16. Locate the folder containing the file(s) you have saved for evaluation in "Select Files to Repair".
17. Open the folder, choose the file to review and repair and press "Repair" in A-Prompt.
18. Click on each item under "Required for Conformance," establish why it is non-compliant, and make the appropriate repairs. Note: Be sure to review the "Not Required For Conformance" section, since some Priority One and Priority Two items may be lurking there.
19. Enter the reason for non-compliance on a spreadsheet (see page 3) and the repair you have made, recommended or have a question about.
20. In some cases you may be unsure how to repair the code. If you can, put in a placeholder called "REPAIR" and move on to the next item. Otherwise note the item in the spreadsheet.
21. After you have addressed all the compliance issues, save the repaired file with "rev" added to the original name.
22. Open the file in Dreamweaver MX or a similar html editor. Verify the changes made by A-Prompt, and make any additional changes you have recommended for headings, labels, title tags, etc. Have your html editor also make any code repairs that are necessary. You can find it in Dreamweaver under Commands > Clean up XHTML. Re-save the file.
23. Go to the W3C HTML Validator webpage: http://validator.w3.org/
24. Find "Validate by File Upload and browse to find the revised file. Press "Check."
25. Review and save the results under a name that reflects the html name for the revised file, such as "WorksiteSetupDefaultRevValidation." This should be a very short list of necessary repairs.
26. Reopen the html file in your html editor, and make the corrections specified by the W3C HTML Validator.
27. When you are finished with each file, note on the revised file where you have made changes by highlighting the changes in a larger size font, bold and blue. You can do this by saving the file as a Word document and highlighting it there.
28. Repeat steps 12 through 24 for each page in your assigned tool

Testing Hints
Tool Locations
Tools (except those listed on the Sakai home page) can be found in a worksite I've created called Accessibility Test. You all have administrative privileges, so you can upload a file, create a message, etc. for testing.

Usability Issues
If you come across something that doesn't seem to make sense usability-wise, put it in the spreadsheet as "Usability" with a description. I'll forward it on to the developers. But don't get too hung-up on issues not related to accessibility...

Bugs
If you find something that doesn't seem to work properly, please note it on the spreadsheet as "Bug", create an account on Jira under "Signup for an account,"and enter the bug into the Jira database under "Create New Issue." The Jira URL is:

http://bugs.sakaiproject.org/jira/secure/Dashboard.jspa

Headings
Think of headings both as a mechanism for screen reader users to skim through the content of a page and to navigate to areas of interest. They should provide a sense of organization and relationship.

Turning off Style Sheets
You can check if the page is still readable with style sheets turned off by going to View > Page Style > No Style in the Firefox browser.

Turning off Java and Javascript
You can check whether page commands work with Java and Javascript turned off by going to Tools > Options and unclicking "Enable Java" and "Enable Javascript" in the Firefox browser. Remember to refresh the page (Control + R) to turn on the new settings.

Adding Text and Headers
It is best to preserve existing code, even if it means duplicating existing text (as in adding a caption). This will help provide developers with context for the change.

Repairing XHTML Code
If you are using Dreamweaver, use the Commands > XHTML command to automatically repair unclosed tags. Then use File > Check Page > Validate as XML to check XML syntax.

Validating XHTML Code
The "NOSCRIPT" place holder provided by A-Prompt in response to the <script type...> statement in the <head> section will cause the page to fail validation. Remove the script before you validate the page for a more accurate result.