[DOCS] Add APX design patterns

[FiniteStateGit]

Describe the issue briefly

Document O3DE implementations of the Accessible Player Experience (APX) design patterns found at: https://accessible.games/accessible-player-experiences/

Note: This is not a request to document APX or the specific design pattern, problem and solution definitions. The table below lists the problem and solution definitions for context only, followed by a short description of an implementation to be documented.

Problem & solution definitions	Description of documentation request
Problem: Players are unable or unreliably able to take in information from the game and/or its interfaces via a particular modality, and cannot rely solely on it for information.	Send vibration events to an input device.
Solution: Players can select additional channels of information via different modalities so they can reliably take in information from the game or its interfaces.	Caption key ambient/environmental sounds.
	Display visual indicators for directional audio.
	Distinct sound effects for distinct gameplay events.
	Spoken dialogue with text captioning.
Problem: Players cannot enter text into the game through a standard input device or interface.	Add keyboard input to consoles.
Solution: Players can replace a standard interface with an alternative so that they can enter text into the game.	Configure keyboard input language, key repeat delay, and key repeat rate.
	Replace text entry with speech-to-text.
	Communicate with teammates on multiple channels (audio, text, visual indicators) simultaneously via a UI wheel.
Problem: Players cannot reliably read the text in the game or its interfaces.	Control the flow of dialogue with auto-play, message backlogs and a reference to previous dialogue.
Solution: Players can change the way text is presented to them in the game or its interfaces so that it can be read reliably.	Enhance text readability with letterbox captioning.
	Configure the size of on-screen text.
	Configure HUD color schemes.
	Configure console captioning systems.
Problem: Players cannot effectively use the controls of the game in their standard configuration.	Configure keybinds, release checks, alternate controls, shortcuts and macros.
Solution: Players are able to remap controls of the game so that they can effectively use the controls of the game or its interfaces.	Configure camera movement.
	Configure style of input interactions (toggles, holds vs. taps, tapping speed).
	Configure single-handed, multiplayer shared-controller, and multiplayer shared control (with different input devices) input schemes.
	Configure alternate ergonomic controls (Face-only mapping on a gamepad).
	Configure controls with varying complexity (Button press vs. directional skillshot).
	Configure alternate controls for the same in-game actions (walk with mouse or keyboard).
Problem: Players cannot be precise in their actions in the game or its interfaces.	Customize the sensitivity of camera movement.
Solution: Players can adjust the precision of actions so that they can successfully target, move, or navigate in the game or its interfaces.	Customize mouse sensitivities.
	Customize the sensitivities of zoom events.
Problem: Players cannot successfully undertake a sequence of actions required by the game.	Automate game actions to reduce button presses.
Solution: Players can reduce the number of actions in the sequence so that they can successfully make progress in the game.
Problem: Players cannot use the user interface components due to their size, layout, content, or structure.	Configure HUD layout.
Solution: Players can show, hide, resize, pin, or rearrange user interface components so they can effectively and efficiently use them.	Customize UI scale.
	Resize and set opacity for UI elements.
	Customize HUDs to show/hide and dynamically display UI elements.
	Minimize the complexity of menu navigation with shortcuts.
Problem: Players cannot use standard controllers or input devices to interact in the game or its interfaces.	Using an Xbox Adaptive Controller (XAC) as an input device.
Solution: Players can replace a standard controller or input devices with an alternative piece of hardware or software so that they can interact with the game and its interfaces.
Problem: Players cannot reliably identify differences within the game or its interfaces.	Customize high-contrast reticles.
Solution: Players can change the presentation of information so that they can distinguish between, attend to, and use different elements of information in the game or its interfaces.	Create color blind modes.
	Customize UI elements for different types of vision deficiency.
	Augment text programmatically.
	Customize UI element overlays.
Problem: Players cannot reconfigure presentation and control settings each play session due to the time or effort it takes to do it.	Save custom keybindings between sessions.
Solution: Players can save and retain settings for presentation and controls between play sessions so that they do not have to do configuration every play session.	Save custom presentation settings between sessions.
	Save game startup options to quickly start a new session.
Problem: Players cannot use standard displays and their accompanying settings to take in information from the game.	Set custom visual resolutions and framerates.
Solution: Players can replace a standard display or alter the display settings so that they can take in the information presented by the game or its interfaces.	Customize audio modes for different play settings and devices.
Problem: Players cannot reliably take in and understand information in one or more channels of a game or its interfaces.	Customize Field-of-view settings.
Solution: Players can change the attributes of information in channels so that they can reliably take in and understand it.	Customize the volume of different audio components (ambient, dialogue, music).
	Customize visual noise with high contrast modes (shading).
	Customize visual effects to reduce visual noise (head-bobbing, visual effects, strobing).

Which page(s) / section(s) are affected?

Learning-guide

Does this work have an engineering dependency? What is it?

Some implementations of patterns may have engineering dependencies that need to be identified.

[sptramer]

OK, here's how I'm thinking we might want to structure umbrella tickets like this as they go through triage:

• This is a fairly clear proposal for improvements to the documentation, so those can be placed there.
• But this ticket is also related to uncovering what actions should be taken to support these features and provide this information. This makes it a research task, and anyone who claims it should be responsible for undertaking the research to support it and create action items. If we didn't think there was enough here to tag it for research, it can be converted to a discussion or tagged as needs-more-info.

[FiniteStateGit]

@sptramer Should individual issues be created? The first item is a good example of something that is not immediately actionable, 'Send vibration events to an input device'. Does a single person own the research of an item (filing issues on o3de or o3de-org as required), or the entire list?

I wrote these items as an umbrella ticket to include more context and to get a general determination from the sig before filing so many issues. There is another list of design patterns, less related to input and UI, so this also serves to guide how I should file those issues.