[WG: Accessibility] Accessibility improvements that could be seen in Sakai 3 over Sakai 2

[Richwine, Brian L]

Hi,

Using comments Jon Gunderson provided, I've updated the Accessibility Improvements list (making changes re table accessibility). Note that I also made a few other minor grammar changes. The list as I now have it follows.

Sincerely,
    -Brian
Accessibility improvements that could be seen in Sakai 3 over Sakai 2

*         Explicitly label every form element (ARIA can be helpful here)

*         Make all controls keyboard accessible (ARIA and accessible JavaScript techniques can be helpful here)

*         Use accessible content authoring tools. Make sure the content authoring tools allow the user to create accessible content (alt text for images, accessible table markup (headers, summary, etc.), appropriate structural elements (headings, paragraphs, etc.), etc.)

*         Allow users to specify their default WYSIWYG editor preference

*         Make all link text/titles to unique destinations distinct. Make sure the purpose/destination of each link is clear.

*         Use appropriate semantic markup (good heading structure, lists for lists, paragraphs for paragraphs, well marked up data tables with summaries and appropriate headers, etc.)

*         Use CSS for layout instead of tables and markup data tables appropriately. If tables are being used for layout, have each layout table's role marked appropriately.

o   ARIA can be used to mark a table as for layout by adding the ARIA role="presentation" to the table tag.

o   For data tables, follow best practices for accessible table markup (use table summaries, header cells, etc. as appropriate).

*         Eliminate cases where the use of color is the sole means of communicating pieces of information

*         Give better announcement of pop-ups and completed actions (ARIA can be helpful here)

*         Make uniform and logical use of ARIA Landmarks to improve page navigation and purpose discovery by the user

*         Use ARIA features as needed to provide necessary contextual information for adaptive technologies (roles, states, change notification, etc.)

*         Don't use frames/iFrames. If frames are necessary, make sure they are named appropriately to provide necessary contextual  information.


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:48 AM
To: accessibility at collab.sakaiproject.org
Subject: Re: [WG: Accessibility] Accessibility improvements that could be seen in Sakai 3 over Sakai 2

Hi!

I think this is a great list and after reviewing the Jira tickets I believe you have covered all of the issues we had found with 2.x and added more.  I hope that we can look forward to HTML5 and possibly draw from it too. Thankx.

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/<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:48 PM
To: accessibility at collab.sakaiproject.org
Subject: [WG: Accessibility] Accessibility improvements that could be seen in Sakai 3 over Sakai 2

I am making a list of accessibility improvement that could be achieved in Sakai 3 over the Sakai 2.x code base. I'm especially interested in including issues that go beyond the "low hanging fruit" and in having a list that addresses issues that are critical to get into the ground floor of Sakai 3's development.

Please email the list with comments and suggestions. Here is what I have so far:

Accessibility improvements that could be seen in Sakai 3 over Sakai 2

*         Explicitly labeling every form element (ARIA can be helpful here)

*         Make all controls keyboard accessible (ARIA and accessible JavaScript techniques can be helpful here)

*         Use accessible content authoring tools. Make sure the content authoring tools allow the user to create accessible content (alt text for images, accessible table markup (headers, summary, etc.), appropriate structural elements (headings, paragraphs, etc.), etc.)

*         Allow users to specify their default WYSIWYG editor preference

*         Make all link text/titles to unique destinations distinct. Make sure the purpose/destination of each link is clear.

*         Use of appropriate semantic markup (good heading structure, lists for lists, paragraphs for paragraphs, well marked up data tables with summaries and appropriate headers, etc.)

*         The use of CSS for layout instead of tables, or have each table's role marked appropriately

o   Using ARIA: Adding role="presentation" to the table tag causes it to always be treated as a layout table

o   Using ARIA: Adding role="grid" to the table tag causes any table to be treated as a data table

*         Eliminating cases where the use of color is the sole means of communicating pieces of information

*         Better announcement of pop-ups and completed actions (ARIA can be helpful here)

*         Uniform and logical use of ARIA Landmarks to improve page navigation and purpose discovery by the user

*         Use of ARIA features as needed to provide necessary contextual information for adaptive technologies (roles, states, change notification, etc.)

*         Don't use frames/iFrames. If frames are necessary, make sure they are named appropriately to provide necessary contextual  information.


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

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