[WG: Accessibility] Sakai Accessibility Teleconference this week

[Eli Cochran]

Let me point folks at the 2.7 Road Map:

http://confluence.sakaiproject.org/display/MGT/Proposed+Sakai+2.7+Changes

I don't think that all these things will get into the Sakai 2.7 but  
these are the current proposals.

- Eli

On Aug 13, 2009, at 8:44 AM, Londergan, M D wrote:

> Mike,
>
> Thanks as always for your helpful input. We will cover the issues  
> raised in Gonzolo's and Sean's email on the call today. Your input  
> is always of great help. I look forward to the Sakai Accessibility  
> WG evolving a revised accessibility objective that takes into  
> account WCAG2.0 and in particular issues related to AJAX and Aria.
>
> Sorry you will be unable to join us today.
>
> Margaret
>
> -----Original Message-----
> From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org 
> ] On Behalf Of Michael S Elledge
> Sent: Thursday, August 13, 2009 10:16 AM
> To: Silverio, Gonzalo
> Cc: accessibility at collab.sakaiproject.org
> Subject: Re: [WG: Accessibility] Sakai Accessibility Teleconference  
> this week
>
> Hi Gonzalo (and everyone)--
>
> In the past, Sakai's accessibility objective was compliance with WCAG
> 1.0 Priority One and Priority Two criteria. Since WCAG 2.0 has now  
> been
> released, Sakai's standards would have to be revised somewhat to  
> remain
> consistent. WCAG 2.0 Level A actually adopts a number of Priority Two
> criteria so it is a more robust standard (I've attached a presentation
> that I gave recently at U Mich that illustrates this). But Sakai may
> still want to pull in some Level AA criteria.
>
> Exactly what a "new" or "revised" Sakai standard should be, however,
> still needs to be determined and is really the purview of Margaret and
> the rest of the accessibility group. I'll be happy to work on it with
> Margaret and the group, since we're starting to address it at MSU
> anyway, but that's her call.  :^)
>
> BTW, I will be unable to meet today because of a time conflict, just  
> to
> let you know.
>
> Mike
>
> Silverio, Gonzalo wrote:
>> On 8/13/09 1:16 AM, "Sean Keegan" <skeegan at gmail.com> wrote:
>>
>>
>>>> Perhaps the way to proceed is to target
>>>> Sakai 3 as a locus for aria enabled semantics, where they will be  
>>>> crucial
>>>> given it¹s ajaxy ways,  and leave the 2.x  as is, which is  
>>>> generally fairly
>>>> accessible in old school ways. Does that sound right?
>>>>
>>> That sounds fine.  From my experience, 2.x works in terms of
>>> accessibility and if integrating ARIA attributes into the 3.x code  
>>> is
>>> a more effective workplan, than I can support that option.  I  
>>> suppose
>>> the big question that comes to mind is then what are the timelines
>>> surrounding 2.7 implementation as well as 3.x target dates?
>>>
>>
>> 2.7 at the end of the year, 2.8 ~ May 2010, 3.0 sometime later,  
>> either late
>> 2010 or the next year, not sure.
>>
>>
>>> Based on the meeting notes, it seems that the inclusion of these
>>> roles/attributes in the accessibility checklist is one option to
>>> pursue (as was outlined in the meeting notes from 7/30).  How much
>>> information do you think is necessary to include in the  
>>> accessibility
>>> checklist - in other words, should there be information specific to
>>> ARIA with examples?
>>>
>>
>> The checklist for 3.0, I am assuming. It is hard to tell. If all  
>> goes well
>> there will be no need to - Sakai 3.0 will use FLUID components for  
>> the most
>> challenging widgets and a library of UI elements that will be  
>> decorated by
>> an ARIA engine with the ARIA attributes. The FLUID components  
>> already do
>> this (decorate a given DOM with the correct attributes, and update  
>> them
>> based on user/application interactions).  All the developer will  
>> need to do
>> is declare a markup fragment to be a type of thing that FLUID or  
>> the ARIA
>> engine recognizes (a menu, a treegrid, etc.).
>>
>> If this scenario does not materialize then yes, the developer would  
>> need
>> this information. I tend to think the best way would be to provide  
>> a clear
>> match up between a widget and a markup fragment properly ARIAized,  
>> so if the
>> developer is looking at a design with a spinner, she can just grab  
>> the
>> corresponding fragment and use it. Instrumenting the fragment to  
>> make it
>> responsive to interactions, that would be required as well - but at  
>> that
>> point things become very complicated, so not sure, really.
>>
>>
>>> Also - is there a specific accessibility criteria (e.g., WCAG 2,  
>>> etc.)
>>> that we are attempting to meet with either the 2.x or 3.x releases -
>>> or at least specify to provide direction to developers as to the
>>> conformance level?  I was poking around but did not see anything
>>> specific on the Sakai site.
>>>
>>
>> Hopefully Mike can address this.
>>
>> Thanks, talk to you all later today.
>>
>>    -Gonzalo
>>
>> _______________________________________________
>> accessibility mailing list
>> accessibility at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>
>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>>
>>
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley