[WG: Accessibility] Draft Sakai Accessibility Goals

[Richwine, Brian L]

It has been suggested by Mary Stores that the "As usable as possible for persons using adaptive technology" goals be reworded. I had intended them to mean that user testing with adaptive technology would take place to ensure functional accessibility issues are caught and fixed since adhering to the standards / laws only means that a site is technically accessible.

Along those lines, I'm wondering if a specific goal for Sakai 3 should address a need for consistent/standard keyboard behavior since JavaScript coding and even backend programming can affect so much of the user experience and the keyboard functionality of a web application such as Sakai 3. Perhaps conformance to the DHTML Style Guide Working Group's DHTML Style Guide (http://dev.aol.com/dhtml_style_guide) would work for this. The working group had a wide range of participants who contributed to the style guide (it wasn't just AOL). I haven't found a similar standard / guidelines document anywhere else.

With those two changes in place, I have the accessibility goals as follows:

Draft Sakai Accessibility Goals
Sakai 2.x
Goals

·         Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional (ie: ARIA attributes, use of non-standard tags like embed, etc.)

·         Section 508 §1194.22 (a-p)

·         WCAG 1.0 Priorities One and Two (except Checkpoints 3.2 and 6.3)

·         Tested for functional accessibility to ensure the best user experience possible for persons using adaptive technology

Reasoning
These goals, while obviously not met 100% by Sakai 2.x, appear realistic to what could be achieved with Sakai 2.x and should be strived for with any new development. Goals "Section 508" and "WCAG 1.0 Priorities One and Two" are stated as goals in existing Sakai 2.x documentation (like the Accessibility Help Document). I am assuming here that they simply meant the Web Accessibility parts of Section 508, hence the "§1194.22 (a-p)" specification. I left WCAG 1.0 checkpoint 3.2 (valid markup) out to allow for ARIA and non standard tags to be used where needed to improve accessibility or functionality (WCAG 2.0 favors accessibility over strict adherence to valid markup). Semantically correct markup is important to provide assistive technology (and its users) proper contextual information and navigation features. WCAG 1.0 Checkpoint 6.3 was left out because it requires pages to be usable with JavaScript turned off (this is not a requirement of Section 508 or WCAG 2.0).
Sakai 3.x
Goals

·         Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional (ie: ARIA attributes, use of non-standard tags like embed, etc.) (Valid markup is not required in WCAG 2 -- see 4.1.1)

·         Section 508 §1194.21 (a-l), §1194.22 (a-p)

·         WCAG 2.0 Level A and AA

·         WAI-ARIA

·         Consistent and standard keyboard functionality following the DHTML Style Guide Working Group's DHTML Style Guide

·         Authoring Tool Accessibility Guidelines (ATAG)

·         Tested for functional accessibility to ensure the best user experience possible for persons using adaptive technology

Reasoning
I believe these goals to be ones Sakai 3 developers should be reaching for. Well formed markup is needed for obvious reasons (Sakai's doctype is XHTML). Semantically correct markup is important to provide assistive technology (and its users) proper contextual information and navigation features. Since Sakai 3 looks and behaves like a software application, I included Section 508 §1194.21 (a-l) which covers software applications along with the traditional 16 web accessibility rules in §1194.22 (a-p). Many international laws either directly state requiring WCAG compliance or at least appear based on WCAG standards - especially WCAG 1.0. WCAG 2.0 is in many ways backwards compatible with WCAG 1.0 and offers features that make sense for Sakai 3 (Allows JavaScript and WAI-ARIA, covers many accessibility issues caused by using JavaScript to modify the behavior of standard HTML controls as found in today's web applications (and covers much of Section 508 §1194.21)). WAI-ARIA is included as a goal for its benefits for making web applications accessible and usable, and as a technology to use in meeting WCAG 2.0 4.1.2, Section 508 §1194.21, and proposed new rules in Section 508 §1194.22 (not an exhaustive list). The Authoring Tool Accessibility Guidelines are included to insure Sakai 3's content authoring features are accessible and that they allow users to create accessible content.


From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Richwine, Brian L
Sent: Sunday, January 03, 2010 10:43 PM
To: accessibility at collab.sakaiproject.org
Subject: [WG: Accessibility] Draft Sakai Accessibility Goals

Hi,

Over the holiday break, I worked on writing up Accessibility Goals for Sakai 2.x and Sakai 3. Since Sakai 2.x is obviously in production and was developed with different technical and user experience goals, and mostly developed under earlier accessibility standards, I see the accessibility goals between Sakai 2.x and Sakai 3 as needing to be separate.

I'm not exactly sure what Eli was looking for when he talked about needing to develop accessibility goals for Sakai. These goals focus on the technical standards and functionality as goals and not the process of achieving them, where they fit into Sakai's Development Process, or any timeline. I believe the process related issues need to be in a separate document that discusses where accessibility considerations and testing fits into the Sakai Development Process.

Here is what I came up with. My reasoning for the choices is listed below. Please read and comment back to this list for discussion.

I have the next Sakai Accessibility Teleconference listed as scheduled for Thursday January 14th at the normal time. By the next meeting I would like to have heard some feedback and discussion on the accessibility goals. I am working on contacting Sakai QA folks about accessibility testing for the Sakai 2.7 release and also on contacting the appropriate Sakai 3 developers on how we can get involved now with getting accessibility issues addressed in Sakai 3's development. I will report my findings on this list and at the January 14th teleconference.

Thanks,
  Brian Richwine

Brian Richwine
Adaptive Technology Support Specialist
Adaptive Technology and Accessibility Centers
Indiana University - Bloomington/Indianapolis
http://iuadapts.indiana.edu
(812) 856-4112

Draft Sakai Accessibility Goals
Sakai 2.x
Goals

·         Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional (ie: ARIA attributes, use of non-standard tags like embed, etc.)

·         Section 508 §1194.22 (a-p)

·         WCAG 1.0 Priorities One and Two (except Checkpoints 3.2 and 6.3)

·         As usable as possible for persons using adaptive technology.

Reasoning
These goals, while obviously not met 100% by Sakai 2.x, appear realistic to what could be achieved with Sakai 2.x and should be strived for with any new development. Goals "Section 508" and "WCAG 1.0 Priorities One and Two" are stated as goals in existing Sakai 2.x documentation (like the Accessibility Help Document). I am assuming here that they simply meant the Web Accessibility parts of Section 508, hence the "§1194.22 (a-p)" specification. I left WCAG 1.0 checkpoint 3.2 (valid markup) out to allow for ARIA and non standard tags to be used where needed to improve accessibility or functionality (WCAG 2.0 favors accessibility over strict adherence to valid markup). Semantically correct markup is important to provide assistive technology (and its users) proper contextual information and navigation features. WCAG 1.0 Checkpoint 6.3 was left out because it requires pages to be usable with JavaScript turned off (this is not a requirement of Section 508 or WCAG 2.0).
Sakai 3.x
Goals

·         Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional (ie: ARIA attributes, use of non-standard tags like embed, etc.) (Valid markup is not required in WCAG 2 -- see 4.1.1)

·         Section 508 §1194.21 (a-l), §1194.22 (a-p)

·         WCAG 2.0 Level A and AA

·         WAI-ARIA

·         Authoring Tool Accessibility Guidelines (ATAG).

·         As usable as possible for persons using adaptive technology

Reasoning
I believe these goals to be ones Sakai 3 developers should be reaching for. Well formed markup is needed for obvious reasons (Sakai's doctype is XHTML). Semantically correct markup is important to provide assistive technology (and its users) proper contextual information and navigation features. Since Sakai 3 looks and behaves like a software application, I included Section 508 §1194.21 (a-l) which covers software applications along with the traditional 16 web accessibility rules in §1194.22 (a-p). Many international laws either directly state requiring WCAG compliance or at least appear based on WCAG standards - especially WCAG 1.0. WCAG 2.0 is in many ways backwards compatible with WCAG 1.0 and offers features that make sense for Sakai 3 (Allows JavaScript and WAI-ARIA, covers many accessibility issues caused by using JavaScript to modify the behavior of standard HTML controls as found in today's web applications (and covers much of Section 508 §1194.21)). WAI-ARIA is included as a goal for its benefits for making web applications accessible and usable, and as a technology to use in meeting WCAG 2.0 4.1.2, Section 508 §1194.21, and proposed new rules in Section 508 §1194.22 (not an exhaustive list). The Authoring Tool Accessibility Guidelines are included to insure Sakai 3's content authoring features are accessible and that they allow users to create accessible content.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20100104/7eb03bed/attachment-0001.html