[WG: Accessibility] Draft Sakai Accessibility Goals

[Humbert, Joseph A]

Hi!

These are a great start.  I believe we need to be more specific in some areas:


·         Sakai 3.x

o   WAI-ARIA & Authoring Tool Accessibility Guidelines (ATAG).

§  For all other bullets and guidelines you specify meeting specific guidelines, but not for this bullet.  I think we need to be specific for all  bullet points as you point out in the Sakai 2.x reasoning section.

·         Sakai 2.x and Sakai 3.x

o   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.) & As usable as possible for persons using adaptive technology.

§  I have no arguments with these, but I think it might be beneficial to add more to the reasoning section about these.  I think we should specify in that section or somewhere that guidelines will be created as well as success criteria, primers, and technical guides.  This way the community sees that there is a way to gauge the usability of Sakai by persons using adaptive technology.
Other then that I believe these are great goals.  Thankx for your hard work Brian.

Joe Humbert, Assistive Technology and Web Accessibility Specialist
UITS Adaptive Technology and Accessibility Centers
Indiana University, Indianapolis and Bloomington
535 W Michigan St. IT214 E
Indianapolis, IN 46202
Office Phone: (317) 274-4378
Cell Phone: (317) 644-6824
johumber at iupui.edu<mailto:johumber at iupui.edu>
http://iuadapts.Indiana.edu/

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/20100105/71a3f9d4/attachment-0001.html