TELUS’ core principle is customer first. This means delivering an accessible digital experience regardless of a customer’s abilities, device quality or screen size. Our guidelines are in place to ensure that we not only meet legal requirements but also to allow our digital experiences to be seamlessly viewed through assistive technology.
TELUS and their vendors are committed to meeting or exceeding the Web Content Accessibility Guidelines 2.0, level AA (WCAG 2.0 AA). Accessibility is a legal requirement, mandated by the Accessibility for Ontarians with Disabilities Act (AODA) and Canadian Radio-Television and Telecommunications Commission (CRTC).
Responsibilities by role
Accessibility is at the core of TELUS’ product development process and everyone has a responsibility in creating world class experiences that are easily accessible to our customers. To give you a better idea of what these roles could potentially mean, we’ve highlighted a few key areas.
Some TELUS customers interact with the brand through Assistive Technology used by people with disabilities to accomplish tasks online.
Assistive technology used to interact with digital content includes:
Screen magnification software
Speech input software
Alternative input devices
Motion tracking or eye tracking
Single switch entry devices
Learn more about other assistive technology from Berkeley Web Access.
Keyboard accessibility is vital to an accessible digital experience. Customers with motor and visual disabilities rely on a keyboard to navigate the TELUS website. Users might utilize modified keyboards or other hardware that mimics the functionality of a keyboard.
Keyboard users must know where they are on the page. Designers need to make it easy to show where the keyboard focus is on. Elements with keyboard focus must have a visible focus style that is different from the non-focus style.
Testing Digital Products
Testing the accessibility of the user experience from start to finish can ensure that all of our customers can complete their intended task while visiting the page. Tools and quick tests can detect accessibility bugs that are interfering with page tasks.
If there is a bug detected, testers must report the priority of the bug. Note that all accessibility defects must be resolved; use the priority to organize your backlog. Bugs that are captured through automated testing must be fixed before launch.
Critical (task cannot happen)
High (task is difficult to complete)
Medium (it is inconvenient to complete a task)
Low (the experience is frustrating, but it does not affect the outcome)
Here are a few tools you can use to do automated digital accessibility testing:
aXe is an open source rules library for accessibility testing. It allows developers to run automated accessibility tests and take responsibility for the accessibility of their code. aXe works on Chrome and Firefox.
WAVE supports human evaluation, and informs about web accessibility. Wave is useful for testers and stakeholders and enabled on Chrome and Firefox browsers.
Lighthouse accessibility tests are a subset of aXe-core tests that can be machine validated. Lighthouse also recommends a list of manual tests for a more complete scope of your site's accessibility.
TPG ARC Tool Kit is a Chrome Only Browser extension that provides automated accessibility checks through the Dev Tools Inspector ARC Tool Kit is similar to axe (and Wave) with a few additional features
Extension for Chrome and Microsoft Edge Insider to run accessibility testing on webpages and web applications.
Test with assistive technology
Screenreaders are text-to-speech engines that help blind or visually impaired people to read digital content. Use a screen reader to confirm the proper announcement of labels and descriptive text. Below are three options:
Developers combine the content and visual design to build the experience for our customers. In the following sections read more about accessible coding and how you can create digital products that everyone can use.
Specify your language
The language attribute helps assistive technology (AT) like screen readers decide which language or voice to use when reading pages content. HTML lang="en"
If the language changes on the page (e.g. a French quote), define the language for that content fragment. em lang=“fr”
Announce state changes and errors
UI changes must be indicated visually and have a text-equivalent. Multisensory information ensures that people with different disabilities can perceive the change. Errors can be announced with live-regions.
Communicate the current state
It’s very common for UI elements to have two (or more states), e.g. on/off buttons. The current state should be indicated both visually and in text. Accessible Rich Internet Applications (ARIA) enhance the accessible experience. However, adding ARIA incorrectly can create new accessibility issues. Using native HTML elements supported with ARIA labels, as needed, to improve the experience.
Responsive web design makes use of flexible layouts, flexible images, and cascading style sheet media queries. The goal of responsive design is to build pages that detect a customer’s screen size and orientation and adapts the layout to match the user’s needs. Consider the following when coding a responsive page:
Content is legible at all browsers zoom levels including below 100%, at 100% or up to 200%
Pages are fully responsive and consumable on sized from 320x wide and above
Pages font size is set to 100%
Allow users to adjust their preferred browser font size and reflect that option in the page content
Motion sometimes takes up a large portion of the screen and can affect everyone differently. Designers and developers must work together to create accessible motion design.
Native app accessibility
Mobile phones are commonly used by people with disabilities. They offer a portable solution to overcoming common barriers. Developers and designers must work together to create accessible app experiences on all platforms.