owned this note
owned this note
Published
Linked with GitHub
# Telus PikTv - Accessibility Review <i class="fa fa-universal-access"></i>
## Executive Summary
This report describes the conformance of the Telus.com ([PikTv](https://www.telus.com/en/tv/pik) only) with W3C’s Web Content Accessibility Guidelines (WCAG). The review process is described in **Review Process** below and is based on evaluation described in Accessibility Evaluation Resources.
Based on this evaluation, the Telus.com website **is close to meeting** WCAG 2.1, Conformance Level AA. Detailed review results are available in Section 6 below. Resources for follow-up study are listed in Section 7 below. Feedback on this evaluation is welcome.
## Evaluation Details
Conformance evaluation of web accessibility requires a combination of [semi-automated](https://www.w3.org/WAI/ER/tools/) evaluation tools and manual evaluation by an experienced reviewer. The evaluation results in this report are based on evaluation conducted on the following date(s): 01/04/2019. The website may have changed since that time.
Additional information on the evaluation process is available in [Evaluating Web Sites for Accessibility](https://www.w3.org/WAI/eval/Overview).
|Telus PikTv - Accessibility Review|
---|
|Website reviewed: https://www.telus.com/en/tv/pik|
---
## Review Process
The accessibility is assessed using of the following tools:
|Tool used|description|
|---|---|
Continuum Explorer Community| Browser extension to check for accessibility
Lighthouse (Chrome Accessibility Developer Tools) | Browser extension to check for accessibility
Pa11y CLI | Command line tool for programmatic accessibility reporting
VoiceOver | Screen reader
ChromeVox | Screen reader
NVDA | Screen reader
Keyboard testing: | Navigation and focusable items
---
## Results:
# Home page
(https://www.wcstage.telus.com/en/tv/pik)
###  top level nav
|Violation:|
|---|
|```Provide ways to help users navigate, find content and know where they are.```<br>The **top level navigation menu** appears to AT users as a list of three links and there's no indication that `Shop` is actually expandable (there's no visual clue either).<br>Once the user clicks on `Shop` there's no indication that the sub menu expanded revealing its content.<br>Possible implementation reference: https://www.w3.org/TR/wai-aria-practices/#menu|
|Ui:|
||
---
###  language picker
|Violation:|
|---|
|```Provide ways to help users navigate, find content and know where they are.```<br>The three links to other languages appearing underneath the search box have no description or label. When using a screen reader it is not possible to understand where the links get the user to.<br>Language picker accessibility and possible code implementation is discussed here: http://terrillthompson.com/blog/759|
|There’s also another (duplicate?) language picker component showing EN only on the purple bar.This component presents the same accessibility issues.|
|Ui:|
||
---
###  region picker
|Violation:|
|---|
|```Provide ways to help users navigate, find content and know where they are.```<br>The **Select your region** component has no description or label. When using a screen reader it is not possible to understand where the link gets the user to.<br>The regions list needs to be labelled too to let the user know what the list is about.<br>Guidelines on how to implement such component can be found here: https://www.w3.org/TR/wai-aria-practices/examples/menu-button/menu-button-links.html|
|Ui:|
||
---
###  search box
|Violation|
|---|
|```Provide ways to help users navigate, find content and know where they are.```<br>The **Search Box** component displays the **Quick Links** list as soon as you focus or while typing the keyword. The user can tab through or use key Up / Down to select a link. Using the latter doesn’t move the focus and the selected link is not announced by the screen reader.<br>Guidelines on how to implement such component can be found here: https://www.w3.org/TR/wai-aria-practices/#combobox|
|Also, on **Firefox** (both Win and Mac) this component becomes a ==focus trap==, it is impossible to tab away from it.|
|Ui:|
||
---
###  footnotes
|Violation|
|---|
|The content referenced by footnotes should be easily accessed by clicking the note number. Currently those numbers are not links.<br>Also, the footnote content should provide a link to get the user back to the same point in the document the note was linked to.|
|Ui:|
||
---
###  ~~icon/image in card~~
|Violation|
|---|
|**Decorative images** don’t add information to the content of a page. <br>In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text. Leaving out the alt attribute is also not an option because when it is not provided, some screen readers will announce the file name of the image instead.|
|Ui:|
|Decorative pics are highlighted below:|
||
---
###  ~~KB accessibility on tab menu~~ FIXED
|==Violation <i class="fa fa-exclamation-triangle" aria-hidden="true"></i>== https://www.telus.com/en/tv/pik|
|---|
|```Ensure that all content can be accessed with the keyboard alone.```<br>The tab menu in **Pik TV features** [Stream great content][Two streams, one account][Powered by TELUS Internet] is **not keyboard accessible**.|
|Ui:|
||
:::success
fixed here: https://github.com/telus/telus-site-builder/pull/1738 <i class="fa fa-github" aria-hidden="true"></i> MERGED
:::
---
###  ~~empty H3~~
|Violation|
|---|
|```Error: Heading tag found with no content. Text that is not intended as a heading should not be marked up with heading tags.```<br>WCAG2AA.Principle1.Guideline1_3.1_3_1.H42.2|
|Ui:|
||
:::info
PR in review: https://github.com/telus/telus-site-builder/pull/1750
:::
---
###  ~~empty H4~~
|Violation|
|---|
|```Error: Heading tag found with no content. Text that is not intended as a heading should not be marked up with heading tags.``` WCAG2AA.Principle1.Guideline1_3.1_3_1.H42.2|
|Ui:|
|
:::info
PR in review: https://github.com/telus/telus-site-builder/pull/1750
:::
---
###  meganav
|Violation|
|---|
|All the anchors in **mega_nav** have this issue:<br>```This A has an aria-labelledby attribute value of 'mega_nav_item_object', which includes one or more invalid ids```<br>There is no element with **id** equal to **mega_nav_item_object**|
|Ui:|
|
---
###  ~~outline~~
|Violation|
|---|
```Avoid outline:0 or similar styles on links and other elements that can receive keyboard focus.```<br>The **Terms & conditions** accordion at the bottom of the page doesn't show any outline when focused. It looks like it's a variation of the accordion component used elsewhere in the page that for some reason has no `outline`<br>Also, when collapsed the **accordion content is just not visible** to sighted users but it is still available to ATs |
|Ui:|
||
:::info
PR in review: https://github.com/telus/telus-site-builder/pull/1748
:::
---
###  carousel
|Violation|
|---|
|```Provide ways to help users navigate, find content and know where they are.```<br>The **Channels Carousel** component gives no indications to Assistive Technologies users of what the component is about and how to interact with it.<br>Guidelines for accessible carousels available here: https://www.w3.org/WAI/tutorials/carousels/|
|This list could be presented as a simple list `<ul>...</ul>` of available Tv shows. This would allow AT users to understand where they are and how to navigate the content.<br>Screen readers provide shortcuts to lists and between list items.<br>Screen readers enumerate the items so users know how many are available.<br>The two chevron `<button>` are of no use to AT users and could be removed using `aria-hidden="true"`|
|~~From a UX perpsective the interaction with the carousel feels slow, also it looks like the **carousel doesn't scroll to the last** item but it remains cut off to the right~~<br>This component has been recently refactored, improving the general UX but there're still a few tweaks needed to make it even more accessible and usable|
|Ui:|
||
---
# Eligibility
(https://www.telus.com/en/ab/shop/eligibility)
:::success
No issues were detected. :tada:
:::
---
# Plans
(https://www.telus.com/en/bc/shop/home/pik/plans)
###  ~~page landmarks~~ FIXED
|Violation|
|---|
|All page content must be contained by landmarks<br>Ensure all content is contained within a landmark region, designated with HTML5 landmark elements and/or ARIA landmark regions.<br>Screen reader users can navigate to a section based on its HTML element or ARIA Landmark.|
|Currently only the main content is wrapper in `<main>`, the page is missing the `<header>` and `<footer>` elements|
:::success
fixed here: https://github.com/telus/offer-selection-ui/pull/354 <i class="fa fa-github" aria-hidden="true"></i>
:::
---
###  breadcrumb nav
|Violation|
|---|
|```When ARIA regions, landmarks or HTML5 section elements are provided, users must be able to distinguish them from other regions, landmarks or sections in the page, particularly when two or more instances of the same type are used.```<br>When such an element does not provide a descriptive label to clearly identify itself, users of screen readers may have trouble locating the correct section or understanding its purpose.|
|This applies to the Breadcrumbs and Tab Menu (see screenshots) <br>Example code: |
```html
<div>
<div role="navigation" aria-labelledby="h1a">
... <!-- navigation items here -->
</div>
<h1 id="h1a">Document Training Outline</h1>
...
</div>
```
|Ui:|
|---|
||
||
###  results list
|Violation|
|---|
|Headings communicate the organisation of the content on the page. Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation.<br>The results list should be structured as an unordered list of items `<ul>`, the `x results` text shuold be wrapped in a `<H2>` and this should also be the list label. Finally each card title should be wrapped in a `<H3>` element |
**Current structure:**
<br>
**Suggested structure:**
<br>
:::success
Partially fixed here: https://github.com/telus/offer-selection-ui/pull/253 <i class="fa fa-github" aria-hidden="true"></i>
:::
|Design/UX |
|---|
|Consistency allows all users to predict where to find information and how to use it. This is particularly helpful for users with cognitive impairments, in particular autistic users.|
|The results list shows promo info styled as plan cards. The info card shouldn't be styled as a result card as this way the cognitive load the user has to expend is higher. At first sight we see two cards, even if the label reads "1 Result"|
|Current implementation:|
||
|<br>**A possible alternative**: |
---
###  icons in cards
|Violation|
|---|
|**Decorative images** don’t add information to the content of a page. <br>In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text. Leaving out the alt attribute is also not an option because when it is not provided, some screen readers will announce the file name of the image instead.|
|Ui:|
|Decorative pics (the two icons) are highlighted below:|
||
:::success
Partially fixed here: https://github.com/telus/offer-selection-ui/pull/253 <i class="fa fa-github" aria-hidden="true"></i>
:::
---
# Channels
(https://www.telus.com/en/bc/shop/home/pik/channels)
###  tab menu (:grey_question:)
|Violation|
|---|
|```Tab menu and the dynamic content updates```<br>When content changes dynamically within a web page, it may cause accessibility problems.<br>It is important to notify the user of the new content and set focus or allow the user to jump to the updated content|
|Currently, when the user clicks on one of the tabs **the focus is set back to the beginning of the page**.<br>|
|The problem here is due to the way the page reacts to user interaction. The whole page gets re-rendered on select, causing the clicked menu item to loose the focus.<br>~~Also, as per [Telus's Accessibility Requirements](https://7tr6ks.axshare.com/#g=4&p=pik_tv_plans), **the user should be able to select the tabs using the arrow keys**~~|
|Ui:|
||
:::warning
Outdated fix here: https://github.com/telus/offer-selection-ui/pull/155 <i class="fa fa-github" aria-hidden="true"></i>
:::
---
###  localised offers banner
|==Violation <i class="fa fa-exclamation-triangle" aria-hidden="true"></i>== Focus trap|
|---|
|On **Firefox** (both Win and Mac) keyboard users can't move the focus out of the banner. The banner becomes a focus trap.|
|Ui:|
||
||
---
###  Mobile nav menu
|==Violation <i class="fa fa-exclamation-triangle" aria-hidden="true"></i>==|
|---|
|The drop-down navigation menu replacing the tab-menu and appearing when using a small screen is not KB accessible on ==Windows== systems.<br>The HTML option element listening to the `onchange` event to trigger actions is very inaccessible to keyboard-only users. Most browsers trigger the onchange event on up/down arrow key-press and most users expect to use up and down keys to actually see the available options.<br>The result is that the browser navigates away as soon as the user interacts with the drop-down. |
|Ui:|
||
---
###  filters (old design)
|Violation|
|---|
|The filters drop-down is implemented as a ```<span tabindex="0">``` wrapping a ```<button>```.<br>Because the `tabindex` property is set on the span, the component gets the focus two times and, as a result, the _"Refinement, Find channels by language and category"_ message gets annunced twice.<br>Also, pressing return when focusing on the `<span>` doesn't trigger any action<br>Accessibility can be improved using **aria-expanded** attribute<br>(ref: https://www.w3.org/TR/wai-aria-practices/#accordion)|
|As for the **Tab menu and the dynamic content updates** it would be useful to have the new state announced when the filters gets displayed|
|Ui:|
||
---
###  filters content (old design)
|Violation|
|---|
|The expected behaviour for a form is to trigger submit on Enter key. The checkboxes in the filters panel are within a form but the `Find channels` button is placed outside the form, hence the form is not submitted when hitting the `Enter` key<br>Also, on `Reset` and on `Submit` the page main content gets re-rendered and the focus is set back to the beginning of the page, causing the user to loose context.|
|As per Telus Accessibility requirements, the focus should be put back on the panel toggle button on `Reset`, `Submit` and `Close`.|
|Ui:|
||
:::success
fixed here: https://github.com/telus/offer-selection-ui/pull/206 <i class="fa fa-github" aria-hidden="true"></i>
:::
---
###  filters: new design
|Violation|
|---|
|~~The new implementation presents multiple headings (`Filter by:`, `Filter by Language` and `Filter by Category`) at different heirarchical levels but all coded as `<H4>`; the last two headings should be coded as `<H5>`.~~<br>It would also help ATs users to have this list actually rendered as a `<ul>`, described using `aria-labelledby`, reflecting the drop-down status using `aria-expanded` attribute and pointing to the content panel Id using `aria-controls` attribute|
|The new design has good KB accessibility, the following notes highlight possible areas of improvement|
- The button should have **aria-expanded** set to true/false according to the state
- The drop-down content should be wrapped in a form
- The Form should submit on `Enter`
- The Form should be labelled using aria-label
- On VoiceOver the chekboxes labels are read two times
- ~~Clicking on `Clear` should just untick all the check-boxes, no form submission (currently clicking on `Clear` doesn't do anything unless the user already clicked on`Apply`~~)
- On `Submit` the focus should go back to the drop-down button.
- The `X` button is not actually needed (the user can already click multiple times the drop-down button to toggle the content open/close) except when rendered on smaller viewports as the filter panel becomes a modal dialog. The drop-down should automatically collapse when the focus is moved outside the drop-down itself negating the need for the `X` button. (current implementation collpases the drop-down only when `clicking` outside the drop-down content)
- Mobile version of the filters must be a **modal dialog**, trapping the focus within the dialog itself.
- When one or more filters are applied the `X` button appears in the drop-down button. When moving the focus to it the SR simply reads "button", offering no further clarification:
- On mobile the **filters of checkboxes have no discernible text**.
|Ui:|
|---|
||
:::info
PR in review: https://github.com/telus/offer-selection-ui/pull/450 <i class="fa fa-github" aria-hidden="true"></i>
:::
---
We could reduce the cognitive load by highlighting the `Apply` button a bit more. A common pattern here would be to provide solid background color (green?), or a border, to the `Apply` button, giving more relevance to it and presenting the button as the natural choice for this context.
Proof of concept:
---
###  search channels
|Violation|
|---|
|Buttons must have discernible text:<br>https://dequeuniversity.com/rules/axe/3.2/button-name?application=axe-puppeteer|
|Ui:|
||
---
###  ~~channels card (old design)~~ FIXED
|Violation|
|---|
|```Provide alternative text for images.```<br>In the channels list, the `DIV (role=image)` doesn’t have a mechanism that allows an accessible name value to be calculated.<br>When the ARIA role="img" container is used for a collection of elements, developers must use aria-label or aria-labelledby" reference to assign alternative text -- the alt attribute cannot be used.<br>If the image is only decorative then **there's no need to use a background image on a div**, an `<img alt="">` would be a better option.<br>Also, the technique adopted here is probably not needed (generating custom css rules for each image for each channel) as the CMS is capable of returning bespoke resized/cropped images.<br>Using the `<img>` tag and fetching the resized/cropped image from Contentful will save hundreds (thousands?) css lines generated to achieve the same result.|
|Ui:|
||
:::success
fixed here https://github.com/telus/offer-selection-ui/pull/256 <i class="fa fa-github" aria-hidden="true"></i> MERGED
:::
---
###  channel logo (old design)
|Violation|
|---|
|```Provide ways to help users navigate, find content and know where they are.```<br>The **Channel Logo** in the channel cards is a link to the channels details page, but there's no text/label describing the link <br>Screen reader users have no indication where the link will get them to.<br>**As per Telus Accessibility requirements this element shouldn't be tab-able**.
|Ui:|
|---|
||
---
###  channels card new design
Same feedback expressed for the "old design" applies here.
:::success
Decorative images fixed here https://github.com/telus/offer-selection-ui/pull/256 <i class="fa fa-github" aria-hidden="true"></i>
:::
The new design introduces the `See details` feature.
It is rendered as a `link` but it would make more sense to render it as a `button`.
~~The `See details` label and the chevron icon on its right are **two separate links**, they should be a single element.~~
The `See details >` element is functionally an accordion, it should expose its state using `aria-expanded` attribute and point to the content panel Id using `aria-controls` attr. Also, because links and buttons must make sense out of context, it should have `aria-label` attribute set to provide additional info.
The **`Skip to Panel`** shortcut is available every five cards. The feature itself is not immediately obvious as the user needs to skip four cards and get to the end of the fifth before the link is displayed.
Functionally it doesn't seem to work, on click the focus is moved back to the beginning of the page.
---
~~This new design also introduces the concept of pagination.
It would be useful to show the total number of results i.e.`Showing results 1-30 of 100` at the beginning of the list (this information is actually displayed at the bottom of the list only). Currently it only reads `51 results`.~~ FIXED
Suggested design:
:::success
The suggested desing has been successfully implemented by the catalog team!
:::
---
Hitting the `Load more channels` button triggers the asynchronous load of the remaining channels.
Once the new data is available the focus is not moved to the first of the new items but instead it is moved to the end of the list, skipping all the new content and making it tedious and time consuming for the user to tab back to where she was.
Also, being this an asynchronous action, new data availability should be notified to ATs as soon as it is added to the page.
---
###  recommended channels
|Violation|
|---|
|Proper Use of Buttons and Links|
|The `Show more recommendations` button is coded as a link `<a>` (even though it functionally is a button that triggers some content to show/hide).<br> This can be confusing as buttons can be activated by hitting `Enter` or `Spacebar` while links respond to `Enter` only (hitting the spacebar while the focus is on `Show more recommendations` causes the page to scroll down.<br>Being coded as a link, screen-reader users would expect to navigate to some other page as there is no indication that this component is actually a collapsed accordion that would make some extra content avbailable when expanded.|
|Once the link is activated new content appears in the page but this isn't announced to ATs.<br>The new content is rendered before the `Show more recommendations` link and the focus is not moved to the new content, causing ATs user to easily miss it.<br>KB useres need to `shift+tab` to access the newly rendered content|
|As for the other channel cards in this page, the list of results is coded as a series of `<div>` rather than using `<ul><li>...` and has no label describing it.<br>This reduces the possibility for ATs users to understand and navigate the context they are in.|
|Ui:|
||
|**Button alternative**:|
|
|
---
###  mini cart
|Violation|
|---|
|**View summary** button. This component is implemented as a ```<span tabindex="0">``` wrapping a ```<button>```.<br>Because of the `tabindex` property set on the span, the component gets the focus two times and, as a result, the _"View summary"_ message gets annunced twice.|
|Ui:|
||
|When the mini cart is collapsed its content is still available to ATs users, it's just not visible. Navigating the widget using a screen-reader makes the hidden mini-cart content scroll into view|
|Ui:|
||
|The Summary heading has `tabIndex=0` and `role=presentation`. The latter is not needed while the former should be `tabIndex=-1`. The focus should be set programmatically on expand using JS|
|Ui:|
|
|**Decorative images** don’t add information to the content of a page. <br>In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies|
|Ui:|
||
|The Mini cart widget is essentially a modal dialog and, as such, the user shouldn't be able to interact with the content outside the dialog window. <br>Modal dialogs contain their tab sequence. That is, `Tab` and `Shift + Tab` do not move focus outside the dialog.<br>The current implementation **doesn't prevent** `Shift + Tab` from navigating outside the dialog content. Actually `Shift + Tab` behaves like `Tab` does, as it moves the focus to the next element rather then the previous one.<br>Also, ATs don't perceive the mini car as a modal dialog and allow users to enter/leave the mini cart freely.|
|Ui:|
||
|Another example of the virtual cursor being able to focus on (and scroll into view) content not properly hidden to ATs:|
||
<br>
---
### General considerations over the channels page
This page presents a long list of items (**channel cards**).<br>Whenever the user selects a channel **the focus is moved back to the beginning of the page**, making it extremely time consuming to select multiple channels, expecially if the desired channels are located towards the end of the list.<br>~~Also, there is no obvious way to skip all the content and reach the **Mini Cart** sitting at the bottom of the page~~.<br>
The long cards list could be presented as an Unordered List `<ul>...</ul>` so to allow users to understand where they are and skip the content if needed.<br>The list heading `X Results` shuld be a H2. Headings communicate the organisation of the content on the page. Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation.
:::success
Partially fixed here https://github.com/telus/offer-selection-ui/pull/161 <i class="fa fa-github" aria-hidden="true"></i>
:::
###  Nice to have ###
Once a channel is selected it would be helpful to have some sort of **feedback confirming the channel has been added/removed** and a quick link to **skip the remaining content and get to the mini cart**.
Possible design for a quick link to the mini cart:
When moving the focus to a card the Cart button appears on the bottom left corner of card itself, showing the number of items already added.
On focus the screen reader says "You have x items in your cart: skip to cart!"
<br>
Proof of concept in this video:
[](https://youtu.be/p73idcsuEGU)
I.e: When an item is added/removed the screen reader announces it saying "Item added/removed to your cart".
---
# Addons
(https://www.telus.com/en/bc/shop/addons)
:::success
No issues were detected. :tada:
:::
---
# Plan Pdp
(https://www.telus.com/en/bc/shop/home/product/prime-time-and-my-5-tvx)
###  images in card
|Violation|
|---|
|**Decorative images** don’t add information to the content of a page. <br>In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text. Leaving out the alt attribute is also not an option because when it is not provided, some screen readers will announce the file name of the image instead.|
|Ui:|
|Decorative pics highlighted below:|
||
||
---
###  popular channels
|==Violation <i class="fa fa-exclamation-triangle" aria-hidden="true"></i>==|
|---|
|The list of popular channels is coded as a series of `<img>` with a click event handler attached to it. This makes the content **not accessible by KB users**|
|Ui:|
||
---
# Channels Pdp
(https://www.telus.com/en/bc/shop/home/product/a-e-tvx)
###  images/icons in card
|Violation|
|---|
|**Decorative images** don’t add information to the content of a page. <br>In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text. Leaving out the alt attribute is also not an option because when it is not provided, some screen readers will announce the file name of the image instead.|
|Ui:|
|Decorative pics highlighted below:|
||
||
---
# Mobile
Mobile devices are becoming ubiquitous in our society. A 2016 Pew Research Center survey1 of adults with disabilities found that 70% of those under the age of 65 are using smartphones, and 44% of them have tablets. One in four adults and seniors with disabilities have a computer, a smartphone and a tablet. According to a survey by the non-profit WebAIM2 (Web Accessibility In Mind), about 70% of people with vision disabilities who use screen readers are using this technology on a mobile device.[(1)](https://www.essentialaccessibility.com/blog/mobile-accessibility/)
###  Burger menu
|Violation|
|---|
|The burger menu content is not scrollable when on Lanscape mode and the content in the lower end is cut out.<br>Also, this component is functionally a **modal dialog** and, as such, the user shouldn't be able to interact with the content outside the dialog window.<br>Currently it is possible to access the content underneath the menu using ATs or an external KB.|
|Ui:|
||
|Incorrect labelling for the back button(highlighted): it is announced as "Pik tv, click to activate"|
||
|Each sub level should be a modal dialog|
<br>
---
# Telus Accessibility requirements
- https://7tr6ks.axshare.com/#g=1&p=preselecting_pik_tv_plan_flow
- https://7tr6ks.axshare.com/#g=1&p=pik_tv_plans
- https://7tr6ks.axshare.com/#g=1&p=pik_tv_channels
- https://7tr6ks.axshare.com/#g=1&p=pik_tv_channels_filter_menu
- https://7tr6ks.axshare.com/#g=1&p=pik_tv_add-ons
## Accessibility requirements considerations
When defining the requirements for an accessible UI we need to keep in mind the distinction between keyboard users and Assistive Technologies users.
The base requirement for accessible web content is to make sure the page is completely keyboard-accessible.
A keyboard user typically uses the `Tab` key to navigate through interactive elements on a web page: links, buttons, fields for inputting text, etc.
When an item has keyboard "focus", it can be activated or manipulated with the keyboard.
Screen reader users, on the other hand, have the ability to navigate or jump to different sections of the page using other keys (or key combinations) then just the `Tab` key.
I.e. screen readers provide shortcuts to sections, headers, links, lists ... and between list items.
Making "tabable" (setting `tabindex=0`) some elements that normally wouldn't receive focus can produce unintuitive/annoying ui behaviours, resulting in a sub-optimal UX for both AT users and KB users.
---
# Tab-Menu considerations
PikTv currently has two distinct components that visually render the **Tab-Menu**; one is used uniquely in [PicTv home page](https://www.telus.com/en/tv/pik) while the other one is in other pages, i.e. [Plans](https://www.telus.com/en/bc/shop/home/pik/plans).
**The Tab-Menu implemented in the home is not keyboard accessible and needs to be refactored.**
Despite having the same graphical layout the two tab-menus are different in the function they accomplish.
The first one is properly a tab-menu since it shows/hides content already present in the page while the second one is more a navigation menu as it updates the URL and renders a new page.
Also Tab-Menus can usually be navigated using the arrow keys. This way the user can move the focus to the desired tab and the tab content gets displayed immediately.
The Navigation-Menu can't offer the same sort of UX as a new page would be rendered when the tab is selected.<br>++For this reason the suggested UX is to wait for the user to actually hit `enter` after he/she selects the desired tab using arrow keys.++
<br>
---
# Outline for focused elements
On browsers other than Chrome (or Chromium-based browsers like Opera or Brave) the default focus style is insufficient to effectively highlight the selected element. In WCAG 2.1, focus indicators are bound to the same contrast rules as other parts of the content, as per [1.4.11: Non-text contrast](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.1&showtechniques=324%2C331#non-text-contrast). This means a contrast of 3:1 between the outlines and their background is required.
<br>
Example: Firefox on Osx, `See details` button highlighted
---
# Main content re-render issue
While performing the accessibility tests a pattern emerged as source of some **performance/UX/A11y** **issues** and it is basically related to how the state is accessed by different components / sections of the app.
Part of the app state is reflected in the URL, i.e :
- refinements[nameContains]
- refinements[Language]
- refinements[Category]
- showMoreRecommendations
- ...
This is a common pattern and allows for bookmarking the application at a given state.
However this can cause the main content to re-render whenever the state/url changes with little to no optimisation.
This means that in cases like the `Show More Recommendations`, where we just need to add / remove a few cards, the browser re-renders the main content and the focus is set back to the beginning of the page.
Apart from the impact on performances (slower UX as the browser re-renders a lot of content that didn’t change) this also poses some issues in terms of accessibility as **the user loses the context of where s/he is**.
In most cases we can prevent this by using the `shouldComponentUpdate` callback, together with a correct use of the Redux state management.
I.e.
When the user performs an action altering the URL, the `ProductCatalog` component should check whether the `pathname` has changed.
If the pathname is the same (as it is when adding/removing filters or showing more or less recommendations) then its `shouldComponentUpdate` function should return false.
Since the updated URL is set in the Router object (available in the state object handled by Redux) the components that depend on that specific part of the state should react to the new state by re-rendering itself.
The main issue here is that some components access the **`router.location`** prop directly and then they parse it to extract the values they need, relying on the full re-render the get updated values, rather than accessing the state through the props provided by the `mapStateToProps` function (Redux).
<br>
---
# References
[Web Content Accessibility Guidelines (WCAG) Overview](https://www.w3.org/WAI/intro/wcag)
[Web Content Accessibility Guidelines 2.1](https://www.w3.org/TR/WCAG21/)
[Techniques for WCAG 2.1](https://www.w3.org/WAI/WCAG21/Techniques/)
[Accessibility Evaluation Resources](http://www.w3.org/WAI/eval/)
[Web Accessibility Evaluation Tools List](https://www.w3.org/WAI/ER/tools/)
[Using Combined Expertise to Evaluate Web Accessibility](https://www.w3.org/WAI/eval/reviewteams)
Google Drive
Gist
Clipboard
Sign in with Wallet
