On Wed, 2004-06-09 at 13:53 -0700, Brion Vibber wrote:
This is why the conflicting defaults must be changed; they are very damaging to usability. If you don't do it, I will.
Can you propose new default assignments? Im not objecting to avoiding keys like a (select all on moz linux), but we should try to find a more meaningful choice than '2' or similar.
Having *no labels* (but the access keys being listed prominently in the editing help and the site's accessibility statement) would also be acceptable. This would be the natural state with JavaScript disabled if the accesskeys were being set in the HTML (as they were until recently).
Which users do you have in mind here? I imagine there are very few disabled users using lynx for their daily browsing needs. Imo accessibility is not about textbooks, it's about making good decisions with the disabled, but also with the average user in mind. That's the gist of the WCAG and section 508 as far as i understand them.
I added all those access keys and tooltips in 1.3, and only in the PHPTal skin. The 'standard', 'nostalgia' and 'cologneblue' skins don't have these access keys at all, i'd say practically no access keys are a bigger problem than user-configurable ones set from js with helpful labels.
Do you then agree that the access keys should work even if JavaScript is disabled or unavailable?
The most important ones do (p, s). We could re-add some other important ones, but i don't agree that this is a high priority. The problem with having both would be maintenance- the keys would need to be updated/changed in two places- Monobook.js and acceskey-xy. The ~80 saved calls to wfMsg per page view and the reduced page source size are also important for accessibility- a slow/timing out wikipedia is not accessible at all.
Gabriel Wicke