| Target release | |
|---|---|
| Epic | |
| Document Status | DRAFT |
| Product | |
| Interaction Design | |
| Visual Design | |
| Development | |
| EIA | |
| QA | Omar Aziz |
| PMO | Nareg Burr |
Goals
- A best in class accessible experience for DisneyNOW children and users.
Tasks
- Collect Accessibility resources
- Setup brown bag
Background and strategic fit
- Apple Accessibility for Developers https://developer.apple.com/accessibility/
- Apple Accessibility Documentation https://developer.apple.com/documentation/uikit/accessibility/
Assumptions
Requirements
| # | Feature Title | User Story Description | Importance | Notes |
|---|---|---|---|---|
| 1 | ||||
| 2 |
User Research
User Experience Design
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
| 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
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
| 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
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
| 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
Useful Links:
Designing for Accessibility and Inclusion - https://www.smashingmagazine.com/2018/04/designing-accessibility-inclusion/
Principles for Accessible Design - http://ncdae.org/resources/factsheets/principles.php
Universal vs. Accessible Design - https://www.washington.edu/doit/what-difference-between-accessible-usable-and-universal-design
What is Accessibility?
Accessibility involves two key issues: how users with disabilities access electronic information and how web content designers and developers enable web pages to function with assistive devices used by individuals with disabilities.
For instance, a website is accessible if all people, including disabled and elderly people, can use it.
Why is it important to us?
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
The more inclusive the application is, the broader the reach. Why exclude a segment of the population? While it might not always be easy, you might discover that improving the accessibility of your site can improve the experience for all users.
Accessibility is the right thing to do- It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with diverse abilities.
Benefits all users-
Uses innovative technology
Creates market opportunity
19.6% of the U.S. population as having some sort of disability. Within that group are individuals with visual, hearing, cognitive, and motor impairments.
Who else does accessibility benefit?
people using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.
older people with changing abilities due to ageing
people with “temporary disabilities” such as a broken arm or lost glasses
people with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio
people using a slow Internet connection, or who have limited or expensive bandwidth
Accessibility overlaps with other best practices such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimization (SEO). Accessible websites can have better search results, reduced maintenance costs, increased audience reach, and demonstrate corporate social responsibility (CSR).
- Intro/Facts
- Why have an accessibility review?
- It's the law.
- We want our content and services to reach the widest possible audience.
- Accessible websites provide a better experience for all users regardless of ability.
- 15-20% of the population has some form of disability
- Standards
- Title III of The Americans with Disabilities Act (ADA)
- Requires businesses to provide public accommodations for the disabled.
- Language expanded to include digital accommodations and emerging technologies.
- Section 508 of the Rehabilitation Act of 1973 (508)
- Required for Government agency websites
- Also private companies with government contracts
- Specific to the U.S.
- Required for Government agency websites
- WCAG 2.0 (Web Content Accessibility Guidelines)
- Specific to Web Content only, not User agents (UAAG) or Authoring Tools (ATAG)
- Used by ADA to measure compliance with Title III
- Accepted Internationally
- WCAG 2.1 (2018) will expand the types of disabilities and technologies
- low vision, learning disabilities, speech disabilities and multiple disabilities
- small screens, touch screens and other features common to mobile devices and tablets
- WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications)
- A set of standards and best practices for making dynamic content, custom UI components, and Web apps accessible
- Title III of The Americans with Disabilities Act (ADA)
- Why have an accessibility review?
- Succes Criteria
- The Good News: 90% of accessibility comes with good development practices
- Web standards like HTML and User Agents (ie. browsers) have accessibility built in
- Platforms and libraries, like Wordpress and Bootstrap, have standards built in.
- The Bad News: A high accessibility score does not mean your site is fully accessible
- As of yet, no tool can perform a completely automated assessment on the WCAG 2.0 guidelines.
- Automated tests check for standards and best practices, but only a human can verify that a web page is accessible.
- Non-standard or unconventional design specifications can introduce accessibility issues
- The Good News: 90% of accessibility comes with good development practices
- Testing Scope
- Web Standards and practices (automated test)
- Unique Templates and components such as forms and navigation
- Use Cases
- Can the user get to your site?
- Can the user navigate within your site?
- Can the user complete a task or goal (ex, buy something or get information) and get notification upon success?
- In the event of failure or error, can the user fix the error/failure?
- Typical timeframe
- Requesting a review
- Intake Process
- summary of steps taken by our team to review a site and the expected output.
Open Qs
- Currently, UX opens JIRA tickets
- Standard JIRA issue template is used
- Review findings are delivered as a spreadsheet file
- Issues are tagged with the person responsible for remediation. (Dev, Content Creator, etc.)
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 |
|---|---|