[WG: Accessibility] Questions I'm not sure how to answer

[Richwine, Brian L]

> Would it be alright if I tried to add this to one of the Confluence pages in the accessibility WG?

That's fine with me. I'm guessing that somewhere on or off of the current accessibility page would be best. However, if in your recent reading of the WG's site you see a better place for it I'm happy with that too!

-Brian
________________________________________
From: khomotso at gmail.com [khomotso at gmail.com] on behalf of Clay Fenlason [clay.fenlason at et.gatech.edu]
Sent: Wednesday, March 02, 2011 6:52 PM
To: Richwine, Brian L
Cc: accessibility at collab.sakaiproject.org
Subject: Re: [WG: Accessibility] Questions I'm not sure how to answer

Reams of thanks for this thorough response, Brian. Would it be alright
if I tried to add this to one of the Confluence pages in the
accessibility WG? I want to capture this valuable information for
others, but I don't want to mess up the group's space if you'd rather
I didn't.

~Clay

On Wed, Mar 2, 2011 at 6:42 PM, Richwine, Brian L <brichwin at indiana.edu> wrote:
> Hello Clay,
>
> First to answer the two questions:
>
> Question 1. "Is this platform compliant with Section 508c of the Rehabilitation Act?  What are the accessibility features?"
>
> I'm assuming this question applies to core tools of the 2.8.0 release. Compliance to Section 508 (and the stated goal of meeting WCAG 2.0 A & AA Success Criteria) varies from tool to tool, and to a certain extent depends on how tools are configured.
>
> Note: The current Section 508 Web Standards are quite old (1999). The WCAG 2 Level A and AA Success Criteria, and their associated techniques for success, are generally the internationally recognized standards to meet for accessibility conformance. If the WCAG 2 Level A and AA Success Criteria are met, then the Section 508 §1194.22 Standards will be met. It is possible to meet all Section 508 §1194.22 Standards, and not meet the WCAG 2 Level A and AA Success Criteria.
>
> Any tool or task that requires the student to use the JavaScript WYSIWYG editors, and the other Rich Text Editors found in Sakai, will pose challenges to non-mouse users (low-vision, blind, and users of alternate input devices). The CKEditor would be a big improvement over the FCKeditor. It isn't clear to me which editor (or editors) Sakai 2.8.0 will be released with. The FCKeditor is completely inaccessible (it can trap keyboard focus for sighted non-mouse users, its presence is often undetectable to screen-reader users, and the toolbar and text formatting functions are inaccessible).
>
> No one has perfected an accessible JavaScript WYSIWYG editor. The CKEditor is generally accessible, however can require significant effort on the part of an adaptive technology user to learn how to use it effectively. It is the most accessible WYSIWYG editor we have tested. A less obvious, but big plus with the CKEditor, is that users would gain the advantage of being able to paste documents into the editor from more accessible external editors (like MS Word) that they are likely much more competent at using with their adaptive technologies.
>
> We've started creating a document for faculty at IU on how to create accessible courses using Oncourse (IU's Sakai implementation). That document is attached. It lists tools based on their accessibility and lists the specific accessibility concerns and available workarounds for tools that are only partially accessible. Much of a disabled user's experience, and how accessible Sakai 2.x feels to them, is determined by the content uploaded to it. A document on how to create accessible courses in Sakai for instructors and a document for institutions on how to maintain Sakai's accessibility when configuring and skinning Sakai would be wonderful additions if we had the resources to create them.
>
> Accessibility Features:
> 1. CKEditor (if released with it)
> 2. Skip Navigation / Jump-to links with consistent accesskeys (keyboard shortcuts) 3. Consistent use of Headings to delineate interface features / page structure (this is a feature of the portal) 4. Tested to internationally recognized standards (WCAG 2.0 Levels A and AA Criteria) using expert review, manual and automated code review, and tested for real functional accessibility by users of adaptive technologies who follow tasked based walkthrough scripts.
> 5. All images / icons have appropriate alternative text descriptions 6. Complex data tables have table summaries that inform screen-reader users about the table's purpose and how it is structured 7. Consistent visible indication of keyboard focus is available for sighted keyboard only users (applies Sakai CSS skin as released) 8. Accessibility Information and Help is available in the built-in Sakai Help tool.
> 9. Accessibility Statement and documentation is available (for Sakai 2.8.0) that:
>     a.) Indicates accessibility standards the Sakai developer community strives to meet
>     b.) Indicates accessibility barriers and workarounds (where available)
>     c.) Indicates points of contact (Sakai Accessibility WG lead and Accessibility WG email list) for institutions and users to report accessibility issues / concerns and to receive help and answers to accessibility questions.
>
> There are several tools that have significant accessibility barriers for some users. Besides tools that rely on the WYSIWYG editor, these include the Profile2, Drop Box, and Forums.
>
> Here are some of the accessibility issues still in Sakai that the Sakai Accessibility WG is working on:
>
> . Implicitly labeled checkboxes and radio buttons are still used by some tools and is not supported by screen-readers (especially when used with IE)
>  - Technically, meets accessibility standards but doesn't work in reality
>  - Screen-readers generally don't support implicitly labeled controls.
>  - Older rendering technologies, velocity, etc. don't always generate explicitly labeled controls
>  - S: We have a jQuery routine that can automatically convert implicitly labeled controls into explicitly labeled controls. It will require updates to many tools. Plan on including in Sakai 2.9 (is back portable)
>
> . Form input buttons with ASCII symbols instead of meaningful text (i.e.: "|<") aren't accessible to non-visual users
>  - S:  We have a non-traditional ("creative") fix for this being tested right now. Plan to include in Sakai 2.8 (is back portable)
>
> . Status messages / Result messages
>  - Ephemeral messages that display for only a few seconds go unnoticed by screen-reader users, and may be problematic for those with scanning and reading disabilities.
>  - Nothing draws notice to success/fail messages/form validation error messages for screen-reader users
>  - Investigating WAI-ARIA features for live regions and form control status attributes. But this won't help readers with scanning / reading difficulties.
>  - Need to develop best practice techniques for each use case
>
> . Select elements (drop down menus) w/onchange even handlers that switch context/submit page
>  - Users should be able to explore the options safely without activating the control. This is a problem in IE and Opera.
>  - S: We have a jQuery interaction handler we want to include in 2.9 that addresses this (is back portable)
>
> . Pop-up messages are generally inaccessible. These occur as:
>  - Title attributes used as tooltips
>  - DHTML/jQuery pop-ups
>  - S: We are researching a solution for the various use cases and developing best practice techniques for each case
>
> . Failure to support user display preferences
>  - The newly proposed Section 508 revisions will require support of user display preferences (font size, font color, high-contrast mode, etc.). Currently neither Sakai 2.x nor Sakai OLE support this.
>  - S: Need alternate high contrast CSS skin and user preferences to select in Sakai 2.x, Need to support user skinning in Sakai 3
>
> . Screen-reader users have great difficulty in selecting multiple options in multi-select select elements.
>  - Example: Screen-readers find it extremely difficult and often make errors selecting multiple users to send a message to
>  - Probably will require UI changes
>
> . Drag 'n drop reordering controls are generally inaccessible or have significant usability issues.
>  - Technically there is a method for non-keyboard users to use the fluid reordering tools, but it is not obvious. Insufficient structural semantic information is passed to screen readers for these tools to be usable as well.
>
> . Many tables don't meet accessibility best-practices
>  - Data tables in Sakai generally lack row headers
>  - Table summaries frequently outdated / incorrect
>  - Inconsistent table layout confuses users
>  - Blank columns / rows used for formatting table instead of CSS. This leads to semantically confusing table structures.
>
> . User interface inconsistencies, especially the underlying semantic structure used to layout tool features (like the tool's menu bar). Users are required to learn different strategies to perform similar features that exist across tools.
>
> Question 2. "How can users with disabilities access this platform using text to speech software (JAWS, VoiceOver), speech to text software (Dragon Naturally Speaking), and other accessibility software (refreshable Braillers, electronic notetakers, etc.)?"
>
> The Sakai Help tool includes an "Accessibility Information" page. For example, the IU Oncourse system's Accessibility Information page is: https://oncoursehelp.iu.edu/helptool/doc/arkn
> This page includes lists of accessibility features, barriers, configuration and user hints for JAWS and WindowEyes. The Accessibility WG needs to find, and work with, an experienced Sakai user who is proficient at using Sakai with VoiceOver before we are confident enough to add configuration and user hints for VoiceOver.
>
> Dragon NaturallySpeaking users will have to know how to use the mouse emulation commands to access nonstandard controls (like the add and action menus in the Resources tool). Dragon NaturallySpeaking users will also have to know how to work drop-down lists (select elements) to be successful at using many Sakai tools (this requires using keyboard emulation commands like saying "press control spacebar" and "move down", etc. ).
>
> Refreshable Braille displays work in combination with screen-reading programs and could only enhance a screen-reader user's experience.
>
> For the term "electronic notetaker", it is assumed they mean portable devices like a PAC Mate from Freedom Scientific which is a portable device that includes either chorded Braille key input or QWERTY keyboard and runs a version of Microsoft Windows, JAWS, and Microsoft Office.  Some limitations of these devices would reduce the practicality of using Sakai with them (for instance, most lack a PDF reader application). We haven't tested Sakai with one of these devices, but in general, they can access any web site JAWS can.  Beyond the lack of support for certain document formats, users of these devices might have some success accessing Sakai, however that is just our educated guess.
>
> We have a blind student at IU who claims to use Oncourse (IU's Sakai implementation) with both an iPad and his Macbook. We don't know what tasks he actually has performed with them, but he had no complaints. Some tools (like the Wiki tool), apparently depend on hidden flash applets, which might limit their successful function on an iPad since iOS devices don't support Flash.
>
> -----
> Sakai Accessibility Status Documentation
>
> I'm sorry that the Sakai accessibility documentation is not currently in a state such that it answers your questions. The Accessibility Working Group recognizes that the Sakai Accessibility documentation is less than ideal and developed a plan to improve/overhaul the documentation with the Sakai 2.8.0 release. The plan is as follows:
>
> When the 2.8 release draws closer, we will update/overhaul the Sakai "Current Accessibility" pages on the Accessibility Working Group's pages. They need to be more organized and professional in appearance, less busy, and straight to the point and yet represent the friendly energy folks get from the Sakai Community. Our Sakai Accessibility statements will transition from their current draft state to being formally included in the Sakai Accessibility documentation (for Sakai 2.8 after the review we are on now, Sakai '3' after the Sakai 3 Q1/Q2 accessibility review we are about to launch). These are the first accessibility reviews we've undertaken since the draft accessibility statements were approved.
>
> The "Current Accessibility" page will be changed to refer to the various flavors and versions of Sakai. This is because Sakai versions linger (some schools are still using Sakai 2.3) and so people can see the trail of improvements made. The "Current Accessibility" pages will include two landing pages -- one each for Sakai 2.x and Sakai 3 (or Sakai OAE). These pages will include the Accessibility Statements, information on the Sakai Accessibility Working Group and how to report accessibility issues to the group, links to pages detailing 508 and WCAG 2.0 conformance, a link to the current accessibility help pages, and links to the appropriate accessibility review splash page. Once the new documentation has been posted, the Sakai Accessibility Working Group home page will be updated to prominently feature at the top of the page teasers and links to those pages. We will make sure all of the accessibility review reports have been uploaded to the wiki for the 2.9 review at that point.
>
> Much has been written about the usefulness of accessibility statements and the purpose they should serve. These articles/papers were read and discussed; comparable/competitive accessibility statements/sites were reviewed, analyzed, and discussed; plans for how to proceed have been made via the Sakai Accessibility Working Group list, the biweekly teleconferences, and at the Denver conference. All of this will be taken into account in revising the Current Accessibility pages.
>
> Please let us know if you have any questions on this or if we haven't answered one of your concerns.
>
> Sincerely,
>  IU Web Accessibility Team: Margaret Londergan, Joe Humbert, Brian Richwine, Mary Stores
>
>
> -----Original Message-----
> From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Clay Fenlason
> Sent: Wednesday, March 02, 2011 9:57 AM
> To: accessibility at collab.sakaiproject.org
> Subject: [WG: Accessibility] Questions I'm not sure how to answer
>
> Hello all:
>
> A local task force has posed some pointed questions about Sakai's accessibility compliance, not all of which I know how to answer from the materials in Confluence. I'm hoping you can help me refine my answers, which I need to return to them fairly soon.
>
> 1) "Is this platform compliant with Section 508c of the Rehabilitation Act?  What are the accessibility features?"
>
> The Confluence page that seems to answer this in detail was last edited in 2009, and so by my reckoning it's only current for 2.6. [1] It's not clear to me if any of that information changed in 2.7, though I can get some clues from a summary page of changes per version [2].
> The 2.7 accessibility review results page itself is empty [3]
>
> 2) "How can users with disabilities access this platform using text to speech software (JAWS, VoiceOver), speech to text software (Dragon Naturally Speaking), and other accessibility software (refreshable Braillers, electronic notetakers, etc.)?"
>
> I'm frankly not sure I understand what this question is getting at, but it sounds like they want to know about any special setup or configuration for these tools. I'm just not familiar with them.
>
> Thanks in advance for any help or advice you'd offer.
>
> Best,
> Clay
>
> [1] https://confluence.sakaiproject.org/x/S4DtAg
> [2] https://confluence.sakaiproject.org/x/NoDtAg
> [3] https://confluence.sakaiproject.org/x/eQoQB
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>