| Target release | |
|---|---|
| Epic | |
| Document Status | DRAFT |
| Product | |
| Interaction Design | |
| Visual Design | |
| Development | |
| EIA | |
| QA | |
| PMO |
Goals
Tasks
Background and strategic fit
Assumptions
Requirements
| # | Feature Title | User Story Description | Importance | Notes |
|---|---|---|---|---|
| 1 | ||||
| 2 |
User Research
User Experience Design
Goals
Tasks
Background and strategic fit
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 |
|
|||
| 2 |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
Not Doing
Research
From Vincent: https://www.raywenderlich.com/142058/ios-accessibility-tutorial
Each component and element should be built following the Web Content Accessibility Guidelines (WCAG) and met the AA standard. Our patterns are perceivable, operable, and understandable to users, even when using a screen reader or other assistive technology.
Keyboard accessibility
Keyboard accessibility is important for users who rely on or prefer using a keyboard. Encourage accessibility by providing keyboard functionality to all available content. Common keyboard interactions include using the Tab key to select different interactive elements on a page and using the Enter key or the Spacebar to activate an in-focus element.
Focus indicators
The tab key navigates through various interactive elements on a page. A default visual indicator is provided. On Web, the display is an outlined border around the focused element. When an element is in focus, it can be further activated using the keyboard.
Navigation order
The order in which interactive elements receive focus is logical and predictable. Create the tab flow hierarchy by using the source code to arrange the keyboard navigation. Begin with the header, followed by the main navigation, then page navigation (from left to right, top to bottom), and end with the footer.
Use natively-accessible elements in navigation to activate links, buttons, and form controls with a keyboard. Reinforce semantic HTML to convey intent and meaning instead of simply defining the look and feel of an element. Enhance with ARIA (Accessible Rich Internet Application) labels when necessary. For additional customization, use tabindex=“0” to ensure a navigable element receives a focus indicator.
Provide a “Skip to content” option when there is lengthy navigation so a user may access main content faster. This option is a link that is visually hidden by default and appears when it receives keyboard focus via the tab key.
WebAIM recommends the following to enable a “Skip to content” link.
<body>
<a href="#maincontent">Skip to main content</a>
...
<main id="maincontent>
<h1>Heading</h1>
<p>This is the first paragraph</p>
</main>
</body>
Color accessibility
Please refer to our usage section on the Colors page to learn more about color contrast ratios. You can also use this color contrast tool to ensure your ratios pass WCAG AA standards.
Web Content Accessibility Guidelines
WCAG version 2.0 is the industry standard. The Web Content Accessibility Guidelines (WCAG) are published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).
- Read the (WCAG) 2.0 guidelines
- Official WCAG 2.0 reference/checklist
- A customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2.0 requirements (success criteria) and techniques.
- International accessibility laws and standards
- Other checklists:
- The Future of WCAG
Goals
Tasks
Background and strategic fit
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 |
|
|||
| 2 |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
Not Doing
Research
Mobile Design
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
iOS
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Android
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Web Design
Small
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Medium
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Large
Flows
| Description | User Story I | User Story II | User Story III |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Tablet Design
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
iOS
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Android
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
TV Design
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
tvOS
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Roku
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
FireTV
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Android TV
Flows
| Description | User Story 1 | User Story 2 | User Story 3 |
|---|---|---|---|
Sketches |
|||
Wires |
|
|
|
Comps |
Analytics
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
Not Doing
Usability