Present:
Avni, Victor, Emmanuelle, Dave, Don, Carl, Raul, Mr_Calvin, Miguel
Assessment
- morals will have the sumary of the assessment fixes ready for august 12 meeting, daveb will have contributed his fixes and the bug tracker fixes by then, emma_r is fixing more
Accessibility
- link to accessibility stuff, http://www.openacs.org/xowiki/wcag_checkpoints
- the policy doc has the "Contributing Code to .LRN and OpenACS Core" paragraph that should be a "History" document somewhere else, linked from the policy doc
- the history is at the wiki, but the policy is too short to break it up
- the policy and statement should link to the wiki, for more details but the problem is that the wiki is NOT accessible
- I suppose the background could follow the policy, for those who just want to follow the policy, the paragraph before the last one is important too, it defines "current compliance level"
- here's an official policy statement that has a very long set of sections on justification http://aappolicy.aappublications.org/cgi/content/full/pediatrics%3b103/3/686
- the group of primary addressees of the policy statement is openacs/.lrn developpers, anyone who wants to commit to dotlrn-all, dotlrn-extras, acs-core
- the policy part does talk about commits to those three sets of packages, can be called "commit policy"?
- the policy is a statement, that we want people to feel like they can depend on, that they won't get non-accessible code by surprise
There are 3 documents about accesibility
1. accessibility statement: the one that include the list of access keys etc... which is an adp in the themne-zen package, it's linked from every page of .lrn (at the top), the link is "accessibility"
2. accessibility policy , for developers, that says that the "current compliance level" is the one stated by the statement
3. the checkpoint summary in the wiki to be used as a tool by developpers, to check their code etc...
next task is to write the techniques, openacs-specific, i.e. translate the W3c/WAI ones into openacs language
- write the policy and publish it to say "we shouldn't go backwards from here", the checkpoints + techniques to provide tools for developpers and have the board approve the policy
- we need agreement on the "not going backward" part, which I hope is not really an issue
- we could give people one week to comment offline via e-mail and give formal approval next week
- once we agree on them we should post to the forums?
- one of the questions will be "where to publish the policy", forums is one but we might want to publish elsewhere, like a static page
- why not also branch an dedicated ".LRN accessibility" forum ..., to pool questions of developers
Miguel's ideas:
- Miguel's idea is that the whole admin page of a community is the actual dotlrn-admin-portlet https://openacs.org/forums/message-view?message_id=1503658
- Here's an example: https://openacs.org/forums/message-view?message_id=1577071
- The idea is that every portlet behave like a page, using a .vuh file
- He is going to commit the changes about the reorganization of dotlrn-admin-portlet on HEAD and the fix of a dotlrn-toolbar non valid html code on 5.4
OVERTIME :)
- another idea: better sort for dotlrn-main-portlet https://openacs.org/forums/message-view?message%5fid=175555, in fact, alphabetical order
- a functional index or add column somewhere and maintain it via trigger could work
- mcordova is gonna try it, and post the results
- And one more thing - https://openacs.org/forums/message-view?message%5fid=1651386, next time...
minute 90...
