Keyboard functionality

Keyboard functionality is vital to an accessible digital experience. Customers with motor and visual disabilities rely on a keyboard to navigate to actionable and important pieces of the TELUS website and app. Some customers might use modified keyboards or other hardware that mimics the functionality of a keyboard on desktop and on mobile devices.

Learn more about keyboard accessibility

Actionable elements

Actionable elements

Actionable elements help a user navigate, enter information, or submit forms. e.g. Links, Buttons, Form Fields, and Custom Components 

  • The visual design of interactive content must be different from static information. Use chevrons, underlines or other indicators to show how they are different. For colours, distinct is classified as a 3:1 ratio between the surrounding paragraph text and actionable element
  • The text of the element must describe the action so use clear language to let the user know
  • The code must tell assistive technologies that leverage keyboard accessibility, whether an element is an actionable HTML or Native App element. Use native HTML or native elements. Where they do not exist you will need to explore options like WAI-ARIA
  • All clickable or tappable elements need to work with a keyboard, speech recognition software, or single switch, as well as screen readers and braille keyboards
  • To support keyboard functionality, code elements as semantic HTML and native code whenever possible. Otherwise it's required to manually code with extra javascript or WAI-ARIA to make the component work for accessibility

Actionable elements help a user navigate, enter information, or submit forms. e.g. Links, Buttons, Form Fields, and Custom Components 

  • The visual design of interactive content must be different from static information. Use chevrons, underlines or other indicators to show how they are different. For colours, distinct is classified as a 3:1 ratio between the surrounding paragraph text and actionable element
  • The text of the element must describe the action so use clear language to let the user know
  • The code must tell assistive technologies that leverage keyboard accessibility, whether an element is an actionable HTML or Native App element. Use native HTML or native elements. Where they do not exist you will need to explore options like WAI-ARIA
  • All clickable or tappable elements need to work with a keyboard, speech recognition software, or single switch, as well as screen readers and braille keyboards
  • To support keyboard functionality, code elements as semantic HTML and native code whenever possible. Otherwise it's required to manually code with extra javascript or WAI-ARIA to make the component work for accessibility

Keyboard functionality at all sizes

Keyboard functionality at all sizes

Keyboard functionality needs to work at all major viewports, orientation, text size to 200%, and, within reason, browser zoom sizes to 200%.

Keyboard functionality needs to work at all major viewports, orientation, text size to 200%, and, within reason, browser zoom sizes to 200%.


Further reading

Further reading

Read the Visible focus Guide to make a keyboard customer’s location easily identifiable.

Examples of experiences

Read the Visible focus Guide to make a keyboard customer’s location easily identifiable.

Examples of experiences


Explore more

Explore more