This report was written with support from the Government of British Columbia, with support from Northwest Territories Public Library Services, Department of Education, Culture and Employment, Government of the Northwest Territories, and the Government of Canada’s Social Development Partnerships Program – Disability Component.
The opinions and interpretations in this publication are those of the author and do not necessarily reflect those of the Government of Canada.
This work is licensed under a Creative Commons Attribution-Non Commercial 4.0 International License
The National Network for Equitable Library Service (NNELS) is a digital public library of ebooks for Canadians with print disabilities,[i] and an advocate for an accessible and equitable reading ecosystem for Canadians with print disabilities. NNELS supports principles of openness, inclusion, and choice. NNELS is hosted by the BC Libraries Cooperative, a community service not-for-profit cooperative and a national leader in information and technology services.
Our team of Accessibility Testers has expert knowledge in the areas of accessibility testing, analysis, software development, and leadership. The team works to educate and advise publishers, technology vendors, and public libraries on best practices for accessibility. Our testers have lived experience with a range of print disabilities, including blindness, low vision, and learning disabilities.
Overall, Creativebug apps and the web platform are navigable and usable for people who use screen magnification and those who use screen readers. The greatest barriers relate more to the content than the system itself. For example, there are a lack of image descriptions for images, and a lack of audio descriptions for videos, meaning that although a person with a visual disability may be able to navigate the site, they will have challenges using the content. Another barrier is the lack of heading structure/navigation in the PDFs offered in some courses; in order to be accessible, documents need structure.
In addition to these challenges with content, some common accessibility barriers were identified: controls and buttons need improved labeling, and colour contrast should be increased
When using a web browser to explore and interact with Creativebug, the overlay improves accessibility of some aspects, but creates challenges and barriers in others; in general, the use of the overlay results in a more inconsistent experience.
Creativebug is an online platform that gives access to a variety of video classes for arts and crafts. There is also an app that allows the content to be accessed on mobile devices. Testers tested the website on desktop and mobile operating systems. The app was tested on iOS and Android. Test accounts were created through the Northwest Territories library. A listing of the browsers and operating systems used can be found in the Systems and Assistive Technology section of this report.
The findings outline the areas where users struggled to use the platform and provide recommendations on ways it could be improved for greater accessibility.
Introduction to Assistive Technology
All mainstream operating systems include built-in screen-readers (Narrator on Windows, VoiceOver on Apple devices, and TalkBack on Android) that read the contents of the screen out loud, allowing users with visual disabilities to browse apps and websites, send and receive texts and emails, and accomplish many other tasks with ease. Keyboard commands and custom touch gestures provide a flexible way for a user to find and interact with the controls on-screen. Windows also has alternative screen-reading software available, most notably a commercial option called Job Access with Speech (JAWS) and a free and open-source option called Non-Visual Desktop Access (NVDA). The text spoken by a screen-reader can be sent to a refreshable braille device. Mainstream operating systems are also equipped with user interface magnification, large text options, and high contrast viewing mode to assist people with low vision.
To ensure usability and accessibility of an application by people with print disabilities, all functions and controls must be accessible using assistive technologies. The DAISY Consortium explains that the basic assumption of accessibility evaluations is that reading systems “should support reading with eyes, ears, and fingers.” (DAISY Consortium, 2017). It should be possible for users to read the content of the document by:
- Reading the text with screen-readers or self-voicing text to speech (TTS) applications
- Adjusting the display including font size, alignment, and color contrast, or combination of some or all these options
- Reading the text with a refreshable braille display
- Reading with assistive technologies designed for persons with dyslexia or other disabilities
- Reading with the app’s built-in read aloud functions
Accessibility Performance and Recommendations
This report discusses the accessibility findings in the following sections for iOS, Android, and web platforms. The tasks discussed are:
- logging in and out;
- searching for classes;
- viewing, and reading class content;
- and visual adjustment.
The site makes use of the UsableNet Assistive service from UsableNet to enhance the website interface. Details of the effects of this overlay will be discussed in the Web section of this report, but in general it gives mixed results. More detailed feedback was given by testers on the website than the mobile apps.
In addition to the accessibility of the platform itself, accessibility of the content is also a consideration. As it exists now, low vision users are most likely going to benefit from this platform. Videos do not have audio description, which would help blind users to understand the content. Images in the gallery areas and PDF content do not have alternative text descriptions. The PDFs are not tagged for accessibility and are lacking semantic items such as headings which can help screen reader users better understand the structure of the content. Some tools will attempt to add heading markup, but the result will vary depending on the software the user uses to render the PDF.
Structure is important but the lack of description of visual elements is the main barrier screen reader users will face in accessing the content on this site. The visual descriptions and semantic markup of the PDF documents are not enhanced with the accessibility service. Even if navigation is improved, the content will provide little value to blind users without more description.
This report gives an overview of the issues users experienced. A more comprehensive audit would be needed to do a full analysis of each area of the interface, but a general outline of the platform’s accessibility for blind and low vision users along with the challenges found is presented.
In summary, the app is somewhat accessible, but most controls do not indicate their role and there are a number of unlabeled elements where VoiceOver indicates there is an element but reads nothing. Tapping on an unlabeled element can start the video player, but the playback controls are not accessible to VoiceOver. Users are left to work out which elements can be activated by trial and error.
Logging In and Out
All testers were able to successfully sign into the app. VoiceOver reads the field names separate from the edit fields. Having them read as one item would be a smoother experience. Also, there are some unlabeled elements on the login screen indicated by VoiceOver that do not do anything when activated. Removing these would be preferred. The sign in/log in option does not have a button role where VoiceOver will indicate that the item is a button so the user knows it is something that can be activated. Log out is obvious in the setting but it is not always clear in other areas especially when using magnification. Signing out is accessible from the settings.
Much of the functionality of browsing and searching for lessons is useable with VoiceOver, though it takes some trial and error. One tester found that when browsing through lessons, sometimes the focus got stuck near the top of the screen when swiping between items and they had to touch the lesson area of the screen to continue browsing for a lesson.
The tabs at the bottom of the screen are read properly by VoiceOver. On the Explore tab, which gets focus after logging in, the search field is read as a piece of text, and it is not indicated as an item that can be activated. There is also an unlabeled element read when swiping to the next item after the “search” text.
On the My Classes tab, the tabs for Downloads and Watchlist have the added text “tab description” spoken after the label. The same improvements to labelling apply as to the tabs on the class page when viewing a class: the tabs should be given a role of tab and the extra “tab description” should be removed. It would make sense to have the section labels “My watchlist” and “Recently watched” indicated as headings to allow VoiceOver users to move between them by navigating to the next or previous heading. One tester mentioned some difficulty finding the watchlist in the app, and this would help resolve that issue. Using headings for these elements would also help users understand the structure of this screen and clarify that these items are labels that apply to the classes listed after them.
On the Instructors tab, the list of instructors is accessible. However, when viewing an instructor’s profile, images are not described and there are blank elements, where VoiceOver indicates an item is present but does not give any details about it. Activating the blank element before the instructor’s bio information consistently causes the app to crash.
The Settings area is straightforward to use, although it also has the same challenges of elements read as text without a button role, and the presence of blank elements.
The text of help content was accessible with VoiceOver, but more help content would be useful. Some suggestions would be an overview of what is offered in the app and any differences between it and what is available through the website. There is an article that mentions content can be downloaded for offline use, but it does not give much detail. It would help to state that the download option is located on the Chapters tab when viewing a course.
Searching for Classes
All testers were able to search for classes. The filter and sort options are not read in a logical order. The order they are read is: Filter by, Sort by, the selected filter (defaults to All classes), and sort order (defaults to Release date). With default filter and sorting options selected, the order should be: Filter by, All classes, Sort by, Release date. On the main screen where the current filter and sort options are listed, as well as on the filter and sort screens, the items that can be activated do not have a button role, so it is not obvious to a VoiceOver user which items can be activated. On the filter page, it would also help to have VoiceOver indicate which filter is selected when one is chosen.
Viewing and Reading Class Content
It is possible to navigate between the different section tabs such as Description, Materials, Chapters, and so on when viewing a class, but there are several things that could be improved for better accessibility with VoiceOver. VoiceOver does indicate which tab is selected, which is helpful. However, each tab is described as “tab description” which is unnecessary. Using an ARIA role of tab would be preferred for a more familiar interface experience. The “tab description” text could be removed once these elements are properly identified as tabs.
Several areas have blank elements, including the Play button to begin playing a video. Removing the blank elements if there are any that do not have a purpose would cause less confusion. Labelling the blank elements that do have a purpose as well as giving elements that can be activated a button role would go a long way toward making the interface more understandable. On the description tab, the buttons to give a rating are read as buttons but they are unlabeled. This causes confusion on what they do.
The current rating is just read as a number and could be clarified. On the Chapters tab, the “Download to my classes” label is separate from the button. It should be coded to be part of the same element when navigating with VoiceOver.
The PDF content generally has poor accessibility since it was found to not be tagged with semantic elements and does not have image descriptions (alt text). In the Gallery and Comments areas, there are similar challenges with blank elements and buttons read as text, which would be clearer if they had a button role. Images do not have alternative text descriptions; images in the gallery are indicated as blank elements.
The video player is not very accessible with VoiceOver. The control to start a video is read as a blank element. Once a video is started, the only item available to VoiceOver is the time remaining. The controls are not accessible. To close a video, it is necessary to close and restart the app. Transcripts were not found to be available in the app, at least when using VoiceOver.
The app did not offer any options for visual adjustment. iOS testers that tested the iOS app used screen readers and did not use visual adjustments, but in general, ensuring that the text throughout the app has sufficient contrast and respects operating system font settings where possible would be a good starting point.
- Label controls in the video player. This is a concern throughout the app but particularly on the video player screen.
- Remove any blank elements that do not serve a purpose in the interface, to avoid VoiceOver from focusing on it.
- Label blank elements that do have a purpose so VoiceOver can identify them properly.
- Use a control type for the search control on the Explore tab. Either use a text field if it is visually indicated as such, or a button if it must be activated first before the text field is visible.
- Give roles to elements throughout the app so that VoiceOver can identify them properly and users will know which can be activated without needing to use trial and error.
- For the edit fields on the Login form and the Download to My Class button on the course page, have the label and control indicated as a single item so that it reads the label together with the control.
Browsing and searching for classes is doable on the Android app, though screen readers do not read the video controls properly. Visual contrast could be improved in some areas.
Logging In and Out
Users were able to easily log in and out of the app on Android.
The browsing and searching areas of the app were useable with Voice Assistant, however not all the elements were read by the screen reader, particularly on the video player screen.
On the Explore tab, the tester had difficulty distinguishing items visually, and commented that using headings would make it easier to keep track of their position.
When filling out the Contact Form, moving outside the Edit field before submitting the form caused fields to appear as an error in red before the form was submitted.
Searching for Classes
Searching for classes was accessible with Voice Assistant. Filter options were available.
Viewing and Reading Class Content
The video player interface is not very accessible. Voice Assistant did not read controls accurately, and they are quite small for a user with low vision to find and activate. The back button when playing a video to go to the previous screen is hard to find. Captions were available on the web, but the tester had difficulty finding them on the app.
The information on the classes such as Chapter Listing and Materials were read properly with Voice Assistant. However, controls and headings were still small and had poor contrast for a low vision user. The PDF was difficult to read, both visually and with Voice Assistant.
Test results on visual contrast were mixed. For instance, the search edit control has good colour contrast, but class listings on the explore tab and search results are difficult to distinguish visually.
- Ensure all controls including those used to control video playback are labeled properly so screen readers can read them.
- Better contrast would be helpful in the class listings and search results.
- Ensure captions are available for videos in the app.
- Organize content on the Explore tab using headings for different sections.
The website was tested using mobile and desktop browsers with a variety of assistive technology. For low vision users, the site works quite well, though there were some concerns raised about improving contrast in the navigation areas of the site.
The website uses the UsableNet Assistive service from UsableNet to help with accessibility. This adapts the website on demand to add semantic markup that isn’t present in the original code. Results from using this are mixed. One tester liked it, and another mentioned not using it because of having difficulty turning this type of mode off on other sites that use it. In fairness, on this site, the ability to turn accessibility mode on and off works well. The link to toggle it is easy to find near the beginning of the page, though it is understandable that a user’s previous negative experiences with such tools will discourage them from using it. It was mentioned that it is not possible to use the accessibility service in incognito mode because of the cookie requirements, making a user choose between the accessibility mode or user privacy. Searching and browsing class listings is possible, but not all interface elements are accessible. The claim that the accessibility service aligns content with WCAG guidelines is not accurate.
It is nice to see that Creativebug is trying to make its site accessible. Unfortunately, the results from the accessibility service are mixed and the accessibility policy is misleading. In addition to the more obvious difficulties of video and image content not being adequately described, semantic structure like headings and access to some interface elements is still not optimal even when it is used. A better approach would be to state that Creativebug is attempting to make site pages compliant with WCAG and ADA guidelines, but that content created by instructors may not be fully accessible. Suggesting that users add a brief description when uploading photos that could be used for alt-text may help to at least give screen reader users a sense of what photos contain. For a lot of the navigation challenges, changes could be made to the site directly to make the structure more accessible without relying on the accessibility service to make adjustments.
Logging In and Out
All testers reported that the log in process on the web was accessible using a library bar code. Logging out was accessible for users who used magnification, but problematic with screen readers. Without the accessibility mode, the account menu cannot be found with screen readers. When accessibility is enabled, the My Account button that opens the account menu is read. However, the menu options are not reliably rendered when it is expanded.
Screen readers often present a rendering of the page that allows users to read elements in more detail and that includes items like headings and links to help users understand the structure of the page. Users use this mode for the majority of site browsing and switch to interacting with the page directly when using form controls and similar constructs that require direct interaction with the browser.
When the account menu is expanded, interacting with the browser directly and tabbing through elements focuses on the menu links, but at least with NVDA, the menu items are not read in the virtual rendering of the page. Most screen reader users who did not use magnification reported difficulty logging out of the site.
When exploring the code, the entire structure of the menu list item that contains the image to expand the menu and menu items is coded to be presented as a single button element. For proper accessibility, the button role should apply only to the element that is used to expand the menu instead of the enclosing element that also contains the menu items. The accessibility overlay is likely making a best effort analysis on how to add semantic markup, and while it does make these elements keyboard accessible, the result does not make them obvious to screen reader users.
Although the accessibility mode does enhance accessibility in some areas, the experience is still not optimal, and other areas are less accessible when it is turned on. For instance, when reading the navigation links with the accessibility mode disabled, there is no indication by a screen reader that there are submenus that appear for some of them when hovering over them with a mouse. With the accessibility mode enabled, the submenus are now indicated for some of them. However, the “Resources” item is no longer read as a link and its submenu is not available.
Some of the submenu links are in the footer as an alternative means to access the content but not all. It is also somewhat confusing that the main navigation links are duplicated beneath the search box. The following paragraphs give an idea of the type of difficulties a screen reader user will encounter when using various pages on the site.
There is some use of headings, but the hierarchy could be improved, and some elements such as “Pick up where you left off” and “Recommended for you” are not tagged as headings with or without the accessibility mode enabled. The main heading “Get your daily dose of creativity” has the first part tagged as a level 2 heading and the second as a level 1. Remaining headings are level 3, including a blank heading before “Watch now”. Items in curated lists such as the daily practice page have no headings to help navigate between them, and there are silent elements that appear to be Unicode characters between the author’s name and the rating text. Graphical links such as the social media and mobile store links at the bottom of the home page are not labeled properly, though labels on these links are improved when accessibility is enabled. Using a consistent heading structure for site pages with a level 1 heading for the main heading on the page, and lower-level headings for subheadings would be preferred.
The Inspiration page does not work well with screen readers with or without accessibility mode enabled. The option to add an image is just read as regular text and is a clickable item but it is not obvious that it can be activated; the modal dialogs for adding an image and viewing an image in detail are not read properly, and screen readers are unable to determine the number of likes or comments on each photo. A positive feature is that each image is contained in a figure tag.
On the Inspiration page, when uploading an image, the process is slightly different with accessibility mode enabled but there are pros and cons. The button to upload an image is read as a button with accessibility enabled, and the upload dialog is slightly clearer. On the other hand, when choosing an image to open and add a comment, this dialog is not read as well with accessibility enabled as it is when turned off.
On some pages, such as the Inspiration feed, there is a breadcrumb to give the path through the site to reach the page, which is part of the level 1 heading at the top of the page. This should be moved before the heading.
On the CBTV page, the names of videos are not indicated as links, and they cannot be accessed with screen readers. When accessibility mode is enabled, each has an unlabeled button that does work to open them, but the button should have a label to clarify which video it is referring to. The audio in these videos is music only and is not meaningful for a blind user.
When viewing the curated items on the Daily Practice page, items have the same kind of silent elements after the instructor’s name, and are not tagged as headings. There is a Play button added when accessibility mode is enabled but it is misleading; it leads to the class details page, the same as choosing the class name.
When using the site on a mobile browser on Android, not all items were read reliably by TalkBack, and the reading order was not the same as the visual layout. The site had a current page indicator that was displayed visually but not evident with a screen reader. The Help section of the site worked well and had clear structure for headings and text. The menu of Help options on the main website had poor contrast but the contrast in the Help area of the site was sufficient.
Searching for Classes
The basic search process is accessible, although the link to submit the search is unlabeled when not using the accessibility mode. Some fine-tuning of the Filter and Sort options would make them clearer. Some adjustment to the ARIA[ii] roles for the Filter and Sort buttons would clarify the structure. They are indicated as menus, but the Filter and Sort pop-ups are not. This is further discussed in the development recommendations section below.
One tester noted an unlabeled clickable element before the Filter button that activated the filter options. There are clickable elements that allow an individual filter to be removed, but this is not obvious with a screen reader because they are just read as an empty clickable item. When the accessibility mode is enabled, the name of the active filters is read as a button, which is slightly better, but it still does not indicate that pressing this will remove the filter. It was also mentioned that there is an unlabeled button above the Clear Filter item, though this could not be consistently duplicated. Having a Clear Sort button, similar to the Clear Filters button, would give a more consistent experience. Alternatively, the default label for the Sort button could include the phrase “Sorted by relevance” to indicate that this is the current sort. Changing the Sort to Relevance does clear the sort but it is not obvious that this is the default state.
In the search results, both the title and instructor are read twice, once as an image and once as text. This is largely remedied by the accessibility mode, making browsing results more efficient. Use of headings works well here to allow screen reader users to move through results. One tester noted that there were irrelevant results mixed in with the results that were more relevant to what they were looking for. This was noticed on both the website and Android app.
Viewing and Reading Class Content
Most testers on desktop browsers found the video playback controls to be accessible. Controls are somewhat inconsistent to access on macOS and not read well with screen readers on Android or iOS mobile browsers. When using NVDA, one tester reported trouble using the left and right arrows to seek through content, but this could not be reproduced on another machine.
The surrounding page does have some semantic markup to indicate headings and tabs, but there are some improvements that would be helpful. The tabs for the different sections such as Description, Chapters, Materials etc. have letters before them that must be activated to select the corresponding tab. Allowing the tab text itself to be activated to select the tab in addition to the letter would be preferred, instead of needing to select the letter. The breadcrumb is contained in the page heading, though using the accessibility mode does move it before the heading. Having it outside the heading is preferred. Adding a level 2 heading before the start of the updated tab content would make it easier to navigate to the updated content after selecting one of the tabs.
The player has some keyboard shortcuts, which is helpful. There is a message read when the video player gets focus that alerts the user to press the question mark key for keyboard shortcuts. The list that is read out runs together and is confusing to understand. There is no indication when it has been opened or closed.
When settings are expanded, they close when tabbing out of the settings area. This area should remain active until it is closed. One tester mentioned that changing video settings caused a lag on both desktop and mobile browsers when video resumed after settings were closed, but it did resume at the same point where it stopped. This tester also noted that an accessible volume option was available to increase the volume level higher than the regular system level. Captions were visually clear.
Accessing video controls on Android was hit and miss. Adding a class to the Watchlist was very problematic. The controls for captions were present in the regular view but not with accessibility view. However, the tester had difficulty enabling captions with either mode. Accessing the share options on a gallery image was troublesome since the Connect to Facebook option appeared without giving a chance to choose one of the sharing options.
Tabs have letters before them which is somewhat confusing, such as “a” for Description and “b” for Chapters. When activating the tabs with a screen reader, these letters must be chosen rather than the tabs themselves. The active tab is indicated as expanded, this is misleading and should be removed. However, it works well when the active tab is indicated as selected. Interestingly, the “expanded” status is removed when the accessibility overlay is enabled.
A downside to the accessibility mode is that the Materials and Gallery tabs are not present when it is turned on. Labelling the start of the updated content as a level 2 heading would also make it more efficient to navigate to the start of the active tab’s content. The text of the transcript is not available when the accessibility mode is enabled. When users can access the transcript, one screen reader user found it difficult to read because of the included links. The downloadable PDF does give another option to read it without the links, and the transcript layout works well for low vision users. The text in the chapter listing, materials, and notes areas of class listings have good contrast.
Test results using a screen reader are mixed when using accessibility mode including:
- The rating information is not clear without the accessibility mode enabled. The number of ratings is available when it is turned on, but it is not clear how to leave a rating with either mode, or to find what the average rating is.
- The Gallery and Notes tabs contain dialog elements that are difficult to use with screen readers. They are not accessible in the regular screen reader’s rendering of the page. Tabbing through them does provide some access but not all elements are properly labelled.
Some areas are better with the accessibility mode enabled but others are more difficult to use:
- The profile pictures for the comment authors do not have alternative text.
- Like and Unlike controls are clickable items but are not indicated as links or buttons, and they are not in the tab order.
- The status of whether replies are expanded or collapsed was unclear.
- Images in the comments and in the PDFs are not described.
Much of the course content will be difficult for a blind user to understand. Videos do not have audio description, and images both on the website and in the PDFs are not described.
The site does not offer any choices for visual adjustments. Possible improvements would be to add a dark theme, and a choice of fonts. The side menu arrow could be made more distinct, and the color scheme of the side menu could be improved to match the rest of the site more closely.
Some of the navigation text is in all caps, which makes it more difficult to read. An interesting finding was that the site worked quite well with dark mode, using a browser on an Android, and content was easy to distinguish; the help section had good contrast and worked well. Site content also worked with the Android’s browser Zoom feature to make it larger.
- Label buttons and controls consistently throughout the site and use a consistent heading structure.
- Ensure all menu items are accessible by keyboard without needing to hover with a mouse.
- The site makes some use of semantic HTML elements and ARIA, and further efforts in this area would help make the site accessible natively without the mixed results currently offered by the accessibility mode. Alternatively, work with UsableNet to ensure that the output generated by the Assistive service is more consistent and offers access to all interface elements.
- On the Search Results page, the buttons for Filter and Sort are read as menu buttons, but the lists of options, when they are expanded, are not read as menus. In this case, although the lists of options do have keyboard support to act as one, having them marked as menus to assistive technology is confusing, particularly since the categories of filters are skipped over when arrowing through the options, which would cause screen reader users to believe all options are part of the same menu. Using ARIA to indicate expanded or collapsed status without the menu indication would be preferred.
- Use better colour contrast, especially on the bottom navigation lists.
- Avoid use of all caps on navigation items.
- Use the same colour scheme for the side menu as the rest of the site. Make the side menu icon more distinct for low vision users.
- Add audio description to videos and image alt-text if possible or adjust the accessibility statement to clarify that these items are lacking. Adding descriptions would be a major undertaking since Creativebug is highly visually oriented, but at least noting the lack of these elements in the accessibility statement would give a realistic expectation for users relying on screen readers.
The Creativebug website works quite well for low vision users, but more font options and better contrast would be helpful, especially for menus. For screen reader users, much of the site’s navigation is accessible. However, for these users, it is necessary to go in and out of accessibility mode since it improves some areas but causes more difficulty in others. The accessibility service causes mixed results and unfortunately still leaves some barriers, which leaves the site lacking in compliance with web accessibility standards.
Improving labeling of controls in the app, most notably in the video player, would help screen readers read them more reliably. Due to the visual nature of the classes, which make extensive use of videos and images, the content will be problematic for users unable to see it. The course content and user submitted images would need manual efforts to make them accessible to users relying on nonvisual alternatives.
It is understandable that for this kind of content, describing it would take a large amount of effort. If descriptions are not consistently provided, this should be mentioned in the accessibility statement so that non-visual users will be aware they will likely need to get additional help to access the material.
Systems and Assistive Technology
- Operating Systems
- Windows 10
- macOS 11.3.1
- iOS 14
- Android 10
- Mobile Applications
- Creativebug 1.1 (Android)
- Creativebug 1.4, 1.6 (iOS)
- Chrome 86 through 90 on Windows and Android
- Safari 14.1 on macOS
- Safari on iOS 14
- Screen Readers
- NVDA 2020.4 (Windows)
- JAWS 2020, 2021 (Windows)
- VoiceOver (macOS)
- VoiceOver (iOS)
- TalkBack 8.2 (Android)
- Voice Assistant (Android) Magnification
- Zoom (Android feature)
- Zoomtext 2020 (Windows)
- Zoom (iOS)
The following people contributed to this report, including testers and editors.
- Karoline Bourdeau
- Leah Brochu
- David Kopman
- Riane Lapaire
- Ka Li
- Richard Marion
- Laetitia Mfamobani
- Deanna Ng
- Megan Selmer
- John Ylioja
[i] Print disabilities are defined by Canada’s Copyright Act and include visual, mobility, or comprehension impairments such as dyslexia.