E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Akshi Kakar
Date: Fri, Feb 14 2014 10:20AM
Subject: Keyboard shortcuts apart from Screen Reader hotkeys?
No previous message | Next message →

I have been referring to WCAG 2.0 to meet all accessibility requirements for our web application and have questions about one specific requirement:

"2.1.1 Keyboard: All functionality<http://www.w3.org/TR/WCAG20/#functiondef>; of the content is operable through a keyboard interface<http://www.w3.org/TR/WCAG20/#keybrd-interfacedef>; without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)"

I have read the 'How to Meet' and 'Understanding' portions of this criteria and understood that all user actions that require continuous mouse movement such as 'drag and drop' need to have a keyboard alternative.

My question is, do we need to provide keyboard shortcuts or alternatives for the basic navigation within the web application or do users access them through the arrow/tab keys or the screen reader? This is probably a question for users of alternative keyboards or those with motor disabilities.

Thank you for your time.

Regards,
Akshi

From: Birkir R. Gunnarsson
Date: Fri, Feb 14 2014 7:05PM
Subject: Re: Keyboard shortcuts apart from Screen Reader hotkeys?
← Previous message | No next message

The most important thing to avoid is to create widgets that depend on
mouse movements alone (such as menus that pop up when user hovers over
a link or a page element with the mouse).
Similarly when buttons or links are constructed of divs and spans
without appropriate keyboard handling being present (set tabindex="0"
on the element (better yet, use a natively focusable element such as
an input, link or button for the task), write a function that responds
to the onKeydown event using enter or spacebar keys (13, or 32), and
make sure all events happen onFocus, not just onHover).
These are the WCAG 2.1.1 main points.
Related to that, one can consider WCAG 2.4.1, providing skip links on
the page, ARIA landmarks of the main sections of the page (sadly
screen readers are still the main beneficiaries of this funcionality,
even if inherently it is open to all assistive technologies even to
the browsers themselves), or implement a menu like navigation
possibilities where user can use arrow keys to move between, collapse
and expand page elements. This is important on landing pages with
hundreds of links, often links that basically fall into basic
categories or set of related user actions.
Finally intelligent use of headings (WCAG 1.3.1), lists and tables at
least provides basis for assistive technologies to help user quickly
navigate your content.

Finally, on top of all that, some websites have implemented specific
keyboard interaction patterns for keyboard only users.
For instance, if you go to www.twitter.com and sign in, you can use
'j' to advance to next tweet in your timeline,
'k' to go to the previous one.
'r' to reply to a tweet.
't' to retweet it
...

I would be mindful of not overdoing these patterns of user
interactions, and reserve this type of functionality for very
frequently performed actions on the page.
If you provide 30 keyboard shortcuts specific to your website, I think
users are extremely unlikely to learn them, let alone use them.
If you consider offering 3 to 5 keyboard shortcuts for actions you
believe users will engage in regularly, that is a different matter.
You need to make sure you have an avenue to clearly communicate this
possibility to your users.
Finally, observing traditions, such as allowing the user to press the
escape key to cancel or close out pop ups is important and helps
foster consistency and predictability.

Cheers
-Birkir
Birkir Gunnarsson
Senior Accessibility Consultant | Deque Systems





On 2/14/14, Akshi Kakar < = EMAIL ADDRESS REMOVED = > wrote:
> I have been referring to WCAG 2.0 to meet all accessibility requirements for
> our web application and have questions about one specific requirement:
>
> "2.1.1 Keyboard: All functionality<http://www.w3.org/TR/WCAG20/#functiondef>;
> of the content is operable through a keyboard
> interface<http://www.w3.org/TR/WCAG20/#keybrd-interfacedef>; without
> requiring specific timings for individual keystrokes, except where the
> underlying function requires input that depends on the path of the user's
> movement and not just the endpoints. (Level A)"
>
> I have read the 'How to Meet' and 'Understanding' portions of this criteria
> and understood that all user actions that require continuous mouse movement
> such as 'drag and drop' need to have a keyboard alternative.
>
> My question is, do we need to provide keyboard shortcuts or alternatives for
> the basic navigation within the web application or do users access them
> through the arrow/tab keys or the screen reader? This is probably a question
> for users of alternative keyboards or those with motor disabilities.
>
> Thank you for your time.
>
> Regards,
> Akshi
>
> > > >


--
Work hard. Have fun. Make history.