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

Hi Vivienne
In practice it is unlikely that shortcut keys will interfere with AT
software's shortcut keys, since the latter's shortcut keys will normally
take precedence over HTML shortcut keys (accesskey attribute).

The spin-off, of course, is that this would render the accesskeys provided
by the site redundant to AT users.

This despite I think there is a strong argument in favour of using
accesskeys:

There is a large group of people that will directly benefit from the
provision of shortcut keys.
Shortcut keys to key page zones and frequently used functions, will benefit
all people who prefer to use the keyboard (as opp. to mouse), or are unable
to use the mouse. Including those with short-term needs.

I would suggest the following convention:

1) Provide two hidden links, at the beginning of the page structure, both
of which are revealed to the user, when the user tabs and the the first one
receives focus:
i) Skip to content link (ALT+S) - jumps to main content area; ii) Link to
shortcut keys (ALT+0) - displays all site-based shortcut keys.

2) Additionally, if a user tabs and an element that has an accesskey
associated with it, receives focus, this should be revealed to the user
(e.g.: [ALT+(key)] is hidden until the link or element receives focus.

Note: Unlike HTML 4.01, where the accesskey attribute could only be used
with certain elements, HTML 5 allows the accesskey to be associated with
any element, making it far easier to use the accesskey to provide shortcuts
to key page zones.

Kind regards, Harry



On 15 October 2012 12:48, Vivienne CONWAY <v.conway@ecu.edu.au> wrote:

>  Hi Richard
> Thanks for that - I had understood the same thing.  It makes me wonder why
> it is being considered as an Advisory Technique for the future.
>
>
> Regards
>
>  Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
> PhD Candidate & Sessional Lecturer, Edith Cowan University, Perth, W.A.
> Director, Web Key IT Pty Ltd.
>  v.conway@ecu.edu.au
> v.conway@webkeyit.com
>  Mob: 0415 383 673
>
> This email is confidential and intended only for the use of the individual
> or entity named above. If you are not the intended recipient, you are
> notified that any dissemination, distribution or copying of this email is
> strictly prohibited. If you have received this email in error, please
> notify me immediately by return email or telephone and destroy the original
> message.
>
>  ------------------------------
> *From:* Userite [richard@userite.com]
> *Sent:* Monday, 15 October 2012 6:30 PM
> *To:* Vivienne CONWAY; w3c-wai-ig@w3.org
> *Subject:* Re: Access Keys as a means to passing 2.4.1 Bypass Blocks
>
>    Hi Vivienne,
>
> My understanding is that access keys are not recommended as the can
> conflict with screen reader software.
>
> Richard
>
>  *From:* Vivienne CONWAY <v.conway@ecu.edu.au>
> *Sent:* Monday, October 15, 2012 4:26 AM
> *To:* mailto:w3c-wai-ig@w3.org <w3c-wai-ig@w3.org>
> *Subject:* Access Keys as a means to passing 2.4.1 Bypass Blocks
>
>   HI all
>
> I'd like to get your opinion as to whether the provision of access keys is
> a satisfactory method to pass 2.4.1 Bypass Blocks.
>
> They aren't covered by the Sufficient Techniques but there is a mention in
> the Advisory Techniques as a possible future link.  My concern is that
> unless they are visible upon keyboard activation, the user would not know
> they are available unless there was a mention in the 'accessibility page' ,
> if there was even that page provided.
>
> A page I'm looking at has an inadequate heading structure (only 1 h3 and 2
> h4 elements), no skip links, but has access keys that you can find out
> about in the accessibility link at the bottom of the page.
>
> IMHO, it is certainly not 'best practice', but does it actually fail 2.4.1?
>
>
>
> Regards
>
>  Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
> PhD Candidate & Sessional Lecturer, Edith Cowan University, Perth, W.A.
> Director, Web Key IT Pty Ltd.
>  v.conway@ecu.edu.au
> v.conway@webkeyit.com
>  Mob: 0415 383 673
>
> This email is confidential and intended only for the use of the individual
> or entity named above. If you are not the intended recipient, you are
> notified that any dissemination, distribution or copying of this email is
> strictly prohibited. If you have received this email in error, please
> notify me immediately by return email or telephone and destroy the original
> message.
>
> ------------------------------
> This e-mail is confidential. If you are not the intended recipient you
> must not disclose or use the information contained within. If you have
> received it in error please return it to the sender via reply e-mail and
> delete any record of it from your system. The information contained within
> is not the opinion of Edith Cowan University in general and the University
> accepts no liability for the accuracy of the information provided.
>
> CRICOS IPC 00279B
>
> ------------------------------
> This e-mail is confidential. If you are not the intended recipient you
> must not disclose or use the information contained within. If you have
> received it in error please return it to the sender via reply e-mail and
> delete any record of it from your system. The information contained within
> is not the opinion of Edith Cowan University in general and the University
> accepts no liability for the accuracy of the information provided.
>
> CRICOS IPC 00279B
>