Sakai 2.9 Mailsender Firefox Comprehensive WCAG 2 Protocol Results

Browser(s) / OS Used:

Firefox 8 / Windows 7 64 bit

Sakai Tool:

Mailsender / Mailsender Page on Confluence

Page(s) Tested:

Compose Page, Options Page

Date:

2012.03.22

QA Server:

QA Server Environment:
(Copy from footer)

Evaluator(s):

Brian Richwine

Evaluation Complete: (Yes / No):

No

Images

Fail - The paper clip image has a redundant (and improper) alt text value of "attachment_img"

<IMG src="http://sakaicle1-trunk.uits.indiana.edu:8181/mailsender-tool/content/images/paperclip.gif" alt="attachment_img" height="15" width="15">

This text description of "attachment_img" for this image is redundant to the following link text of "Attach a file".

Image descriptions that don't add any meaningful information should be empty. Change the alt attribute to be alt="" on this image:

<IMG src="http://sakaicle1-trunk.uits.indiana.edu:8181/mailsender-tool/content/images/paperclip.gif" alt="" height="15" width="15">

Also, as a note, alt text should be meaningful text and the words should be separated by spaces instead of underscores. Also, abbreviations should be avoided in alt text. Also, alt text for images should not include that it is a image as that will already be announced by the adaptive technology and will be annoyingly redundant.

Major

Linearized Content

Fail - Email tool page structure's does not linearize well. Again, this is due to the non-described relationships between all of the links/checkboxes for addressing the email (To:).

Did not look at all possibilities of CKEditor documents since that isn't in the scope of this evaluation.

See comments in semantics / labeling.

Critical

Reliance on Sensory Characteristics

OK - no instructions or descriptions dependent on sensory descriptions were found.

Use of Color

OK - Color is not being used as the sole means for providing info

Sufficient Contrast

Resizable Text

OK - Page Zoom in Browser can go to 200%

Semantics

Fail - The meaning and interdependence / relationships for the controls used to select the recipients are not available to non-visual users and not totally clear to sighted users:

   1. Links are being used where radio buttons would traditionally be used. The "Roles", "Sections", and "Groups" links are being used as if they were radio buttons. Neither their relationship as such and interdependence is described semantically.

   2. The function of activating the links is not described to non-visual or visual users alike. The links are often being used to toggle the visibility of a list of checkboxes (list of instructors, students, etc.). This function, and the current state of the control, is not revealed semantically / programmatically (ARIA). Standard visual icons are not supplied ([+], [-], etc.) to indicate that activating the links will toggle the visibility of a section of the form.

   3. The function of selecting/unselecting the checkboxes is not described to non-visual users. The checkboxes are often being used to toggle selection of all checkboxes in a series of checkboxes. This function is not described meaningfully by the controls' labels.

   4. The hierarchical relationship between controls is not described. Checkboxes are nested visually (indented) and that relationship is not described semantically. For instance, if the "Roles" link is activated followed by the "Student" link, a series of checkboxes is revealed (one for each student).

   5. Lists of controls are not contained in lists or blocked together. When a series of controls are related and represent a list, they should be encoded as a list. This way, a non-visual user can know they are in a list of related items, how many items are in the list, and their position in navigating/perceiving the list.

   6. Many controls are completely unlabeled. All controls must be labeled. The purpose of unlabeled controls will not be clear to non-visual users; even worse - adaptive technologies may attempt to guess at the control's label and guess wrong thereby misleading the user.

Consider using a treeview to display and provide selection of recipient options. Code the treeview with ARIA so the role, function, and state of the treeview are fully described. Code the keyboard handling appropriately to standards to meet preexisting expectations / user models.

Or, do extensive work relaying out the recipient controls. Provide meaningful labels that are descriptive of each controls function and relationship. Use fieldset and legend elements to describe the relationship between controls. Make sure the use of the control matches the effective function/relationship/semantics (radiobuttons where radiobuttons should be used -- not links).

Make sure traditional, easily recognized icons are provided that indicate function and state of controls.

Critical

Keyboard Operatibility

Fail - Controls are used in non-standard ways, but are functional. No means for easily navigating long "lists" of controls are provided.

Consider using a treeview to display and provide selection of recipient options. Code the treeview with ARIA so the role, function, and state of the treeview are fully described. Code the keyboard handling appropriately to standards to meet preexisting expectations / user models.

Critical

Time Limits

OK - None detected

Control of Updates

Prevent Seizures

OK - No flashing content found.

Bypass Blocks - Headings

Fail - There is a hidden level three heading at the start of the email form that is being hidden with CSS using visibility:hidden. This heading will be invisible to adaptive technologies and sighted users alike. The purpose of this heading isn't clear. The heading is also redundant with the non-semantic (untagged) "Compose" text that occurs in the "navIntraTool" div. Because the heading is hidden, the heading cannot be used to navigate to the top of the form.

Suggestion:

Remove the untagged "Compose" text that occurs in the "navIntraTool" div (tool action bar) and make the <h3>Compose</h3> visible to all users. The action bar should be reserved for actionable items.Making the heading visible will allow adaptive technology users to easily move back to the top of the Compose form (most screen-reading software and other adaptive technologies allow easy intra-page navigation by headings).

Major

Bypass Blocks - ARIA Landmarks

No ARIA landmarks used by the tool. Tool does not conflict with the portal's ARIA landmarks.

Bypass Blocks - Skip Content Links

Tool does not conflict with the portal's skip content links.

Bypass Blocks - Group Links

Fail - the "All", "Roles", "Sections", and "Groups" links in the "To:" section should be in a list to make clear their relationship to non-visual users.

Critical

Bypass Blocks 

Fail - No means of skipping or easily navigating to the various sections of the form is provided. If checkboxes are displayed for each student in the course a keyboard only user may have to navigate through 100 or more checkboxes one at a time by tabbing (or shift+tabbing) to reach other controls.

Suggestions:
  1. Consider using an accessible (ARIA) treeview control for the "To" / recipient options. This would allow standardized keyboard navigation among the various recipient controls and an easy/efficient means for entering and exiting the tree control.

Critical

Bypass Blocks - Frame Titles

OK - All frames have unique and meaningful titles.

Page Titles

Fail - No page title for the tool document.

All HTML documents need to have a title element that is a child element of the head element.

Some adaptive technologies will read the page titles of pages inside of frames. Window title will be missing if frame is opened in a separate window.

Recommendation: Supply a title that is unique and meaningful that describes the tool's name, function, or purpose. Possibly:
<head>
  <title>Email</title>
...
</head>

Minor

Focus

OK -  Visible indication of input focus is present on all focusable elements.

Links

Fail - The purpose of the various links in the "To:" section of the form is not clear and are especially unclear to non-visual users.

Critical

Links

Fail - When multiple attachments are provided, multiple "Remove" links become present and are not distinguished from each other.

Critical

Headings

Hierarchy of headings, and heading descriptions are OK, however problems exist. Please see the "Bypass Blocks - Headings" section above.

Please see the "Bypass Blocks - Headings" section above.

Major

Labels

Fail - Compose Page - In the "To:" section, the default "All" checkbox is labeled, but does not describe its function. "All" does not describe that the checkbox can be used to toggle selection of all of the displayed recipient checkboxes.

Use extra contextual text to describe the control's function.

For example:

<label for="mailsender-rcpt-all">All<span class="skip">: toggle selection of all displayed recipient checkboxes.</span></label>

Labels

Fail - Compose Page - Checkboxes for toggling selection of all checkboxes in subgroups are not labeled. For instance, if "Roles" is selected then the checkboxes to toggle selection of all Instructors, Students, and Teaching Assistants are unlabeled.

Use extra contextual text to describe the control's function.

For example:

<label for="mailsender-usersGroupOption:0:mailsender-usersGroup-role">
<span class="skip">Toggle selection of checkboxes for all displayed: </span><a id="mailsender-usersGroupOption:0:mailsender-usersGroupLink-collapse-role" ...>Instructor</a></label>

Labels

Fail - Compose Page - The "Other Recipients" textbox is not labeled.

The instructions for entering the other recipient email addresses are not tied to the text box. Text outside of form controls and form control labels will not be available to screen-reader users who are navigating in "forms" mode.

Suggestions:

1. Use an explicit label to label the Other Recipients textbox.

2. Use an aria-describedby attribute on the textbox element to tie the instructions to the textbox.

For example:

<div style="" id="otherRecipientsDiv">
   <div>
       <span><label for="otherRecipients">*Other Recipients:</label>*</span>
   </div>
    <div id="otherRecipientsValue">
       <input type="text" value="" name="otherRecipients" id="otherRecipients" aria-describedby="otherRecipientsInstructions"><input type="hidden" value="istring" name="otherRecipients-fossil">

       <div id="otherRecipientsInstructions">Separate additional email addresses with commas or semicolons.</div>
    </div>
</div>

Labels

Fail - Compose Page - The "Subject:" textbox is not labeled.

Add an id on the input field and place an explicit label around the text label:

 For example:

<div>
    <div>
         <span><label for="subject">Subject:</label></span>
     </div>
     <div>
          <input type="text" value="" id="subject" name="subject"><input type="hidden" value="istring..." name="subject-fossil">

       </div>
  </div>

Labels

Fail - Options Page - The file attachment textboxes are not labeled.

Since a text label is otherwise non-available, use a title attribute on the textbox element to provide a label to adaptive technologies:

<input type="file" name="attachment0" title="File Attachment 1">

Language Identification

Fail - The default human language of the tool's page is not specified.

Critical

Change of Context

Consistency

Accesskeys are used inconsistently.

Tool name changes from "Email" to "Mail Sender" and "Mailsender" in various places.

Please see comments in the Help and Access key sections.

Access keys

Fail - Inconsistent use of accesskeys. Compose and Options pages do not use accesskeys, however the Permissions page uses "s" for saving, and "x" for cancel.

Consider consistent use of accesskeys on buttons that submit or cancel the form actions.

Major

Change of Context Notification

Error Notices

Required Field Notification

Error Prevention

Help

The help page for the email tool has links which do not function rendering the help for the email tool inaccessible.

Fix the broken links in the Email tool help.

Critical

Help

The help system refers to the tool variously as "Mails Sender" and "Mailsender", but not "Email". Users will be confused when using the contents of the help system as to why the Email tool isn't covered.

Use consistent naming of the tool in all places.

Major

Help

Help page for the email tool does not provide any accessibility information.

Include accessibility help for using the email tool.

Help

No help information is available and accessible to keyboard only users about how to use the CKEditor using only the keyboard.

1. Provide a link just above the editor to a help page on the CKEditor.

2. In the context sensitive help for the email tool, include a link to help for the CKEditor.

Validation