User Needs Exercise - Mobile

	A	B	C	D	E	F	G	H	I	J	K	L	M
1	Mobile 2.1 SC User Needs Exercise						https://docs.google.com/document/d/1eJkgXqbh7dx3uD6XAy8XAANmwfbbVZ5GKb_gbsUdkVs/edit#heading=h.n89ecixaq6rg
2	NOTE: This is an MATF exercise – still in progress. We thought it would be useful to plot out just user needs as a first step toward converting the Mobile SCs to 3.0. We wanted to make sure we're doing the first step right. This is also allowing us to see user needs across all the mobile 2.1 SCs at once to see how they relate to each other.
3	ID	Existing SC(s)	SC URL	User Need(s)	Outcome (Testable criteria)	User Type(s)	Functional needs list	Related (current) SCs	Need types (Critical, Critical process, Critical aggregate)	Potential User Clashes – where an accommodation for one type of user may hinder another type of user	Way to resolve the clash?	Notes	New SC Needed?

4	Kim	2.1.4 Character key shortcuts	https://www.w3.org/TR/WCAG21/#character-key-shortcuts	No single-character-key shortcuts because these clash with speech input. Way to map singlekey shortcuts to 1-30 letter shortcuts so that functionality is preserved without single-character-key shortcuts..	Prevents Accidental input by speech (Jake) Users don't have to be hypervigilant to avoid traps from shortcuts that are inappropriate for their input method(s) (Kim) Users can access functionality using shortcuts that are appropriate for the input method(s) they use (Kim)	Mobility – Speech Input		4.1.2 Name, Role, Value	C, CA	This makes some regular keyboard users more efficient. vs. This makes programs unusable for speech Input users.	Yes – letting users change shortcuts resolves the clash
5	Kim	2.1.4 Character key shortcuts	https://www.w3.org/TR/WCAG21/#character-key-shortcuts	No single-character-key shortcuts because these cause errors. Way to map singlekey shortcuts to shortcuts that includs control key so that functionality is preserved without single-character-key shortcuts.	Users don't have to be hypervigilant to avoid traps from shortcuts that are inappropriate for their input method(s) Users can access functionality using shortcuts that are appropriate for the input method(s) they use	Mobility – Keyboard input		4.1.2 Name, Role, Value 2.1.1 Keyboard	C, CA	This makes some regular keyboard users more efficient. vs. This increases the potential for mistakes for some keyboard users.	Yes – letting users change shortcuts resolves the clash
6	Kim	2.1.4 Character key shortcuts	https://www.w3.org/TR/WCAG21/#character-key-shortcuts	No single-character-key shortcuts because these cause errors. Clear instructions about single-character key shortcuts and a way to change them so that functionality is preserved without single-character-key shortcuts.	Users don't have to be hypervigilant to avoid traps from shortcuts that are inappropriate for their input method(s) Users can access functionality using shortcuts that are appropriate for the input method(s) they use	Cognition – Keyboard or speech input		3.2.7 Hidden Controls	C, CA	This makes some regular keyboard users more efficient. vs. Character key shortcuts may not be apparent, increasing the potential for mistakes and confusion about how those mistakes happened.	Yes – letting users change shortcuts and/or clearly documenting that the shortcuts exist and that they can be changed.
7	Detlev	2.5.6 Concurrent Input Mechanisms	https://www.w3.org/TR/WCAG21/#concurrent-input-mechanisms	During operation, the user wants to change input mode from keyboard to pointer on the same device During operation, the user wants to change input mode from keyboard on a desktop device to touch on a mobile device	All controls are operable with multiple input modes allowing hand-over to another input mode or device	Mobility – Keyboard input		2.1.1 Keyboard 2.5.1 Pointer Gestures		probably none		Changing mode to pointer can be occasioned when some control cannot easily be activated by keyboard because it does nit get kb focus
8	Detlev	2.5.6 Concurrent Input Mechanisms	https://www.w3.org/TR/WCAG21/#concurrent-input-mechanisms	During operation, the user wants to change input mode from touch to keyboard input to target input on the same device During operation, the user wants to change input mode from touch on a mobile device to keyboard input on a desktop device	All controls are operable with multiple input modes allowing hand-over to another input mode or device	Mobility – Pointer input (touch)		2.1.1 Keyboard 2.5.1 Pointer Gestures		probably none		Changing mode to keyboard can be occasioned when some control cannot easily be activated by pointer (say, input involving complex gestures)
9	Detlev	2.5.6 Concurrent Input Mechanisms	https://www.w3.org/TR/WCAG21/#concurrent-input-mechanisms	During operation, the user wants to change input mode from mouse input to touch input on the same device	All controls are operable with multiple input modes allowing hand-over to another input mode or device	Mobility – Pointer input (mouse)		2.1.1 Keyboard 2.5.1 Pointer Gestures		probably none		Changing mode to keyboard can be occasioned when some control cannot easily be activated by pointer (say, input involving complex gestures)
10	Detlev	2.5.6 Concurrent Input Mechanisms	https://www.w3.org/TR/WCAG21/#concurrent-input-mechanisms	During operation, the user wants to change input mode from speech input to either target or keyboard input During operation, the user wants to change input mode from speech on one device to target or keyboard on another device	All controls are operable with multiple input modes allowing fast, seamless hand-over to another input mode or device	Mobility – Speech input		2.1.1 Keyboard 2.5.1 Pointer Gestures		probably none		Changing mode to keyboard OR pointer can be occasioned when some control cannot easily be activated by speech
11	Jake	2.5.3 Label In Name	https://www.w3.org/TR/WCAG21/#label-in-name	Operable: - User needs to operate controls from the label text alone (name) Perceivable: - User needs matching visual text and speech (for components)	Provide matching visual and programmatic determinable text	Speech input and speech output		1.3.1 Info and Relationships 3.2.2 Labels or Instructions 4.1.2 Name, Role, Value		probably none
12	Kim	2.5.3 Label In Name	https://www.w3.org/TR/WCAG21/#label-in-name	Speech input users need to construct viable speech commands from the words they see on the screen	Words on screen match labels	Mobility – speech input		1.3.1 Info and Relationships 3.2.2 Labels or Instructions 4.1.2 Name, Role, Value		User needs don't clash
13	Kim	2.5.3 Label In Name	https://www.w3.org/TR/WCAG21/#label-in-name	Users who can't see what's on screen need to glean information from labels.	Words on screen match labels	Vision – speech output		1.3.1 Info and Relationships 4.1.2 Name, Role, Value		User needs don't clash
14	Kim	2.5.3 Label In Name	https://www.w3.org/TR/WCAG21/#label-in-name	Different kinds of users need to be able to communicate about labels they perceive using different methods	Words on screen match labels	All types of users		1.3.1 Info and Relationships 4.1.2 Name, Role, Value		User needs don't clash
15	Jake	2.5.4 Motion Actuation	https://www.w3.org/TR/WCAG21/#motion-actuation	Operable: - User needs to operate via controls - User need option to prevent motion actuation (more abstract: user needs option to turn off functionality)	Provide functionality via controls Provide settings function to turn off motion actuation (functionality)	Mobility –		2.1.1 Keyboard 2.5.1 Pointer Gestures
16	Jennifer	2.5.4 Motion Actuation	https://www.w3.org/TR/WCAG21/#motion-actuation	User needs the ability to operate via controls	User should be able to use functionality via controls without needing to move their device, especially if device is mounted in a fixed position.	Mobility - Consistent presentation		2.1.1 Keyboard 2.5.1 Pointer Gestures		User needs don't clash
17	Jennifer	2.5.4 Motion Actuation	https://www.w3.org/TR/WCAG21/#motion-actuation	User needs the ability to turn off motion actuation	User should be able to turn off motion actuation (functionality) to prevent accidental activation of the functionality.	Mobility		2.1.1 Keyboard 2.5.1 Pointer Gestures		User needs don't clash
18	Sukriti	1.3.4 Orientation	https://www.w3.org/TR/WCAG21/#orientation	User needs the ability to switch between landscape and portrait mode	Allows the user to access information in their desired orientation in case of fixed mounting or motor impairments	Mobility - Consistent presentation		1.4.10 Reflow	C	Having a device mount on a wheelchair or other mobility assistive device can limit the orientation the device can be used in. If an application does not allow for this flexibility, it might be challenging for users to look at information sideways, and lose context	Enabling landscape and portait support for screens wherever possible
19	Sukriti	1.3.4 Orientation	https://www.w3.org/TR/WCAG21/#orientation	User needs the ability to persist landscape or portrait mode	Allows the user to access information in their desired orientation in case of fixed mounting or motor impairments	Cognition - Visual consistency		1.4.10 Reflow	C	Once an orientation is set, all screens should present information consistent with user choice. If the setting does not persist, it might add to cognitive load in addition to motor challenges for the user while navigating between screens	Persisting orientation setting between apps, screens and at the time of the switch (in cases where changes have been made, and the orientation switch causes the information to reload)
20		1.3.4 Orientation	https://www.w3.org/TR/WCAG21/#orientation	Do users who need captions have orientation needs?				1.2.5 Captions
21	Detlev	2.5.5 Target Size	https://www.w3.org/TR/WCAG21/#target-size	No tiny or close-together targets so accidental activation is prevented	Allows users to activate the intended target Missing the target does not accidentally activate not intended targets	Mobility – Pointer input		1.4.3 Text Contrast 1.4.11 Non-Text Contrast 2.4.7 Focus 2.4.11 Focus Appearance (Minimum) 2.5.8 (WCAG 2.2) Target Size (Minimum)	C	Having large targets can reduce the amount of content visible at any one time in th eviewport and negatively affect the visibility of structure. It can lead to more scolling adding to navigational effort for all users	Optimising content structures so meaningful groups of content will be morwe likely to fit into the screen real estate. Negative side effect: Content gets more segmented, navigation effort increases
22	Detlev	2.5.1 Pointer Gestures	https://www.w3.org/TR/WCAG21/#pointer-gestures	No complex gestures to activate things without siongle-point pointer operable alternative	Users have an alternative option for activation for all input that requires users to perform compex pointer gestures like swiping or multi-point activation	Mobility – Pointer input		2.5.7 (WCAG 2.2) Dragging 2.5.8 (WCAG 2.2) Target Size (Minimum)	C	Additional single-pointer-operable controls can make the interface busier and increas the cognitive load	Embed controls or make them implicit in a way that they don't make the interface much busier. An example is a tappable (clickable groove of a slider control. Use controls to emphasise also complex gesture affordances. An example is arrows overlaying an image slider, emphasizin also that swipe gestures might bring in hidden content.
23	Detlev	2.5.1 Pointer Gestures	https://www.w3.org/TR/WCAG21/#pointer-gestures	Simple and obvious single-point pointer operable controls are available (e.g. a [+] and [-] controls to increment / decrement a slider value, advance an image slider, or delete an item)	Users have an alternative option for activation for all input that requires users to perform compex pointer gestures like swiping or multi-point activation	Cognition – Visible affordance		1.4.3 Text Contrast 1.4.11 Non-Text Contrast	C	Additional single-pointer-operable controls can make the interface busier and increas the cognitive load	Embed controls or make them implicit in a way that they don't make the interface much busier. An example is a tappable (clickable groove of a slider control. Use controls to emphasise also complex gesture affordances. An example is arrows overlaying an image slider, emphasizin also that swipe gestures might bring in hidden content.
24	Detlev	2.5.2 Pointer Cancellation	https://www.w3.org/TR/WCAG21/#pointer-cancellation	No unintentional or hesitant input has consequences that cannot be easily reversed	The beginning of a target activation still gives users the option to back away from it Affordances or behavior or controls make it obvious that actions can easily be reversed	Mobility – Pointer input		3.2.1 On Focus 3.2.2 On Input 2.5.8 (WCAG 2.2) Target Size (Minimum)	C	In some scenarios activation might be slower when each activation only happens on the up event. (Examples currently missing). So it may be more a conflict with efficiency / speed rather than with other specific user needs.
25	Detlev	2.5.2 Pointer Cancellation	https://www.w3.org/TR/WCAG21/#pointer-cancellation	No target input has immediate unexpected and potentially disorienting consequences	The beginning of a target activation still gives users the option to back away from it Affordances or behavior or controls make it obvious that actions can easily be reversed	Cognition – State changes		3.2.1 On Focus 3.2.2 On Input	C	In some scenarios activation might be slower when each activation only happens on the up event. (Examples currently missing). So it may be more a conflict with efficiency / speed rather than with other specific user needs.
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100