[WG: Accessibility] Draft Sakai Accessibility Goals

[Richwine, Brian L]

Based on comments by Joe, Mary, and Margaret, I have updated the Draft Sakai Accessibility Goals. We have them now as follows. They have also been posted to the working group's wiki at:
http://confluence.sakaiproject.org/display/2ACC/Sakai+Accessibility+Working+Group+Accessibility+Goals+Development

Draft Sakai Accessibility Goals

Since Sakai 2.x is obviously in production, is designed with different technical and user experience goals than Sakai 3, and mostly developed under earlier accessibility standards, we see the accessibility goals between Sakai 2.x and Sakai 3 as needing to be separate. These goals focus on technical accessibility standards and laws, and Sakai's functional accessibility, and not the process of achieving the goals, where the goals fit into Sakai's Development Process, or where they fit into any time-line or roadmap documents. The plan for meeting these goals, and the resulting process related issues need to be addressed in separate documents that discuss where accessibility fits into the Sakai Development Process. It is our intent that those documents will be written or discovered, and then linked to from the accessibility goals if/when they are adopted and posted.

Draft Sakai 2.x Accessibility Goals

 *   Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional
 *   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

Draft Sakai 3.x Accessibility Goals

 *   Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional
 *   Section 508 §1194.21 (a-l), §1194.22 (a-p)
 *   WCAG 2.0 Level A and AA
 *   WAI-ARIA feature usage according to best practice guidelines
 *   Consistent and standard keyboard functionality following the DHTML Style Guide Working Group's DHTML Style Guide
 *   Authoring Tool Accessibility Guidelines (ATAG) 1.0
 *   Tested for functional accessibility to ensure the best user experience possible for persons using adaptive technology

Reasoning Used in Determining the Above Draft Accessibility Goals
Reasoning for the Draft Sakai 2.x Accessibility Goals

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.

Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional

The need for strictly valid markup was excluded to allow for technologies like ARIA which work, but are not included in current (X)HTML standards, and to allow for other non standard tags to be used where needed to improve accessibility or functionality (like the embed tag as needed for displaying video in some browsers, etc.).

Besides keeping coding/markup as valid as possible, well formed code is needed in any case where xml is concerned to help provide consistent results in the various parsers since recovery and error handling techniques vary.

Semantically correct markup is very important for adaptive technology and the disabled user. Adaptive technology usually ignores the CSS and other presentational information and uses the semantic/structural markup to make contextual sense of the information being marked up. If CSS is used to, say, simply tell the rendering engine to make a paragraph look like a heading (such as <p class="heading">), then the page structure will be lost for users of adaptive technology. Understanding of the page, navigational features, and the ability to target headings in custom user style sheets would all be lost.

Section 508 §1194.22 (a-p)

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). It is assuming here that they simply meant the Web Accessibility parts of Section 508, hence the "§1194.22 (a-p)" specification.

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

WCAG 1.0 checkpoint 3.2 (valid markup) was excluded 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 see WCAG 2.0 Checkpoint 4.1.1). Semantically correct markup is important to provide adaptive 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 - the output and behavior of scripting is required to be accessible).

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

JavaScript on the client/browser end and coding on the server side, is used heavily in today's web applications to control the behavior of a web "page" and the controls found on it. Where the behavior of HTML controls used to be determined by the browser, the behavior of many HTML controls, including HTML elements not originally thought of as controls, is now in the hands of the programmer. Since JavaScript and CSS are used heavily in modern sites to make traditional HTML elements behave in non-traditional manners (such as slider controls, spinner controls, pop-up calendar date pickers, etc.), the standards don't (and can't) cover all the roles and behaviors a programmer can devise for HTML elements. The standards can't describe how every new and future creation should behave.

The only way to know it is truly usable by users of adaptive technology is to test it.

Reasoning for the Draft Sakai 3.x Accessibility Goals

Sakai 3 developers should be reaching for these goals.

Well formed, semantically correct markup - valid where possible except where exceptions are necessary to make Sakai more accessible or functional

WCAG 2.0 favors accessibility over strict adherence to valid markup see WCAG 2.0 Checkpoint 4.1.1. The need for strictly valid markup was excluded here, to allow for technologies like ARIA which work, but are not included in current (X)HTML standards, and to allow for other non standard tags to be used where needed to improve accessibility or functionality (like the embed tag as needed for displaying video in some browsers, etc.).

Besides keeping coding/markup as valid as possible, well formed code is needed in any case where xml is concerned to help provide consistent results in the various parsers since recovery and error handling techniques vary between browsers.

Semantically correct markup is very important for adaptive technology and the disabled user. Adaptive technology usually ignores the CSS and other presentational information and uses the semantic/structural markup to make contextual sense of the information being marked up. If CSS is used to, say, simply tell the rendering engine to make a paragraph look like a heading (such as <p class="heading">), then the page structure will be lost for users of adaptive technology. Understanding of the page, navigational features, and the ability to target headings in custom user style sheets would all be lost.

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

Since Sakai 3 looks and behaves like a software application, Section 508 §1194.21 (a-l) was included which covers software applications along with the traditional 16 web accessibility rules in §1194.22 (a-p). This is likely to be updated when the new 508 rules are released.

WCAG 2.0 Level A and AA

Many international laws either directly state requiring WCAG compliance or at least appear based on WCAG standards - this is especially true of 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

WAI-ARIA is included as a goal for its features which help make 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).

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

JavaScript coding, and even server side programming, can affect much of the keyboard functionality and other behaviors of a web application such as Sakai 3. Accessible navigation and functional accessibility in general, benefit greatly by consistent and standard behavior from web applications. Conformance to the DHTML Style Guide Working Group's DHTML Style Guide (http://dev.aol.com/dhtml_style_guide) would work to achieve this. The DHTML Style Guide Working Group had a wide range of participants who contributed to the style guide (it wasn't just AOL). We haven't found a similar, or better, standard / guidelines document elsewhere.

Authoring Tool Accessibility Guidelines (ATAG) 1.0

Authoring Tool Accessibility Guidelines (ATAG) 1.0 are included to insure Sakai 3's content authoring features are accessible and that they allow users to create accessible content.

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

Especially in sites like Sakai 3, JavaScript on the client/browser end and coding on the server side, is used heavily to control the behavior of a web "page" and the controls found on it. Where the behavior of HTML controls used to be determined by the browser, the behavior of many HTML controls, including HTML elements not originally thought of as controls, is now in the hands of the programmer. Since JavaScript and CSS are used heavily in modern sites to make traditional HTML elements behave in non-traditional manners (such as slider controls, spinner controls, pop-up calendar date pickers, etc.), the standards don't (and can't) cover all the roles and behaviors a programmer can devise for HTML elements. The standards can't describe how every new and future creation should behave.


From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Richwine, Brian L
Sent: Tuesday, January 05, 2010 11:48 AM
To: Humbert, Joseph A; accessibility at collab.sakaiproject.org
Subject: Re: [WG: Accessibility] Draft Sakai Accessibility Goals

Thanks Joe!

Good catch -- I'll add a 1.0 to the ATAG guidelines.

The reasoning sections in the goals I posted were written to explain to the group my thinking and how I came up with the original draft as a possible aid for discussion. As written, they aren't meant for public consumption and would need to be rewritten with an appropriate focus and language once the final set of goals is determined.

The goals as listed and the accessibility statement we have been working on are meant to be plugged into a larger set of documents, that would include the other information you mention. The original email to the group that starting this work listed (and somewhat discussed) these as follows:
I envision that the following all work together:
*         An Accessibility Statement
*         The Accessibility Goals
*         An Accessibility Plan
*         Documents needed for and supporting the plan (Guidelines, checklists, protocols, documentation, etc.)
*         A Process for Implementation of the Plan
*         Progress evaluation
*         Results Assessment and Reporting

Please let me know if you have any suggestions or comments on the above list.

Thanks!
  -Brian


From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Humbert, Joseph A
Sent: Tuesday, January 05, 2010 11:35 AM
To: accessibility at collab.sakaiproject.org
Subject: Re: [WG: Accessibility] Draft Sakai Accessibility Goals

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/01d5cd42/attachment-0001.html