This document provides an introduction to keyboard navigation and accessibility. It discusses why keyboard navigation is important, who uses it, common techniques for navigating websites via keyboard, and guidelines from the Web Content Accessibility Guidelines (WCAG) for ensuring keyboard accessibility. Key points covered include how to navigate using tab keys and shortcuts, guidelines for focus order, bypassing blocks, avoiding keyboard traps, and ensuring visible focus indicators.
2. Why talk about keyboard navigation first? 1
https://matthewdeeprose.github.io/keyboardnav.html
It covers fundamental aspects of accessibility and
accessibility testing.
Awareness should have a positive impact in
improving iSolutions services.
It introduces other concepts we’ll discuss in future
meetings.
3. Why talk about keyboard navigation first? 2
https://matthewdeeprose.github.io/keyboardnav.html
It covers fundamental aspects of accessibility and
accessibility testing.
Awareness should have a positive impact in
improving iSolutions services.
It introduces other concepts we’ll discuss in future
meetings.
4. Why talk about keyboard navigation first? 3
https://matthewdeeprose.github.io/keyboardnav.html
It covers fundamental aspects of accessibility and
accessibility testing.
Awareness should have a positive impact in
improving iSolutions services.
It introduces other concepts we’ll discuss in future
meetings.
5. What do we mean by keyboard navigation?
A method to navigate web
pages / software etc for
those who cannot or do
not wish to use a mouse
or trackpad.
https://matthewdeeprose.github.io/keyboardnav.html
6. Keyboard (non-mouse) navigation (1)
Not only for keyboard navigation
Used with other assistive technologies, e.g.
• Mouth stick, head pointer, eye gaze, sip-
and-puff.
Focus indicators are used by screen readers
Power users love keyboard shortcuts
https://matthewdeeprose.github.io/keyboardnav.html
7. Keyboard (non-mouse) navigation (2)
Navigate website using tab, enter/return, cursor keys
Interaction Keystrokes
Navigate to most
elements
Tab
Shift + Tab - navigate backward
Link Enter (PC) / Return (Mac)
Button
Enter (PC) / Return (Mac)
or Spacebar
Checkbox Spacebar - check/uncheck a checkbox
Radio buttons
↑ / ↓ or ← / → = select an option.
Tab - move to the next element.
https://webaim.org/techniques/keyboard/
Deque Systems
UX Collective
https://matthewdeeprose.github.io/keyboardnav.html
8. Demonstration 1 on example site
https://mle.southampton.ac.uk/bb/access/example
https://matthewdeeprose.github.io/keyboardnav.html
9. Who uses keyboard navigation? (1)
Roughly 7% of working-age adults who have severe
dexterity difficulties* are likely to choose, out of
necessity or preference, to use their keyboard to
navigate a page or some kind of assistive technology to
browse content online.
31.9%** of people in the US workplace have at least
one basic action difficulty or limitation.
https://matthewdeeprose.github.io/keyboardnav.html
* https://www.powermapper.com/blog/website-accessibility-disability-statistics/
** https://www.disabled-world.com/disability/types/mobility/
10. Who uses keyboard navigation? (3)
Conditions such as…
• Multiple sclerosis
• Dyspraxia
• Parkinson’s disease
• Arthritis
• Carpal tunnel syndrome
…impair or limit fine motor skills.
https://matthewdeeprose.github.io/keyboardnav.html
11. Who uses keyboard navigation? (4)
Visually impaired users: using a mouse requires hand /
eye co-ordination.
Those using Dragon Dictate (for example) to navigate
their computer while not using the mouse or keyboard.
“Tab”, “Tab”, “Tab”, “Click Link”, “8”
https://matthewdeeprose.github.io/keyboardnav.html
12. Who uses keyboard navigation? (5)
A user with a broken mouse or trackpad.
Photo credit:
https://www.reddit.com/user/TheRealTrietsLab
https://matthewdeeprose.github.io/keyboardnav.html
13. Types of impairment Microsoft Design
https://matthewdeeprose.github.io/keyboardnav.html
14. Example situational impairments
Using someone else’s
computer: they have a
trackball, trackpad, unusual
mouse that you don’t like /
know how to use…
https://matthewdeeprose.github.io/keyboardnav.html
15. Example situational impairments (2)
Using device one-handed.
Using device in a cramped space
with limited movement.
Adobe Stock Image
https://matthewdeeprose.github.io/keyboardnav.html
16. What recommendations are there?
The Web Content Accessibility Guidelines provide a
method for us to ensure we can use keyboard
navigation.
https://matthewdeeprose.github.io/keyboardnav.html
17. Levels of conformance: A
https://matthewdeeprose.github.io/keyboardnav.html
A
Minimum level
of conformance.
AA
AAA
18. Levels of conformance: AA
https://matthewdeeprose.github.io/keyboardnav.html
A
Minimum level
of conformance.
AA
More accessible
/
Recommended.
AAA
19. Levels of conformance: AAA
https://matthewdeeprose.github.io/keyboardnav.html
A
Minimum level
of conformance.
AA
More accessible
/
Recommended.
AAA
Even more
accessible /
Enhanced.
20. Aspects of WCAG that relate to keyboard
navigation (introduction)
https://matthewdeeprose.github.io/keyboardnav.html
We can use the site with
a keyboard.
• 2.1.1 Keyboard
• 2.1.3 Keyboard (No
Exception)
There is consideration for
how we experience sites
when using a keyboard.
• 2.4.1 Bypass Blocks
• 2.4.3 Focus Order
• 2.1.2 No Keyboard Trap
• 2.1.4 Character Key
Shortcuts
Visual indications of the
interface are clear.
• 2.4.7 Focus Visible
• 2.4.11 Focus
Appearance (Minimum)
• 2.4.12 Focus
Appearance
(Enhanced)
21. Aspects of WCAG that relate to keyboard
navigation (introduction) (2)
https://matthewdeeprose.github.io/keyboardnav.html
We can use the site with
a keyboard.
• 2.1.1 Keyboard
• 2.1.3 Keyboard (No
Exception)
There is consideration for
how we experience sites
when using a keyboard.
• 2.4.1 Bypass Blocks
• 2.4.3 Focus Order
• 2.1.2 No Keyboard Trap
• 2.1.4 Character Key
Shortcuts
Visual indications of the
interface are clear.
• 2.4.7 Focus Visible
• 2.4.11 Focus
Appearance (Minimum)
• 2.4.12 Focus
Appearance
(Enhanced)
22. Aspects of WCAG that relate to keyboard
navigation (introduction) (3)
https://matthewdeeprose.github.io/keyboardnav.html
We can use the site with
a keyboard.
• 2.1.1 Keyboard
• 2.1.3 Keyboard (No
Exception)
There is consideration for
how we experience sites
when using a keyboard.
• 2.4.1 Bypass Blocks
• 2.4.3 Focus Order
• 2.1.2 No Keyboard Trap
• 2.1.4 Character Key
Shortcuts
Visual indications of the
interface are clear.
• 2.4.7 Focus Visible
• 2.4.11 Focus
Appearance (Minimum)
• 2.4.12 Focus
Appearance
(Enhanced)
23. Accessibility guidelines have four high-level
principles.
Perceivable
Cater to our
senses.
Operable
We can use
the site.
Understandable
Readable
and
predictable.
Robust
Compatible
across
devices -
even those
to come in
the future.
https://matthewdeeprose.github.io/keyboardnav.html
24. Keyboard navigation applies to two of these
principles.
Perceivable
Cater to our
senses.
Operable
We can use
the site.
Understandable
Readable
and
predictable.
Robust
Compatible
across
devices -
even those
to come in
the future.
https://matthewdeeprose.github.io/keyboardnav.html
25. 2.1.1 Keyboard
(Level A)
• All functionality of the content is operable through a
keyboard interface 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.
https://www.w3.org/TR/WCAG22/#keyboard
https://matthewdeeprose.github.io/keyboardnav.html
26. 2.1.3 Keyboard (No Exception)
(Level AAA)
• All functionality of the content is operable through a
keyboard interface without requiring specific timings
for individual keystrokes.
https://www.w3.org/TR/WCAG22/#keyboard-no-
exception
https://matthewdeeprose.github.io/keyboardnav.html
27. 2.4.1 Bypass Blocks
(Level A)
• A mechanism is available to bypass blocks of content
that are repeated on multiple Web pages.
https://www.w3.org/TR/WCAG22/#bypass-blocks
https://matthewdeeprose.github.io/keyboardnav.html
28. Example of a Bypass Block
https://matthewdeeprose.github.io/keyboardnav.html
29. 2.4.3 Focus Order
(Level A)
• If a Web page can be navigated sequentially and the
navigation sequences affect meaning or operation,
focusable components receive focus in an order that
preserves meaning and operability.
https://www.w3.org/TR/WCAG22/#focus-order
https://matthewdeeprose.github.io/keyboardnav.html
30. Example of Focus Order
https://matthewdeeprose.github.io/keyboardnav.html
31. Demonstration 2 on example site
• https://mle.southampton.ac.uk/bb/access/example
https://matthewdeeprose.github.io/keyboardnav.html
32. 2.1.2 No Keyboard Trap
(Level A)
• If keyboard focus can be
moved to a component of
the page using a keyboard
interface…
• focus can be moved away
from that component using
only a keyboard interface,
• if it requires more than
unmodified arrow or tab
keys or other standard exit
methods, the user is
advised of the method for
moving focus away.
https://matthewdeeprose.github.io/keyboardnav.html
https://www.w3.org/TR/WCAG22/#no-keyboard-trap
33. Examples
• Press Escape to leave a
modal (pop up box).
•Similarly in modals,
making sure that you can
only tab between links /
actions with the modal,
and not content outside
of it.
https://matthewdeeprose.github.io/keyboardnav.html
34. 2.1.4 Character Key Shortcuts
(Level A)
If a keyboard shortcut is
implemented in content using
only letter (including upper- and
lower-case letters),
punctuation, number, or symbol
characters, then at least one of
the following is true:
• Turn off
• A mechanism is available to turn
the shortcut off;
• Remap
• A mechanism is available to
remap the shortcut to include
one or more non-printable
keyboard keys (e.g., Ctrl, Alt);
• Active only on focus
• The keyboard shortcut for a user
interface component is only
active when that component has
focus.
https://matthewdeeprose.github.io/keyboardnav.html
https://www.w3.org/TR/WCAG22/#character-key-shortcuts
35. Which of the WCAG principles are we
considering? (2)
Perceivable
Cater to our
senses.
Operable
We can use
the site.
Understandable
Readable
and
predictable.
Robust
Compatible
across
devices -
even those
to come in
the future.
https://matthewdeeprose.github.io/keyboardnav.html
36. 2.4.7 Focus Visible
(Level A) Any keyboard
operable user
interface has a mode
of operation where
the keyboard focus
indicator is visible.
https://matthewdeeprose.github.io/keyboardnav.html
https://www.w3.org/TR/WCAG22/#focus-visible
41. 2.4.11 Focus Appearance (Minimum) 1
(Level AA)
• For the keyboard focus
indicator of each User
Interface Component, all of
the following are true:
• Minimum area:
The focus indication area is
greater than or equal to a
1 CSS pixel border of the
focused control, or has a
thickness of at least 8 CSS
pixels along the shortest side
of the element.
https://www.w3.org/TR/WCAG22/#focus-appearance-minimum
https://matthewdeeprose.github.io/keyboardnav.html
42. 2.4.11 Focus Appearance (Minimum) 2
(Level AA)
• For the keyboard focus
indicator of each User
Interface Component, all
of the following are true:
Change of contrast:
The color change for the
focus indication area has a
contrast ratio of at least
3:1 with the colors of the
unfocused state.
https://www.w3.org/TR/WCAG22/#focus-appearance-minimum
https://matthewdeeprose.github.io/keyboardnav.html
43. 2.4.11 Focus Appearance (Minimum) 3
(Level AA)
• For the keyboard focus
indicator of each User
Interface Component, all of
the following are true:
Adjacent contrast:
• The focus indication area
has a contrast ratio of at
least 3:1 against all
adjacent colors for the
minimum area or greater,
or has a thickness of at
least 2 CSS pixels.
https://www.w3.org/TR/WCAG22/#focus-appearance-minimum
https://matthewdeeprose.github.io/keyboardnav.html
44. 2.4.11 Focus Appearance (Minimum) 4
(Level AA)
• For the keyboard focus
indicator of each User
Interface Component, all
of the following are true:
Unobscured:
•The item with focus is
not entirely hidden by
author-created content.
https://www.w3.org/TR/WCAG22/#focus-appearance-minimum
https://matthewdeeprose.github.io/keyboardnav.html
45. 2.4.12 Focus Appearance (Enhanced) 1
(Level AAA)
• For the keyboard focus
indicator of each User
Interface Component, all
of the following are true:
Minimum area:
•The focus indication
area is greater than or
equal to a 2 CSS
pixel solid border around
the control.
https://www.w3.org/TR/WCAG22/#focus-appearance-enhanced
https://matthewdeeprose.github.io/keyboardnav.html
46. 2.4.12 Focus Appearance (Enhanced) 2
(Level AAA)
• For the keyboard focus
indicator of each User
Interface Component, all
of the following are true:
Change of contrast:
•Color changes used to
indicate focus have a
contrast ratio of at least
4.5:1 with the colors
changed from the
unfocused control.
https://www.w3.org/TR/WCAG22/#focus-appearance-enhanced
https://matthewdeeprose.github.io/keyboardnav.html
47. 2.4.12 Focus Appearance (Enhanced) 3
(Level AAA)
• For the keyboard focus
indicator of each User
Interface Component, all
of the following are true:
Unobscured:
•No part of the focus
indicator is hidden by
author-created content.
https://www.w3.org/TR/WCAG22/#focus-appearance-enhanced
https://matthewdeeprose.github.io/keyboardnav.html
49. Examples of different colour contrasts
https://matthewdeeprose.github.io/keyboardnav.html
Revisiting hard to read contrast
examples
Hard to read
1.19:1
Hard to read
1.64:1
Hard to read
1.84:1
Hard to read? 2.71:1 Hard to read? 2.96:1 Hard to read? 4:1
Easy to read
7.58:1 Easy to read 15.27:1 Easy to read 21:1
50. The ratios to remember
3:1
4.5:1
7:1
Minimum for
Graphical
Objects / UI
AA
Minimum for Text
AAA
Enhanced level
for Text
(not to scale)
1.4.11 Non-text Contrast (Level AA) 1.4.3 Contrast (Minimum) (Level AA) 1.4.6 Contrast (Enhanced) (Level AAA):
https://matthewdeeprose.github.io/keyboardnav.html
51. More about colour contrast in a future session
https://matthewdeeprose.github.io/keyboardnav.html
52. Aspects of WCAG that relate to keyboard
navigation (summary)
https://matthewdeeprose.github.io/keyboardnav.html
We can use the site with
a keyboard.
• 2.1.1 Keyboard
• 2.1.3 Keyboard (No
Exception)
There is consideration for
how we experience sites
when using a keyboard.
• 2.4.1 Bypass Blocks
• 2.4.3 Focus Order
• 2.1.2 No Keyboard Trap
• 2.1.4 Character Key
Shortcuts
Visual indications of the
interface are clear.
• 2.4.7 Focus Visible
• 2.4.11 Focus
Appearance (Minimum)
• 2.4.12 Focus
Appearance
(Enhanced)
53. So what do I need to remember? (1)
• Can I use the keyboard to use the site/service?
• Without getting “trapped”.
• With a sensible order of making my way through it?
• Can I see the focus indicator clearly?
• Can I “skip to content”?
https://matthewdeeprose.github.io/keyboardnav.html
54. So what do I need to remember? (2)
• Can I use the keyboard to use the site/service?
• Without getting “trapped”.
• With a sensible order of making my way through it?
• Can I see the focus indicator clearly?
• Can I “skip to content”?
https://matthewdeeprose.github.io/keyboardnav.html
55. So what do I need to remember? (3)
• Can I use the keyboard to use the site/service?
• Without getting “trapped”.
• With a sensible order for making my way through it?
• Can I see the focus indicator clearly?
• Can I “skip to content”?
https://matthewdeeprose.github.io/keyboardnav.html
56. So what do I need to remember? (4)
• Can I use the keyboard to use the site/service?
• Without getting “trapped”.
• With a sensible order for making my way through it?
• Can I see the focus indicator clearly?
• Can I “skip to content”?
https://matthewdeeprose.github.io/keyboardnav.html
57. So what do I need to remember? (5)
• Can I use the keyboard to use the site/service?
• Without getting “trapped”.
• With a sensible order for making my way through it?
• Can I see the focus indicator clearly?
• Can I “skip to content”?
https://matthewdeeprose.github.io/keyboardnav.html
58. Final demonstration
Access the prospectus from an example University web
page:
• https://www.southampton.ac.uk/student-
life/accommodation
https://matthewdeeprose.github.io/keyboardnav.html
Links we will use:https://mle.southampton.ac.uk/bb/access/example
https://www.southampton.ac.uk/student-life/accommodation
In order not to trigger any participants I have made a bland generic web page for demonstrations purposes.
These guidelines inform EN 301 549 which is the standard used in the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (PSBAR)
Input depending on the path:
Free-hand drawing is an example of functions that require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input.
The use of MouseKeys would not satisfy pass because it is not a keyboard equivalent to the application; it is a mouse equivalent (i.e., it looks like a mouse to the application).
“some AAA criteria can not be applied everywhere”
Like parking in front of a disabled ramp.
Aimed at reducing accidental use of shortcuts..
Keyboard shortcut = using one or more keys.
Only where a combination is concerned, e.g. alt and then f is two step.
While there is a AA version of this success criterion, I believe the AAA is simpler because in the AA version we have to consider