[WG: Accessibility] Hello from the Sakai Accessibility Working Group

[Richwine, Brian L]

Thanks Eli! Your comments are really appreciated. (No worries on the name, although I don't prefer it, many people call me Rich and I've learned to listen for it!)

My thoughts are follow below. Eli's rewrite of the accessibility statement (goals?) is listed below between the <swoop> ... </swoop> tags. What do others think?

I'll update the reasoning section on semantic markup to put an emphasis on the navigational benefits. I didn't think deeply enough when writing the reasoning section to extend the discussion to actionable elements. As to the detail, it is hard to tell where to draw the line between providing information supporting the goals, and writing guidelines. I wonder if, once the checklist/guideline documentation is written, if it would be helpful to include a link to an appropriate section.

> What is really needed are new and innovative designs which provide a better user experience instead of mapping keyboard actions to broken interactions.

Is someone already working on this? Obviously, it goes beyond the scope of accessibility concerns. I searched for similar works, and didn't find didn't find much other than discussions along the idea of using the tab key for navigation outside of widgets and arrow keys for navigation within. If there is going to be a library of Sakai 3 UI Components, can the expected keyboard behavior be detailed there too?

> Where do the Accessibility Improvements list fit in?

Not sure. I am working on creating a Sakai Accessibility page in the accessibility wg's wiki space that would tie all of the documents we've been talking about together in one place, and thought of including it there. I don't know that the accessibility wg's wiki space is the appropriate place for the accessibility statement and goals to be published. The UX Development Guidelines needs to address accessibility, and I have been wondering if a single page discussing Sakai accessibility and linking to supporting documentation would be the right approach, or to work the accessibility information into the Programmer's Cafe, or ...?

Thanks for whittling on the Accessibility Statement! It is definitely on point and easier to read. We really appreciate people who have energy to swoop in and help out! 

> I changed Foundation to Community. I wanted to put the responsibility on the entire community and on those who are doing the work, not on the governing body.

I used the Sakai Foundation in the first paragraph because I wanted to make sure the Sakai Community, and the world at large, reading the statement knew the governing body took accessibility seriously, and then switched to the Sakai Community when referring to the design work. This probably isn't really necessary as the Sakai Foundation is part of the Sakai Community and hopefully everyone in the Community values accessibility. 

-Brian


-----Original Message-----
From: Eli Cochran [mailto:eli at media.berkeley.edu] 
Sent: Wednesday, January 13, 2010 5:53 PM
To: Eli Cochran
Cc: Richwine, Brian L
Subject: Re: Hello from the Sakai Accessibility Working Group

Brian, 
First apologies that I keep calling you Rich. (I think that it's because your name keeps showing up in my email as Richwine, Brian L. Now that I've added you to my address book, I see you as Brain L Richwine. Still, I'm an idiot.)

I was confused. I thought that the Accessibility meeting was today. I'll be on tomorrow. 

Now that I have time, here are some deeper comments. 

*Draft Sakai Accessibility Goals:*
This feels right to me. 

Some minor concerns:
Semantic Markup: What needs to be captured here, first and foremost, is that semantic markup provides navigable landmarks to allow users and their adaptive devices to audibly navigate the page. Tags need to be used consistently and appropriately (consistently using header tag levels is a great example).

There's also something missing here that is similar but different than your CSS example. We're clear that we're not going to support progressive enhancement or users that don't support Javascript. But I'd like to capture that actionable elements should be created using actionable markup (buttons and links) in order to support the right semantics even when the events for those elements are co-opted with richer interactions via Javascript. [Does that make sense? And perhaps it is too much detail for this document.]

As flawed as it is the DHTML Style Guide Working Group's DHTML Style Guide is a good starting point. Some of the recommendations, especially for complex interactions (like DatePicker) feel overly complex and unworkable. What is really needed are new and innovative designs which provide a better user experience instead of mapping keyboard actions to broken interactions. [I'm glad that you put this in, I'd been ignoring them for a while, and I needed to be reminded that this was going to get real at some point.]

Where do the Accessibility Improvements list fit in? 

*Draft Sakai Accessibility Statement*

The Draft Sakai Accessibility Statement hits all the right points, but I think that it could be tighter and stronger. Where previous versions of the statement made it feel that we had already achieved these goals, the current one is not definitive enough in saying that we will meet these goals. 

Forgive my swooping in, but I took a shot at rewriting the goals. Accept or dismiss as you see fit. 

<swoop>
Consistent with the goal to make Sakai the most innovative and powerful Collaboration and Learning Environment, the Sakai Community will ensure that all of the features of Sakai 3 (the next generation of Sakai) are accessible and usable by the greatest number of potential users, including users with disabilities.

To ensure this high level of accessibility for the greatest number of users, our goal is to design Sakai 3 to meet or exceed legislative requirements (such as Section 508 in the USA), following the accessibility design principals found in recognized international standards. Our goal is to meet all of the W3C Web Content Accessibility Guidelines (WCAG) 2.0 Level A and AA Success Criteria, and the relevant parts of the Authoring Tool Accessibility Guidelines (ATAG).

To ensure Sakai 3 has as few accessibility barriers as possible and to provide a rich and enjoyable user experience for all users, Sakai will be developed using emerging standards and best practice design techniques (such as the WAI-ARIA Suite), and support existing and emerging adaptive technologies. 

Leveraging accessibility experts in the Sakai Community, all future development in Sakai 3 will undergo usability and accessibility evaluations throughout the design and development process to ensure that it meets these goals. 
</swoop>

A couple of notes: 
- I changed Foundation to Community. I wanted to put the responsibility on the entire community and on those who are doing the work, not on the governing body. 

- I called out Sakai 3 by name to be specific as to what we're really talking about. 

Thanks for all your work and effort on this. I will try to stay more consistently engaged in the process. I'm eager to start sharing our (YOUR) work with the Product Council, the Sakai 3 team, and with the Board. 

Thanks,
Eli Cochran