| A | B | C | D | E | G | H | I | J | K | L | M | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Updated Ticket | ID | 2594 | Device | Browser/App | Your Name | Country | OS | Browser Version | uTest Test Case URL | Outcome | Tester & TTL Comments | |
2 | WWW-2579 | [Bug][PC React Desktop] Custom Dropdown/Select Component is not Keyboard Navigable *Scenario:* Birth Year options must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is attempting to register *When* the user is attempting to select their birth year. *Then* the birth year options menu should allow keyboard access to all information and functionality that is available to mouse users. {panel} h2. +Current Behavior:+ * User cannot select a value from the "Birth Year" custom drop down component using only the keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all menu content and functionality entirely through use of the keyboard. * The above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functionality. | Windows | PC App | Deepa Anandan | United States (US) | Windows 10 | Pluto Desktop app | https://platform.utest.com/testcycles/303760/testcases/5010732 | Issue is Fixed | |||
3 | WWW-2579 | [Bug][PC React Desktop] Custom Dropdown/Select Component is not Keyboard Navigable *Scenario:* Birth Year options must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is attempting to register *When* the user is attempting to select their birth year. *Then* the birth year options menu should allow keyboard access to all information and functionality that is available to mouse users. {panel} h2. +Current Behavior:+ * User cannot select a value from the "Birth Year" custom drop down component using only the keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all menu content and functionality entirely through use of the keyboard. * The above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functionality. | Windows | PC App | Priya Vinoth | United States (US) | Windows 10 | Version 88.0.4324.150 (Official Build) | https://platform.utest.com/testcycles/303760/testcases/5010889 | Issue is Fixed | |||
4 | WWW-2580 | [Bug][PC React Desktop] On Demand Shortcut Navigation Experience is Broken for Keyboard/Screen Reader Users h2. Current Behavior: Navigation To the left of Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/Screen Reader users. Activating menu items scrolls page to incorrect (the desired option scrolls Just above the viewable area of the screen. Upon attempting to advance through rest of the menu (a laborious task due to number of menu items) appears to get stuck on the 2nd to last genre in the list upon repeatedly attempting to advance further (when the interface appears stuck), keyboard focus eventually appears to bypass the available titles entirely. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | PC App | Seth Taylor | United States (US) | Windows 10 | PC App | https://platform.utest.com/testcycles/303760/testcases/5012530 | Issue is Fixed | While narrator/screen reader is on, keyboard controls properly scroll through list of genres and keyboard focus moves to the menu item that was active. Using keyboard controls is still laborious due to number of menu items. | ||
5 | WWW-2580 | [Bug][PC React Desktop] On Demand Shortcut Navigation Experience is Broken for Keyboard/Screen Reader Users h2. Current Behavior: Navigation To the left of Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/Screen Reader users. Activating menu items scrolls page to incorrect (the desired option scrolls Just above the viewable area of the screen. Upon attempting to advance through rest of the menu (a laborious task due to number of menu items) appears to get stuck on the 2nd to last genre in the list upon repeatedly attempting to advance further (when the interface appears stuck), keyboard focus eventually appears to bypass the available titles entirely. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | PC App | Yauhen Pyzhyk | United States (US) | WIndows 10 | N/A | https://platform.utest.com/testcycles/303760/testcases/5014899 | Bug can still be reproduced | |||
6 | WWW-2581 | [Bug][PC React Desktop] Closed Captions Setting Menu is entirely unavailable to keyboard control once opened h2. +Current Behavior:+ * Closed Captions Settings Menu Can be opened via keyboard, but its content is completely unavailable to keyboard users. h2. +Expected Behavior:+ * User should be able to access, navigate and control all menu content and functionality entirely through use of the keyboard. * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functionality. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* Closed Caption options must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching TV programming *When* the user is attempting to modify CC options. *Then* the CC options menu should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | PC App | Seth Taylor | United States (US) | Windows 10 | Chrome, Version 88.0.4324.146 | https://platform.utest.com/testcycles/303760/testcases/5010573 | Blocked (add note) | No video will play on provided web url. Both Live TV and On Demand video does not play. Play button does not function. Closed caption button does not function. | ||
7 | WWW-2581 | [Bug][PC React Desktop] Closed Captions Setting Menu is entirely unavailable to keyboard control once opened h2. +Current Behavior:+ * Closed Captions Settings Menu Can be opened via keyboard, but its content is completely unavailable to keyboard users. h2. +Expected Behavior:+ * User should be able to access, navigate and control all menu content and functionality entirely through use of the keyboard. * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functionality. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* Closed Caption options must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching TV programming *When* the user is attempting to modify CC options. *Then* the CC options menu should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | PC App | Deepa Anandan | United States (US) | Windows 10 | Pluto Desktop app | https://platform.utest.com/testcycles/303760/testcases/5010570 | Issue is Fixed | |||
8 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Mac | Chrome Browser | Yauhen Pyzhyk | United States (US) | macOS 10.15.6 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5013610 | Issue is Fixed | |||
9 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Mac | Chrome Browser | Deepa Anandan | United States (US) | MacOS Catalina 10.15.5 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010780 | Issue is Fixed | |||
10 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Mac | Safari browser | Deepa Anandan | United States (US) | MacOS Catalina 10.15.5 | Safari 13.1.1 | https://platform.utest.com/testcycles/303760/testcases/5010802 | Blocked (add note) | Tab does not work in Safari browser | ||
11 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Mac | Safari browser | Yauhen Pyzhyk | United States (US) | macOS 10.15.6 | Safari 14.0 | https://platform.utest.com/testcycles/303760/testcases/5013616 | Issue is Fixed | |||
12 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Mac | Firefox browser | Yauhen Pyzhyk | United States (US) | macOS 10.15.6 | FF 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5013621 | Issue is Fixed | |||
13 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Mac | Firefox browser | Deepa Anandan | United States (US) | MacOS Catalina 10.15.5 | Firefox 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010811 | Issue is Fixed | |||
14 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | Chrome Browser | Yauhen Pyzhyk | United States (US) | Windows 10 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010715 | Issue is Fixed | |||
15 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | WIndows | Chrome Browser | Sharmila Viyyuru | United States (US) | Win 10 | Chrome Version 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010580 | Issue is Fixed | |||
16 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | Edge browser | Yauhen Pyzhyk | United States (US) | Windows 10 | Edge 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5010699 | Issue is Fixed | |||
17 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | Edge browser | Harikrishna Pentala | United States (US) | Windows 10 | Edge 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5010765 | Issue is Fixed | |||
18 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | Firefox browser | Yauhen Pyzhyk | United States (US) | Windows 10 | FF 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010606 | Issue is Fixed | |||
19 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | Firefox browser | Deepa Anandan | United States (US) | Windows 10 | Firefox 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010767 | Issue is Fixed | |||
20 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Xbox One | Edge browser | Volodymyr Sazhyn | United States (US) | 10.0.19041.6287 | Edge 44.19041.5663.0 | https://platform.utest.com/testcycles/303760/testcases/5017354 | Blocked (add note) | Tested on Xbox Series S (model 1883) Blocked. Black screen is displayed on Edge Xbox for test url even in dev mode: https://new-arch.app-web.plutostaging.tv/ It works on desktop, but not on Xbox pluto.tv works as expected. | ||
21 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Xbox One | Edge browser | United States (US) | Please enter OS | Please enter browser, with version | Please enter | |||||
22 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | PC App | Yauhen Pyzhyk | United States (US) | Windows 10 | N/A | https://platform.utest.com/testcycles/303760/testcases/5014686 | Bug can still be reproduced | |||
23 | WWW-2582 | [Bug][PC & Xbox Browsers - Multiple] Mute Button has extraneous tab stops * PC Browser - Chrome * MS Edge (Default browser) on XBox One X 1TB (CYV-00001) h2. +Current Behavior:+ * Mute Button has excessive tab stops which results in a confusing keyboard navigation experience that cannot be visually tracked. h2. +Expected Behavior:+ * Mute button should have only one tab stop * Mute button should retain focus as user toggles its state * When user forward tabs from Mute button focus should always go directly to “CC†button. h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario:* *_User using embedded video controls should have a keyboard navigation experience that is consistent and logical._* *Given* Given user is watching Live TV programming *When* the user is keyboard navigating the embedded video player controls. *Then* the tab order should follow the logical arrangement of the screen and should progress up to down left to right without exceptions or extraneous keystops. {panel} | Windows | PC App | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
24 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Mac | Chrome Browser | Deepa Anandan | United States (US) | MacOS Catalina 10.15.5 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010891 | Bug can still be reproduced | |||
25 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Mac | Chrome Browser | Jasmine Sureddi | United States (US) | MacOS Catalina 10.15.5 | Chrome 88.0.4324.150 | Please enter | ||||
26 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Mac | Safari browser | Please enter your name | United States (US) | Please enter OS | Chrome 88.0.4324.150 | Please enter | ||||
27 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Mac | Safari browser | Deepa Anandan | United States (US) | macOS Catalina 10.15.5 | Safari 13.1.1 | https://platform.utest.com/testcycles/303760/testcases/5010905 | Blocked (add note) | Tab does not work in Safari browser | ||
28 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Mac | Firefox browser | Deepa Anandan | United States (US) | macOS Catalina 10.15.5 | Firefox 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010915 | Bug can still be reproduced | |||
29 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Mac | Firefox browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
30 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | Chrome Browser | Divya Gowda | United States (US) | Windows 10 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010856 | Bug can still be reproduced | |||
31 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | Chrome Browser | Yauhen Pyzhyk | United States (US) | Windows 10 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010875 | Bug can still be reproduced | |||
32 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | Edge browser | Yauhen Pyzhyk | United States (US) | Windows 10 | Edge 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5010897 | Bug can still be reproduced | |||
33 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | Edge browser | Deepa Anandan | United States (US) | Windows 10 | Edge 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5011026 | Bug can still be reproduced | |||
34 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | Firefox browser | Yauhen Pyzhyk | United States (US) | Windows 10 | FF 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010850 | Bug can still be reproduced | |||
35 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | Firefox browser | Deepa Anandan | United States (US) | Windows 10 | Firefox 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010924 | Bug can still be reproduced | |||
36 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | PC App | Priya Vinoth | United States (US) | Windows 10 | Version 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010911 | Bug can still be reproduced | |||
37 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Windows | PC App | Deepa Anandan | United States (US) | Windows 10 | PC App | https://platform.utest.com/testcycles/303760/testcases/5010948 | Bug can still be reproduced | |||
38 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Xbox One | Edge browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
39 | WWW-2583 | [Bug][PC, Mac & Xbox Browsers - Multiple] Live TV Guide Is not Keyboard Navigable h2. +Current Behavior:+ * Guide is entirely unnavigable via keyboard h2. +Expected Behavior:+ * User should be able to access, navigate and control all guide content and functionality entirely through use of the keyboard. * Guide should communicate current method of sorting, relationships individual programs have with the current time slot and the channel to which they belong. Users should understand they are browsing a grid of available programming. * Users need access to “next show†information that is visually available but not available via Screen Reader * All of the above functionality should provide adequate context to screen users to make the interface understandable to non-visual users. This can not be adequately tested without baseline keyboard functality. h2. +Acceptance Criteria+ *Scenario:* Live programming guide must be adequately controllable via keyboard without any use of a mouse or other pointing device. *Given* Given user is watching Live TV programming *When* the user is attempting to browse available TV programming. *Then* the programming guide should allow keyboard access to all information and functionality that is available to mouse users. {panel} | Xbox One | Edge browser | Volodymyr Sazhyn | United States (US) | 10.0.19041.6287 | Edge 44.19041.5663.0 | https://platform.utest.com/testcycles/303760/testcases/5018218 | Bug can still be reproduced | Tested on Xbox Series S (model 1883) on pluto.tv User is not able to access, navigate and control ALL guide content and functionality entirely through use of the keyboard. Unable to see content detailed page with keyboard. | ||
40 | WWW-2584 | [Bug] PC React Desktop On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. {panel} | Windows | PC App | Roopa Ravichettu | United States (US) | Windows 10 | N/A | https://platform.utest.com/testcycles/303760/testcases/5017281 | Bug can still be reproduced | |||
41 | WWW-2584 | [Bug] PC React Desktop On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. {panel} | Windows | PC App | Yauhen Pyzhyk | United States (US) | Windows 10 | N/A | https://platform.utest.com/testcycles/303760/testcases/5014903 | Bug can still be reproduced | |||
42 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Mac | Chrome Browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
43 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Mac | Chrome Browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
44 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Mac | Safari browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
45 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Mac | Safari browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
46 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Mac | Firefox browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
47 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Mac | Firefox browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
48 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | Chrome Browser | Yauhen Pyzhyk | United States (US) | Windows 10 | Chrome 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5010788 | Bug can still be reproduced | |||
49 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | Chrome Browser | Harikrishna Pentala | United States (US) | Windows 10 | Chrome Version 88.0.4324.150 (Official Build) (64-bit) | https://platform.utest.com/testcycles/303760/testcases/5011072 | Bug can still be reproduced | |||
50 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | Edge browser | Yauhen Pyzhyk | United States (US) | Windows 10 | Edge 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5010812 | Bug can still be reproduced | |||
51 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | Edge browser | Harikrishna Pentala | United States (US) | Windows 10 | Edge 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5012296 | Bug can still be reproduced | |||
52 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | Firefox browser | Yauhen Pyzhyk | United States (US) | Windows 10 | FF 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5010824 | Bug can still be reproduced | |||
53 | WWW-2593 | [Bug][Multiple Devices] On Demand Main Menu Navigation Experience is Broken for Keyboard/VoiceOver Users h2. Current Behavior: Navigation above Titles on On Demand Main Menu Page expected to act as a means to more efficiently navigate screen. This is not true for Keyboard/VoiceOver users. Activating menu items scrolls page to desired point but upon attempting to advance through rest of the menu (a laborious task due to number of menu items) once user leaves the menu the page scrolls back to the top of the screen and takes the users to the first section on the page. h2. Expected Behavior: After activating a category item in the category menu, the keyboard focus is moved to the area of the screen that corresponds to the menu item that was activated (in addition to the screen scrolling to that section). h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Keyboard/VoiceOver User access titles within a specific section of the page using the Category navigation to take them there* *Given* user is on the ON Demand Main Menu Screen AND VoiceOver is on *When* user to access a movie within a specific section of the page and wants to use the category navigation to get there *Then* The user is able to jump directly from the navigation category they selected to the corresponding section of the screen. | Windows | Firefox browser | Roopa Ravichettu | United States (US) | Windows 10 | Version 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5017408 | Bug can still be reproduced | |||
54 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Mac | Chrome Browser | United States (US) | Please enter OS | Please enter browser, with version | Please enter | |||||
55 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Mac | Chrome Browser | Volodymyr Sazhyn | United States (US) | mac OS Catalina 10.15.7 | Chrome 84.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5018907 | Bug can still be reproduced | Users currently have no way of skipping over large blocks of VOD. | ||
56 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Mac | Safari browser | Volodymyr Sazhyn | United States (US) | mac OS Catalina 10.15.7 | Safari 14.0 | https://platform.utest.com/testcycles/303760/testcases/5018277 | Bug can still be reproduced | Users currently have no way of skipping over large blocks of VOD. | ||
57 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Mac | Safari browser | Please enter your name | United States (US) | Please enter OS | Please enter browser, with version | Please enter | ||||
58 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Mac | Firefox browser | Volodymyr Sazhyn | United States (US) | mac OS Catalina 10.15.7 | Firerfox 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5018926 | Bug can still be reproduced | Users currently have no way of skipping over large blocks of VOD. | ||
59 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Mac | Firefox browser | Please enter your name | United States (US) | 14 | 14.4 | Please enter | ||||
60 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Windows | Chrome Browser | Roopa Ravichettu | United States (US) | Windows 10 | Chrome Version 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5016998 | Bug can still be reproduced | |||
61 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Windows | Chrome Browser | Abigail Turner | United States (US) | Windows 10 | Chrome Version 88.0.4324.150 | https://platform.utest.com/testcycles/303760/testcases/5014349 | Bug can still be reproduced | |||
62 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Windows | Edge browser | Volodymyr Sazhyn | United States (US) | Windows 10 Home 20H2 | Microsoft Edge Version 88.0.705.68 | https://platform.utest.com/testcycles/303760/testcases/5017641 | Bug can still be reproduced | Users currently have no way of skipping over large blocks of VOD. | ||
63 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Windows | Edge browser | Roopa Ravichettu | United States (US) | Windows 10 | Microsoft Edge Version Version 88.0.705.68 | Bug can still be reproduced | ||||
64 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Windows | Firefox browser | Diane Retson | United States (US) | Windows 10 | Firefox 85.0 | https://platform.utest.com/testcycles/303760/testcases/5016089 | Bug can still be reproduced | In the sample I observed, user cannot select a genre, such as "Entertainment," and then navigate to the list of Entertainment shows. | ||
65 | WWW-2594 | [Bug][PC Browser - Multiple][Global Elements] Interface lacks bypass blocks to bypass repeated content/navigation h2. Current Behavior: Users currently have no way of skipping over large blocks of common / global content or navigation and skip directly to info they wish to access. Current use of land-mark regions uses two MAIN regions which is invalid. h2. Expected Behavior: Interfaces must have one or more of the following: * The main content of the site/system wrapped in an HTML element designated as a main landmark w/ a link leading (same page anchor) to that element. * Containing all content within clearly/consistently defined landmarks that describe their purpose The resulting Landmark Region implementation should replicate the following (see attached screenshot under screen recordings): * Banner ** Nav (hamburger menu) ** Nav (live TV / VOD) * Main ** Section (video player) ** Section (live programming guide) h2. +Acceptance Criteria+ {panel:bgColor=#deebff} *Scenario: Screen Reader Users need immediate / obvious access to all content or navigation* *Given* the user is access the application *When* user is attempting to access information or controls in a different part of the screen *Then* shortcuts need to be available to allow the user to quickly jump from one part of the screen to another. | Windows | Firefox browser | Volodymyr Sazhyn | United States (US) | Windows 10 Home 20H2 | Firefox 85.0.2 | https://platform.utest.com/testcycles/303760/testcases/5017668 | Bug can still be reproduced | Users currently have no way of skipping over large blocks of VOD. |