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