Re: Access Keys as a means to passing 2.4.1 Bypass Blocks

On 15 October 2012 17:30, <deborah.kaplan@suberic.net> wrote:

> On Mon, 15 Oct 2012, Harry Loots wrote:
>
>> Alt+ 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, S and a few others are not bound to any
>> browser as far as I am aware?
>>
>
> You will want to do your testing beyond just what is bound  to the
> browser, however. Many people have other adaptive technologies in
> place and the default settings of other adaptive tech may use
> those key bindings -- I'm not sure of those in particular.


AT shortcut keys override HTML access keys. If an AT user encounters ALT+S,
and they already have an ALT+S defined as part of the AT shortcut keys, the
AT shortcut key will take precedence. Given that AT shortcuts override HTML
accesskeys, adding shortcut keys, in my opinion, brings no benefit to AT
users.



> I
> know, for example, that people frequently put into place
> keystroke bindings on websites (Ajax, not access key)


I was specifically referring to accesskeys (as HTML attribute)

(Another thing to take into account with access keys is how you
> expose them to non-screen reader users. Frequently lists of
> access keys are published via text hidden from visual display but
> not from screen reader via CSS, and neither zoom nor
> keyboard-only users ever know the list exists.)


By using the 'focus' event it is possible to expose shortcuts, etc to
keyboard users, while keeping them hidden from the conventional visual
display.

Smart design can will ensure accesskeys are exposed to users when
applicable. Ignoring the benefits accesskeys can bring to a large segment
of the user population (such as older people who may have problems clicking
a mouse, or people with RSI) who do not have AT installed, is like throwing
out the baby with the bathwater. Careful consideration of how the accesskey
attribute is used, can enhance the experience for a huge group of people
without causing interference to others.

Harry