1 of 59

Introduction to �Keyboard Navigation �and Accessibility

https://matthewdeeprose.github.io/keyboardnav.html

2 of 59

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 of 59

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 of 59

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 of 59

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 of 59

Keyboard (non-mouse) navigation (1)

https://matthewdeeprose.github.io/keyboardnav.html

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

7 of 59

Keyboard (non-mouse) navigation (2)

Navigate website using tab, enter/return, cursor keys

https://matthewdeeprose.github.io/keyboardnav.html

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.

Deque Systems

​

UX Collective

8 of 59

Demonstration 1 on example site

https://matthewdeeprose.github.io/keyboardnav.html

9 of 59

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

10 of 59

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 of 59

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.

https://matthewdeeprose.github.io/keyboardnav.html

“Tab”, “Tab”, “Tab”, “Click Link”, “8”

12 of 59

Who uses keyboard navigation? (5)

A user with a broken mouse or trackpad.

https://matthewdeeprose.github.io/keyboardnav.html

13 of 59

Types of impairment

https://matthewdeeprose.github.io/keyboardnav.html

Microsoft Design

14 of 59

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 of 59

Example situational impairments (2)

https://matthewdeeprose.github.io/keyboardnav.html

Using device one-handed.

Using device in a cramped space with limited movement.

Adobe Stock Image

16 of 59

What recommendations are there?

https://matthewdeeprose.github.io/keyboardnav.html

The Web Content Accessibility Guidelines provide a method for us to ensure we can use keyboard navigation.

17 of 59

Levels of conformance: A

https://matthewdeeprose.github.io/keyboardnav.html

A

Minimum level of conformance.

​

AA

AAA

18 of 59

Levels of conformance: AA

https://matthewdeeprose.github.io/keyboardnav.html

A

Minimum level of conformance.

​

AA

More accessible / Recommended.

AAA

19 of 59

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 of 59

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 of 59

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 of 59

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 of 59

Accessibility guidelines have four high-level principles.

https://matthewdeeprose.github.io/keyboardnav.html

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.

24 of 59

Keyboard navigation applies to two of these principles.

https://matthewdeeprose.github.io/keyboardnav.html

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.

25 of 59

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 of 59

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 of 59

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 of 59

Example of a Bypass Block

https://matthewdeeprose.github.io/keyboardnav.html

29 of 59

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 of 59

Example of Focus Order

https://matthewdeeprose.github.io/keyboardnav.html

31 of 59

Demonstration 2 on example site

https://matthewdeeprose.github.io/keyboardnav.html

32 of 59

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

33 of 59

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 of 59

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

35 of 59

Which of the WCAG principles are we considering? (2)

https://matthewdeeprose.github.io/keyboardnav.html

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.

36 of 59

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

37 of 59

More examples

https://matthewdeeprose.github.io/keyboardnav.html

38 of 59

Indicating focus, example 1

https://matthewdeeprose.github.io/keyboardnav.html

39 of 59

Indicating focus, example 2

https://matthewdeeprose.github.io/keyboardnav.html

40 of 59

Indicating focus, example 3

https://matthewdeeprose.github.io/keyboardnav.html

41 of 59

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://matthewdeeprose.github.io/keyboardnav.html

42 of 59

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://matthewdeeprose.github.io/keyboardnav.html

43 of 59

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://matthewdeeprose.github.io/keyboardnav.html

44 of 59

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://matthewdeeprose.github.io/keyboardnav.html

45 of 59

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://matthewdeeprose.github.io/keyboardnav.html

46 of 59

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://matthewdeeprose.github.io/keyboardnav.html

47 of 59

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://matthewdeeprose.github.io/keyboardnav.html

48 of 59

Colour contrast?

https://matthewdeeprose.github.io/keyboardnav.html

49 of 59

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 of 59

The ratios to remember

https://matthewdeeprose.github.io/keyboardnav.html

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):

51 of 59

More about colour contrast in a future session

https://matthewdeeprose.github.io/keyboardnav.html

52 of 59

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 of 59

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 of 59

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 of 59

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 of 59

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 of 59

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 of 59

Final demonstration

Access the prospectus from an example University web page:

​

https://matthewdeeprose.github.io/keyboardnav.html

59 of 59

https://matthewdeeprose.github.io/keyboardnav.html