Hi, In rel_3_0, Joshua has added some accesskey to the left menu. For example : Issues, has access key u. Great and useful. Except that, in french, we say "prêts", that has no u. The result in koha 3.0 french is a not nice "prêtué à" , which means nothing. I investigated to fix this problem and see only 2 ways of fixing it : - remove accesskeys from the templates when generating translated files. A feature will be missing, but at least descriptions will be correct ! - use universal accesskeys. The only "universal" accesskeys I can imagine are numbers. So a solution could be to have : 1-Issue 2-Search (member) 3- search (catalogue). That sounds more easy to remember for users, but I would like to hear english speaking ppl giving their opinion. Note : the translator tool we use can't deal with accesskey (ie : we could get the string but have no method to "link" it to the description, making impossible to know which description it refers to). So the solution to translate the accesskey can't be reached. Of course, it would have be the best one ! -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
1. TRANSLATION. If the existing translation scheme will not work for access keys, should we not at least have a different translation scheme for access keys using access key specific variables stored in SQL. 2. CAUTION ABOUT CONFLICTING ACCESS KEYS AND KEYBOARD PRODUCTIVITY. Access keys mediated by JavaScript usually break web browser access keys even when the particular keys chosen are not otherwise conflicting. I suppose this problem is caused by poorly designed underlying JavaScript libraries. This issue has never happened in any of the JavaScript code I wrote myself without using anyone else's underlying libraries. However, I never have written JavaScript access key code. It would be nice if there was a way to disable the problematic parts of the code but as a user setting without turning off JavaScript completely, but I have not investigated. Losing keyboard control of the browser interferes with potential user productivity. I have never seen any JavaScript access key usage which compensated for the loss of productivity from keyboard access to browser functions. I know that most people merely use a pointing device to control applications. However, the most productive users of a particular application learn to take maximal advantage of keyboard access. Experienced keyboard control users can have some multiples of the productivity of mouse only users for interface control intensive tasks. 2.1. LEGAL PROBLEM IN THE US. Disabling web browser keyboard control is a common part of the security restrictions for browser installations at US libraries. The loss of keyboard control of the browser is most likely a violation of the Americans with Disabilities Act in the US. I suppose that no one has ever sued over the issue in libraries to enforce the law. I speculate that the only reason no one has sued over this issue in the US, the most litigious society in the world, is another aspect of the same culture. Libraries are not much valued in US culture so the disability access lobby has not noticed disability access issues for browsers further than building access to libraries. While as a practical matter US library browser restrictions demonstrate that the lack of keyboard accessibility is not a concern at many libraries, law and library procurement policies forbid such restrictions. This is an issue waiting to become a problem in the US libraries. Whenever it does become a problem for US libraries, non-compliant software will suffer in the US market. 2.2. CURRENT PRODUCTIVITY CONSEQUENCE. Meanwhile, this issue is already a serious productivity problem for some parts of Koha. The issue may send libraries that care about librarian productivity looking elsewhere for library software. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783
Access keys mediated by JavaScript usually break web browser access keys even when the particular keys chosen are not otherwise conflicting.
Just a minor correction: the discussion at hand isn't about JavaScript-mediated keyboard interaction. The discussion is of the simple HTML-based "accesskey" attribute being applied to input fields. This is not to say that similar drawbacks aren't present for HTML-based accesskeys. Googling "conflicting access keys" will give you lots of food for thought, including this: http://www.wats.ca/show.php?contentid=32 I added these access keys to the rel_2_2 NPL templates long ago because I recognized that in the context of our use, the access keys would be useful and non-harmful. I think that if a non-language-based (-biased?) accesskey scheme could be agreed upon, it would be more helpful than harmful. Perhaps it wouldn't be impractical to offer the option of user-defined access keys? http://www.tjkdesign.com/articles/user_defined_accesskeys.asp JavaScript-dependent, but possibly a worthy compromise. I haven't evaluated this solution, I'm just pointing out that it's an option. -- Owen -- Web Developer Nelsonville Public Library http://www.athenscounty.lib.oh.us
participants (3)
-
Owen Leonard -
Paul POULAIN -
Thomas Dukleth