Accessibility WG Teleconference Minutes 11-19-2009

Owned by Former user (Deleted)
Last updated: Jan 07, 2011Version comment
3 min read

(Notes taken by Mary Stores)

Attendees:

  • Mary Stores - IU
  • Joe Humbert - IUPUI
  • Margaret Londergan - IU
  • Brian Richwine - IU
  • Eli Corcoran - UC Berkley
  • Sean Keegan - Stanford
  • Mike Elledge - MSU

Protocol Development

  • Brian added a child page for protocol development on the accessibility working group page.
  • Mike Elledge will be sending a link to MSU web accessibility protocol, which is available for public viewing on MSU's web site.

Developing Accessibility Guidelines

  • The Product Council has developed technical criterion. Will be a good template for us to use. However, accessibility criteria should probably be richer and use more definition

Policy Statement Overview and Feedback

  • Brian wrote up an excellent policy statement (It's the first step toward a goal statement).
  • Brian also has a plan for all the steps, including goal assessing at the end.
  • The policy statement is, according to Eli, a forward looking market statement presented in the language of where we are today. It could be that the statement will eventually be replaced by the goals we come up with in the future, but this is an excellent starting point for generating ideas.
  • Policy feedback: Eli is concerned about that not tool will be evaluated for accessibility/usability; this is an idealistic expectation. As the document currently stands, it is idealistic. However, it can be made more general with statements like "while striving to..." and "it is our intention."
  • Policy statement will be shared by Eli with Clay Fennelson, Michael Corcusca.

Concerns

  • If apps are not accessible, there needs to be an accessible alternative.
  • Should our goals be geared toward a group of people with a specific amount of knowledge of AT use?
  • Concern about writing specific goals for Sakai 2.7 versus 3.0. Sakai 3 goals may be different goals. Set of goals can be for Sakai 3 and new development in Sakai 2.
  • Most of Sakai 2 is not going to be retrofitted, but it will still be around for a long time.
  • There are tools being released independent of a specific schedule being evaluated by product council; not in main core of Sakai but are still significant tools. They would like to have accessibility testing performed.

Sakai 3 testing

  • There are widgets can be viewed at 3akai from the main Sakai project page. Sakai 3 is embarking on a design cycle
  • Part of the design effort for simple learning development will be to pull out a library of reused components.
  • Eli is not sure on timeline for accessibility testing.
  • Sakai 3 is client side; heavily Javascript, have the tools to do great accessibility if done right.
  • To prevent danger of performing accessibility evaluations too late in the development process, it's best that accessibility criteria are developed and feedback received from the web developers. That way, accessibility can be "baked in" to the code; developers can copy and paste the code for a list that has already been coded for accessibility.
  • Within the next couple of months, certain techniques can be decided: example: use specific heading structure; create good copy and paste examples of how to build an accessible widget.
  • The Sakai community is not very prescriptive of coding habits, but it would be good if that habit can be gotten rid of for accessibility sake. But because the amount of coders is smaller, there is an opportunity for accessibility.
  • Eli says the best use of time for the members of this group would be to come up with goals and criteria and propose to the Sakai group. Eli has ideas on how this would be implemented. Concrete suggestions would be the best way to get attention of the group. C
  • Create generalized best practices, not specific to particular widget. Example: no accesskeys; use tabs, arrow, and activation keys instead. Example 2: use jump-to links in Sakai 3.

Before next teleconference

  • After working on policy statement improvement, Eli will send it out and receive feedback. After that, goals will be worked on.
  • Submit comments from policy statement to the group.
  • Also everyone should look at the e-mail sent regarding the bulleted list of documents needed for testing.