Conducted by the National Network for Equitable Library Service (NNELS)

July 2019

This report was written with support from the Government of Canada’s Social Development Partnerships Program - Disability Component.

The opinions and interpretations in this publication are those of the authors and do not necessarily reflect those of the Government of Canada.

Published by the National Network for Equitable Library Service (NNELS), Vancouver BC, July 2019

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License

About NNELS:

The National Network for Equitable Library Service (NNELS) is a digital public library of books for Canadians with print disabilities, 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.

Table of Contents


This report highlights the accessibility barriers of the versions of the RBdigital native mobile apps and website in desktop computers as of March 2019. It explains the barriers that these issues pose and why they are problematic, and advances some recommendations to enhance the usability experience for readers with print disabilities.

A new version of the RBdigital iOS RBdigital native mobile app was released in May of 2019, but was not tested for this report.

Readers with print disabilities utilize a variety of assistive technologies to access applications on their phones, tablets and computers, including screen readers and screen magnification software. For this report, our team of testers evaluated the accessibility of the RBdigital apps for people with print disabilities and found that the apps as of April 2019 presented several barriers for users of assistive technologies. The results show that the RBdigital apps have several accessibility issues that constitute barriers to accessing audiobooks and emagazines material. The app worked moderately well for audiobook content, but was very difficult to access emagazines content; notably, everyone testing in iOS was unable to read emagazines. According to Recorded Books, some of these challenges were corrected in the May 2019 release of RBdigital, but we have not yet tested that version. They also noted that additional accessibility enhancements to the RBdigital website are planned for late July/August 2019.

This report presents the results of the accessibility assessment of the RBdigital app in iOS and Android. It also covers testing of the RBdigital browser in Windows and Mac, as well as the usability experience of the RBdigital Media Manager.

The RBdigital Media Manager is a legacy utility for side loading MP3 audiobook players, and Recorded Books have let us know that it is slated to be discontinued later in 2019. We maintained some of the test results in the report, because these players are currently still available to library patrons. Results from the Media Manager testing are presented after the results from the mobile native apps.

The RBdigital mobile web page was not tested, since the majority of readers who are blind usually default to use native apps, which are simpler to interact with than mobile browsers. The reason for this is fairly straight forward: there are usually more elements on mobile web pages than native apps, making the latter easier to navigate and interact with.


The RBdigital platform provides access to various types of content including audiobooks, emagazines, streaming video, and ebooks. The type of content that a user can access is granted through their local public library. For the purpose of this report, testers assessed the experience of accessing this content through the native mobile apps, as well as the usability experience of the media players in Windows and Mac computers.

The objective of testing the RBdigital app is to assess the usability experience of readers with print disabilities,1 and to what extent they can access audiobooks, ebooks and emagazines through their local public library effectively and efficiently. People with visual or learning disabilities use screen readers2, refreshable Braille displays3 and other assistive technologies in their computers, or mobile devices, to access information. It is important that readers with print disabilities can choose the reading systems that offer the accessibility features they require.

iOS and Android devices are equipped with screen readers (VoiceOver for iOS and TalkBack for Android) that read the contents of a smartphone's or tablet's screen out loud, allowing users with visual disabilities to browse apps, open links, send and receive texts and emails, and accomplish many other tasks with ease. They utilize a variety of gestures in order to interact with software; to open an app or activate a function, users tap on the icon twice; to move through the screen the user swipes, along with other gestures, to allow them to read text, type, and perform all other tasks. These devices are also equipped with an on-screen magnifier, large text option, and high-contrast viewing mode to assist people with low vision. Screen-reading software also helps blind people to use laptops or desktop computers with a system of keyboard shortcuts that makes it possible to navigate pages without using a mouse.

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:

The RBdigital app was tested on iOS and Android mobile devices, as well as Windows and Mac computers, using a variety of assistive technologies including screen readers, and refreshable Braille displays.

It should be noted that if a feature can be accessed with a screen reader it is generally accessible for a Braille display (which presents the information in Braille, rather than with synthetic speech.) A complete list of all the platforms and technologies used in this report can be found in the Systems and Assistive Technology section of this report.

Information covering the different versions of the apps for each of the four platforms tested is presented first, and organized by sections grouping similar features. We highlight the problematic issues as they relate to the different functions of the application in each of the platforms tested, but we do not elaborate on every single feature. You can find the entire list of questions in Appendix A.

The last section of this report includes information on the usability of the RBdigital website using browsers in Windows, Mac OS and Chrome OS. Since many of the findings related to the websites are similar across the different sections, we describe these issues more broadly, and present specific examples to illustrate some of the usability challenges. Some of the barriers found when using a browser are similar to those that the testers identified while using the apps.

Since the majority of readers who are blind, or who have other print disabilities, usually default to using native mobile apps that can be downloaded from the different app stores, the RBdigital mobile web page (web mobile app) was not tested. Apps are usually simpler to interact with than mobile browsers, because the latter usually have more elements on the screen than apps.

Summary of Accessibility Performance: What Worked

The testing that our team undertook shows that RBdigital has several features that are quite accessible. Below you will find the highlights for the accessibility performance of the apps (iOS, Android, Windows and Mac versions.)

iOS with VoiceOver

In general, all testers could use the RBdigital application in iOS with VoiceOver as the screen reader for downloading and playing audiobooks. The controls for listening to audiobooks are nicely laid out, and the labels and buttons appear to be appropriately labelled and interact well with VoiceOver. The rewind and fast-forward buttons are clear, the chapter list is easy to find, and bookmarks can be set and navigated to easily.

Android with TalkBack

There are some great aspects in the Android RBdigital app that enable users relying on TalkBack to access and listen to audiobooks. Many of the buttons are clearly labeled, and publications are well divided by content headings. In the audiobook window, the list of chapters is clear and accessible for the screen reader, and narration snaps to the selection as soon as the new chapter is clicked.

Summary of Priority Issues Across All Platforms

With the recommended improvements laid out in this report, the RBdigital app would be a better option for users with print disabilities relying on assistive technologies.

The most important priorities across iOS and Android in the versions tested are:

iOS with VoiceOver

Although this app is usable on iOS with VoiceOver, most testers describe the app as having issues that prevent accessibility that includes unlabeled buttons and menus that are tricky to navigate. The testers noted that the app, in some ways, seems to be separated into three different apps that all present different user experiences: one for audiobooks, one for ebooks, and one for emagazines. They even noted that the search functions are not the same for each resource. The audiobooks section is by far the most accessible, then the ebooks, and then last with emagazines, which testers noted is not accessible at all to users with assistive technologies.

In terms of Braille access, in many places in the iOS app, the tester found that not all parts of the interface can be reached through a Braille display, which relies on tab accessibility to move back and forth throughout the interface, equivalent to keyboard accessibility. An example is the search box, which the tester could not get to by tabbing from the Braille display. The only way they could access it was by using the touch screen with VoiceOver gestures. This means that much of the interface cannot be accessed with a Braille display.

VoiceOver allows users to navigate the screen by swiping and reads the different elements on the screen as the user moves focus to them; for example, swiping right moves the focus to the next element and swiping left moves to the previous element. Voiceover reads elements in a logical linear manner, from the top left corner to the bottom right. In the RBdigital app, one-finger swiping doesn’t always work to navigate between controls as it does in other apps. For example, in order to switch from searching by keyword to searching by author, the user presses the button called “keyword” and that brings down a menu of other options. However, swiping doesn’t give the user access to this menu. The same is true of the search dialog box. Testers found that swiping down from the top of the screen goes right past the edit field for entering text for searches. This edit field can only be found by touching the screen, which is not intuitive for users of assistive technologies, and can create a higher learning curve to access the app leading to user frustration. It was also noted that the slide-out menus and dialogues appear out of order when using swipe gestures, which can cause more confusion for the user. When exploring by touch, a tester can determine that menus appear at the top of the screen, but when swiping through the screen from top to bottom, or left to right, these options appear at the bottom.

A major issue is that when a menu or feature is activated, the previous screen is dimmed to form an inactive background. This is a common practice throughout the app, but presents a major challenge for VoiceOver users. Instead of being positioned on the new controls, the user is left stranded on the previous screen.

A prime example of this is the Menu button. When activated, it expands with options such as My Account and Log Out. However, testers were not able to swipe to these options, they could only navigate the original screen. The only way to access the menu field is to tap on the far-left side of the screen, then swipe through its controls. This is problematic, because blind users will not know where the menu is, or even that they have to tap it.

When it came to emagazines, all testers discovered they are simply not accessible at all. Although the magazine cover is being displayed, VoiceOver is left in a non-responsive screen in which no text can be read and no controls can be swiped to.

Accessibility Priorities

The following is a list of what the testers identified as top priorities for recommended improvements for iOS with VoiceOver

Android with TalkBack

Although the issues with Android are not as significant as they are with iOS, testers discovered buttons in the app that are unlabeled for screen readers, which makes it difficult to use. In addition, the buttons for “Check Out” and “Play” do not read as buttons, but just a clickable elements. Testers also discovered that the emagazines open in a PDF Reader, which presented a highly-graphical user interface that is not accessible. When a user presses the “Text” button this did not improve the readability, and pressing the “Back” button made the app crash.

It was noted that the ebook reader is not accessible, even though there are several labeled buttons, including “Search,” “Content,” “Settings,” “Menu” and “Bookmark.” One of the two testers that assessed the app in Android could not get TalkBack to read any text beyond the title of the ebook.

Accessibility Priorities

The following is a list of what the testers identified as top priorities for recommended improvements for Android with TalkBack

Testing approach

NNELS developed a list of criteria for testers to perform a structured review of the accessibility of mainstream library reading applications. We drew on the guidelines that the DAISY Consortium developed for the systematic assessment of the accessibility of hardware and software-based reading systems. This methodology allows to determine the accessibility of the functions and features of each reading application from the user perspective.

For more information from the DAISY Consortium, see the Accessibility Screening Methodology Guidelines and Checklist:

Six testers with print disabilities reviewed the RBdigital mobile applications using screen readers. They include testers with visual impairments and learning disabilities, all of which have accessibility expertise and extensive experience using assistive technology. One additional tester who is sighted, and is proficient in the use of a screen reader, also assessed the application in the Android platform; in particular, those features related to visual adjustments aimed to provide access to readers with print disabilities other than blindness, such as low vision or learning disabilities.

All testers performed several tasks, corresponding to the different functions of the application, and answered questions systematically. The questions for all functions are grouped into various categories, including:

Systems and Assistive Technology

RBdigital Application Versions

Devices, Operating Systems and Assistive Technologies


Testers accessed the content provided by RBdigital through their local public libraries, including:

We would like to thank Recorded Books for providing access to their testing environment for our testers, which allowed everyone in our team to review the same content. For consistency in the assessment of ebooks, NNELS provided Recorded Books with two public domain EPUB files that have rich navigational features, semantic tagging, and accessibility metadata, which were uploaded into the testing environment.


The results of testing included in this report were accurate at the time of delivery/publication. They, however, may not reflect all personal experiences, which can be affected by the version of the application, as well as the assistive technologies used. In the following pages, we provide detailed information related to the most prevalent accessibility issues as they pertain to the user experience, but this report does not include descriptions of all features of the RBdigital mobile apps and website.

Testing Results and Recommendations

In this section we dive deeper into specific accessibility issues of the different features of the RBdigital app and website. Below you will find the testing results and their related recommendations as they pertain to:

We highlight some of the problematic issues as they relate to the different parts of the application in each of the platforms tested; but we do not elaborate on each of the features. To see the entire list of questions, please refer to Appendix A.

Library Access

For this evaluation, Library Access includes all features related to accessing RBdigital and the content it offers through a user’s public library, including signing-in, searching for audio or ebooks and emagazines (including filtering searches), downloading and removing books and publications, and setting preferences. To view all the questions for Library Access, please refer to Appendix A.

Signing In

Some testers reported that the sign-in process was confusing. Testers had to do it through a browser and their respective public library’s websites; however, some libraries offer clearer instructions than others. All testers indicated that signing up through the app with less steps would be preferable.

At the time of testing, it was necessary to log into the library account and then go to the RBdigital website and create an account there. Testers described this process as having too many steps and as not being very intuitive. They suggested that it would be simpler to use one’s library card to directly log in to the app with an option to create a username after logging in.

Although this is not an accessibility issue per se, there are two aspects that have a direct impact on accessibility. First, if users have to create their account on their library’s website, they depend on how accessible it is; if it is not, then the sign up process would be inaccessible. Second, because it takes longer to perform some tasks using a screen reader, having to sign in from the library website and then create an account and then sign in again on the mobile app would take a visually impaired user significantly longer than a fully sighted one.

Since the testing was conducted, a new version of the RBdigital app has been made available in the iOS and Android app stores, and Recorded Books let us know that the new version enables patrons to register for an account from within the app, but we have not tested those versions for the native mobile apps, and cannot speak for the accessibility of all the steps and screens for creating an account.

iOS with VoiceOver

The sign-in process can be navigated using standard VoiceOver commands. However, the dialogue has a country picker, and when VoiceOver lands on it the user can tell that they need to select the country, but the label for that element is missing. Instead, the label is next in the swipe order isolated by itself. This meant users had to sign-in on the website. It was also noted that edit-field labels are not read by VoiceOver at all when jumping by edit fields.

Recommendation. Make sure that the label for the country picker is on the picker control itself, so when VoiceOver lands on it, it should say “country” followed by the name of the country. In the screen where the user has to enter their email and password, add the “.” And “@” symbols below the keyboard for ease of access in the email/username edit field.

Android with TalkBack

Testers described the sign in process as too complicated and requiring too many steps, or needing sighted assistance. One tester was able to go to the selector box to click on “Canada” and managed to enter their email correctly, but then was unable to put in their password. Every time they clicked on a letter it read as “full stop.” The only way to troubleshoot this issue was to get sighted assistance to log in.

Recommendation. Allow users to setup their account in the app with their library card.


This applies to all content types—ebooks, audiobooks and emagazines.

iOS with VoiceOver

Testers found that the settings screen for the audiobook Preferences can be activated either by clicking a button, or by clicking on the text that the user would encounter when swiping right from the preferences button. These two options for the same task can be confusing since both actions take the user to the same place. The emagazines and ebook preferences have the same issue. Although in this case, the button says “ebook Preferences,” while the element next in the swipe order says “Magazine Preferences,” so it is not unreasonable to assume that they are two different sections. Testers noted that both took them to the same section, which was confusing since the labels are different.

Recommendations. Make the button active and remove the text elements. Also, add a label for the “Back” button in the preferences section, which is missing and just says “Button” when the user goes into those sections.

Testers noted that VoiceOver does not indicate that an ebook preference is selected, even though the item is visually highlighted. This means that users of VoiceOver cannot access this information without visual assistance.

Recommendation. Make sure that VoiceOver can determine and indicate when a preference is selected.

Android with TalkBack

Testers for Android with TalkBack also found issues with the preferences. They noted that the Preference Menu is not easy to find in the app. Even after reading the help section, one tester could not understand how to set preferences for ebooks. One tester could set preferences, but only on the browser, by selecting Settings at checkout.

Recommendation. Label all controls to allow users relying on TalkBack to set preferences in the app.


This applies to all content types—ebooks, audiobooks and emagazines.

iOS with VoiceOver

The accessibility of the search dialog requires improvements. Testers did find that they could perform all tasks, but only after troubleshooting. They noted that the search section has improperly labeled buttons, and users are not able to swipe to fields reliably. For instance, there are two search buttons that are labelled oddly. The first one is “btn topsearch” and the second one is “perform search.” This is even more confusing for a user who relies on VoiceOver since the swipe order does not match the positions on the screen. The buttons may visually appear in an order that makes sense to a sighted user, but this does not translate for users relying on assistive technologies. It was only through troubleshooting that the testers discovered that “btn topsearch” is the main “search” button.

Recommendation. Make sure all the buttons in the search area are properly ordered and labelled. The search box portion should trap the VoiceOver cursor, the same as with dialogues.

Search results are not fully swipable. When a user tries to swipe through the results there does not appear to be in a logical order, and there is no clear indication what button belongs to what resource. This makes it hard to find the appropriate elements when using swipe gestures. When a user swipes to a title it is not clear what button to select to activate the actions for those titles. It does appear that all the buttons are labeled, but because the buttons are grouped right beside each other there is no context to determine which book a user is adding to their Wishlist or Checking out when they activate the “Wishlist” or “Checkout” button. This is also confusing when exploring by touch, since it is difficult to determine which button activates the actions and on which book. The titles and their corresponding buttons need to be more clearly organized for users with assistive technologies. It was noted though that when a user navigates to the full list of curated ebooks there is no problem reading the list since the swipe order in that section works fine. Testers also found the results pages confusing due to the fact the screen reader would not read out the total number of results on the page. Instead a random “1” was read out with no reference to what this number is attached to.

Recommendations. Add a heading for each title for easier navigation so a screen reader user can skip the buttons and other information regarding that result quickly. Arrange the results as a list with good target size on each clickable element, since a user might want to use explore by touch to navigate the list of results. As well, we also recommend to state clearly that the numbers before the results take the user to different pages.

Testers noted that the “About This Book” is not accessible. In order to access this page to get more information, such as the author, genre, or description, the user must click on the graphic of the book. Unfortunately, this is not formatted as a button, and is therefore not accessible with VoiceOver. The only way to gain access to this information is by getting sighted assistance. Once on this page, it’s fully navigable with VoiceOver and offers all information about the title.

Recommendation. Ensure this option is presented as a labeled button that is clickable so that VoiceOver users can activate it, to ensure full access for all users.

Android with TalkBack

Testers noted that there are unclear or missing button labels. For instance, in order to add a title to the RBdigital library, the user must press the “Plus” button. This label does not clearly indicate its function to the user. It would be better if this button was labeled something like “Search for new books.” Regarding missing labels, testers found that the search button on the top navigation bar is unlabeled. After trial and error they were able to discover its use, but noted that after clicking it they are not presented with a search box, but with two buttons: “audiobooks” and “emagazines.” It is not very clear that this is the search function, since the screen reader only indicates that it is a button for “audiobooks” or “emagazines” and “double tap to activate.”

One tester found the search function even more confusing when they pressed the “Plus” button to find another title. After clicking this button the tester found themselves in a list of 30 items, each with their own Checkout and Wishlist buttons. Although this worked, the tester could not navigate away from this list easily. Through troubleshooting the tester discovered they could press the button labelled as “Refresh” to bring up a content menu. This button is located next to the title and logo of their local library, which is not a logical location on top of having an unclear label. In this new content menu, the tester was able to select “emagazines” and proceed to find another title to read.

The other areas in the search screen are drop down menus for “Title,” “Name,” “Genre” and “Language,” but testers discovered similar issues with unclear or missing buttons and labels. The “Title” and “Name” options are not edit boxes, which makes it impossible to use them. When selected they just drop down to a menu that changes nothing, which is confusing for the user. For example, after opening the dropdown menu for “Title” the button to activate the search beside this area is unlabeled.

For the advanced search section, the button to activate the search is clearly labelled, but the section itself has no label. A user can only presume they are in the advanced search section once they find the button to activate the search.

Testers also noted issues with the filters feature. The button to activate filters is labelled clearly and correctly, but once a tester clicked it and swiped for options, the feature closed. This meant that the filters could not be used for searches.

Recommendations. Label all buttons, controls, and sections within the search area with appropriate, clear, and intuitive names (e.g. “search for new titles” instead of “Plus”). Simplify search screens, and ensure that all controls and search areas are accessible to screen readers.

Testers discovered that the image of the title is an unlabeled button that can be selected separately from the search result information for that title, and that each title in the results is in their own box. Testers did note that after selecting an entire section of a single title the screen reader reads everything properly, which means this section is clear and accessible to the user. Nevertheless, if the user accidently clicks on just the image of the cover the screen reader will read the image as an unlabeled button. This means that as they navigate through the results list they may hear “unlabeled button” in a context that is not clear to them. This can lead to confusion and user frustration, which can cause the user to think the title is not there and give up on the search.

Recommendation. The image of the cover should not be selected separately. This means the entire entry of a title in the browser section will only be read as one element.

Testers also noted that there are one or two small buttons in this section depending on if it is an ebook or emagazine. These buttons are too small and can be difficult to select. It would be useful if they could be read with the rest of the title result information so the user knows that those buttons are there. When the user does not have a book checked out these buttons read as “Checkout” and “Wishlist.” When the user does have an item checked out they read as “Read” and “Download.” Though these labels are clear and appropriate for their function, again they are too small, which can pose issues for a low-vision user.

Recommendation. Consider increasing the size of all the buttons, to make it easier for everyone to find them.

Checking Out, Renewing and Removing Titles

iOS with VoiceOver

Testers found that the checkout screen has odd labels; for example, “view all” is listed twice, and the button labelled “btn Download all” should be labelled as “Download All.” It was also noted that the “Remove Title” buttons are listed in a swipe order one after another, and don’t clearly correspond to a title. This makes it difficult to determine which button removes which book, especially with a large number of books.

Recommendations. All buttons should be clearly and appropriately labelled. Ensure that swipe order is correct, and that VoiceOver indicates which title the options to check out or renew/remove books correspond to. And the same for the “play” and “downloaded” buttons.

Android with TalkBack

There is a “Checkout” button under the title. In the case of emagazines, when the user selects this button, only the title and the date (presumedly the last publication date for that title) is read by the screen reader. Testers noted that after clicking this button a pop up window opens, but the screen reader does not announce that this pop up has opened. The tester did discover with some exploring that there is an option below to select “Automatically Check Out the Next Issue” followed by an “Okay” button, but after clicking “Okay” it is not clear to the user where the item has gone. The user is still on the homepage, but TalkBack only says “RBdigital.” This was also true when checking out ebooks.

Recommendation. After checking a title out give the option to the user to be taken to the page with the title they just checked out, so they can get more information on the title and read it right away.

Selecting a title to return within the app is challenging, since the list does not contain text labels for each item. One must use the arrow keys within the list, then tab to the “Title” box to hear the title of the currently-selected item.

Recommendation. Ensure that all elements contain text labels.

Reading, Listening, and Navigating Content


iOS with VoiceOver

The playback screen for audiobooks is fairly accessible when the user swipes through or explores by touch, and the target size of the playback controls are fine. Nevertheless, the “Total Time” element is completely missing a label. It was also noted that at the bottom of the screen there are the four buttons for “Speed,” “Chapters,” “Bookmarks” and “Sleep” that all have doubled labels. Although users can swipe to the buttons, as well as the text labels, this double labelling can cause confusion. Testers also found that some buttons have labels that could be more concise. For instance, for adjusting the speech there is a button labelled as “1x” beside static text that reads as: “Playback Speed.” It would be more user friendly if it was a single button, labelled as “Playback Speed: 1x.”

Recommendation. Ensure labels appear only once per button, and combine text and labels to add information where necessary.

When an audiobook is playing, the function to skip by percentage value by swiping up or down with one finger does not work. The seek slider is broken with VoiceOver, and when a user swipes up or down the percentage changes but it does not affect the actual playback. This means that this function is not accessible for an average user. The only way to use the slider at the moment is to bypass VoiceOver with double tap and hold gesture.

Testers also found that in the case of the playback speed the button does work, but it appears as a dialogue at the top of the screen. This makes it harder for the user to discover. The focus should jump to the area with the dialogue for changing the playback speed, and the VoiceOver cursor should be trapped in that dialogue until the user makes a choice.

Recommendation. Fix slider menus to allow VoiceOver users to interact with them.

Android with TalkBack

Testers noted that on the main screen in the audiobooks page, a “Play” button is located next to the list of available books, but clicking it does not appear to do anything. It is only after clicking the book’s title in the list that the user realizes the book is being downloaded.

Recommendation. Ensure all buttons are clearly organized and can be activated using TalkBack. Have an audio prompt for downloads for people using screen readers, so they are aware the title is being downloaded.

The buttons for the navigation controls are unlabeled. It was only through trial and error that the tester discovered what these buttons are for, which include skipping forward and back by time interval or chapter, and pause. It is only after a user clicks them that they discover what happens; in other words, the buttons work, but require proper labelling.

Recommendation. Ensure all buttons on the audiobook play page are labeled clearly for users with screen readers.


iOS with VoiceOver

Although testers were able to download ebooks, the popover that appears with the option to select the length of checkout is at the bottom of the screen. VoiceOver does not focus on this area, forcing the user to swipe through the screen to locate it.

Recommendation. Ensure all elements interact with VoiceOver, and that all new popovers and sections are announced when opened.

Testers found two main issues that make reading ebooks difficult. First, the navigation buttons, as well as any lists, on the reading screen are all unlabeled. Testers found that most of the controls were simply labeled as “Button.” This meant the user has to discover what the buttons do through trial and error leading to high user frustration. One tester found the “Next Page” button by accident, but noted no change in the Page Count or Reading Percentage. Second, it is not possible to use three fingers to scroll through the book, which is the gesture used by screen reader users that is similar to how a sighted user would scroll it with a single finger. The only way to turn the page in the reader is with an unlabeled button, which is again inaccessible to users with VoiceOver.

Recommendation. Label all buttons and list controls. Ensure that VoiceOver users can scroll the ebook by using a three-finger swipe gesture, or provide functionality through another gesture.

Testers also noted that there is no “Read Aloud” button to read the entire book or chapter using text-to-speech functionality within the app. Testers attempted to read books by using the standard VoiceOver gesture to read text (swiping down with two fingers), but testers found that even doing this, the pages are not visibly shown as the chapter progresses, as is the case when using the same gesture in other apps. This causes VoiceOver to read further ahead than the page that is currently on the screen, which creates overlap and confusion for the reader navigating the ebook.

Recommendation. Include the option to “Read Aloud” the entire book or chapter that is functional for text-to-speech within the app.

A tester found that one of the unlabeled buttons was to access the Table of Contents. The tester then noted that all the buttons within the Table of Contents were also unlabeled, and that the text for the button was not part of the control itself, but next to it. This meant that the tester could only navigate to areas of the book through trial and error.

Recommendation. The chapter/section names should be on the buttons themselves so when the user touches a button VoiceOver will read the name of the chapter/section the user can jump to.

Android with TalkBack

For users of Android, testers found that the ebooks were not accessible. Though the tester was able to discover the buttons for “Search,” “Content,” “Settings,” “Menu” and “Bookmark,” which were correctly labeled, it was also discovered that there are several other controls that are only labeled as “Web View.” This meant that most of the functionality of the app was not accessible to the user. The tester was also unable to get TalkBack to read any text beyond the title.

Recommendation. Label all buttons to improve accessibility of the reading features for ebooks. Ensure that all pages can interact fully with screen readers.


iOS with VoiceOver

The testers found that opening and reading emagazines through the iOS RBdigital app is entirely inaccessible. While it is possible to see which emagazines are available, and testers could see a few emagazines that showed up on their Checked Out screen, they found that clicking on the “Read” button does nothing. Once this button is clicked, all that VoiceOver says is “In Progress,” and it seems that the device becomes frozen. Testers tried swiping and using other VoiceOver gestures, but nothing seemed to work. VoiceOver would only repeat “In Progress” until the RBdigital app was shut down. Testers got assistance from a sighted user, and they could see that the magazine cover is being displayed, but the app fails to pass on this information to VoiceOver. It should also be noted that some emagazines do not offer the article view, in which they are navigated by pages only.

Recommendations. Ensure that VoiceOver reads download messages so that the user knows that a magazine is being downloaded. As well, ensure that the app sets to Text View by default if VoiceOver is running, or at least make it possible to add this as an option in the settings.

Android with TalkBack

For Android users, the testers found that the most difficult aspect of the emagazines reader is figuring out how to switch from PDF to Text View. The emagazines open in a PDF Reader, which presents a highly-graphical user interface that is not accessible to readers with print disabilities. The menu option for switching from PDF to Text View is hard to locate, and is hard to recognize as a menu option. It also is difficult to get to the menu itself to make this switch with the screen reader. Part of this is because the menus are not static and they are located at the bottom of the screen. It took some exploration for the tester to locate and press the “Text” button, but all controls then vanished and no text appeared. After clicking the “Back” button to navigate back to the browser, the app crashed and Android stepped in to reload it. Luckily, when it reopened it was at the same location as it was before the crash and the user did not have to locate and check the emagazines out again. This time the tester tried selecting a page before pressing the “Text” button, but as soon as they picked a page, the screen went blank. They then attempted to select a different magazine, but the app froze on a prompt of “Opening Magazine” for nearly an hour. When the emagazines finally reopened, the tester was again presented with the word “Text” (which did not appear to be clickable,) and a list of pages. After clicking on a page, not only did TalkBack fail to find any controls thereafter, a visual check of the screen confirmed that it was completely blank.

Recommendation. Ensure that the app defaults to Text View when the screen reader is active. Make the button to change to Text View more prominent and easier to find. Offer the possibility to default to screen-view for emagazines in the settings.

Visual adjustments

In this section we mention some of the features that are missing from the native mobile RBdigital apps that are helpful for users that have low vision, or a learning disability (such as dyslexia.)


Testers did note that although it is possible to change the type of the font, the app does not support the open dyslexic font.

Recommendation. Add the dyslexic font to allow users to change the font type if needed.

It is not possible to highlight text. In addition, it is not possible to select a custom stylesheet, or remove all formatting. It was also noted that ebooks are always present in paginated view, and there is no option to change to scrolled view, and not even dual-page view is supported.

Recommendations. Consider adding options to highlight. Add a custom style sheet or more options to change and/or remove formatting to allow greater customization to suit individual user’s needs.

Testers noted that when reading an emagazine it is possible to change the text from black-on-white to white-on-black, but there are no other choices of colour and it is not possible to change the font type. People with low vision and learning disabilities need access to wider options for background and text colour, as well as font options, to suit their specific needs. For example, many people with poor vision also find it helpful to use other colour themes—such as a blue background with yellow text. It should also be noted that the options that are available to change the text are not available for emagazines that do not have Article sections.

Recommendation. Add a wider variety of font types.

In addition, like ebooks, emagazines always present in paginated view, and there is no option to change to scrolled view.

Recommendation. Permit users to adjust how they read emagazines by providing an option for single-page view.


The tester discovered that there are the same options for background and text colour changes, but the icons to select these options are symbols that are not intuitive and the option was only discovered by mistake through troubleshooting.

Recommendations. Make icons to adjust visual settings more prominent and easier to find.

The RBdigital Website

This section specifically deals with only the website. For test results and recommendations for in-browser app accessibility please refer to the above sections.

Overall, testers accessing the RBdigital website using browsers in Windows, Mac OS and Chrome OS reported mixed results. In this section of the report we highlight the problematic issues as they relate to the different parts of the RBdigital website as it was tested in Windows (Firefox, IE and Chrome), Mac OS (Safari), and Chrome OX (Chrome) browsers; but we do not elaborate on each of the features.

Since many of the findings related to the websites are similar across the different sections, we describe these issues more broadly, and present specific examples to illustrate some of the barriers relevant to each operating system.

Windows browsers with JAWS or NVDA

An issue throughout the entire site is the way the menus are presented. Based on the text, users will generally know that it is a menu, but to improve clarity these menu options should indicate to the screen reader that they can be clicked by letting the screen reader know that it is either a button, link, or menu item. As testers found, the menu options are announced twice; once as a graphic and once as text. Testers noted that the menu options are not defined with proper roles.

Recommendation. Ensure items on menus are clearly and appropriately labeled, and that all the items are identified as clickable by screen readers.

When a user clicks on a button some of the options change, but there is no audible alert to indicate any changes. This means that it is not clear for screen reader users if anything has changed.

Recommendation. Ensure there are audible alerts when a page or item changes for screen readers to have full access to the information in the website.

Chrome OS with ChromeVox Screen Reader

The menu options are not defined with proper roles. Based on the text, users will generally know that it is a menu; but to improve clarity, these menu options should indicate to the screen reader that they can be clicked by letting the screen reader know whether it is either a button/link/menu item.

Recommendation. Menu options should indicate their roles to the screen reader, rather than just showing as list items.

Though the search option is easily located and it is easy to do a simple search, the advance search presents challenges, particularly the keyboard focus trap. After clicking on the “Advanced Search” button, more options do appear and the edit fields are labelled, but the main problem is when the user moves past the narrator textbox. This is where the keyboard navigation gets stuck in between the “Question Mark” button, an unlabeled textbox, and the “Clear Field” button. The user also cannot move past these controls by using the arrow keys, and it is necessary to tab or shift-tab to get past this section. It was also noted that the “Advanced Search” button is a simple button even though it acts as a toggle. This means that the state of the button (i.e. whether it is expanded or collapsed or pressed/not pressed) is not read by to the screen reader, which can cause confusion.

Recommendations. Label all edit fields, buttons and controls. Ensure that users navigating through the keyboard are not trapped or stuck in any controls.

For emagazines, the user needs to click on a page and then select the text option (this text option has no indication it is clickable). This process needs to be done every time they read a different section. It was also noted that the links to different article are labelled as a string of numbers that does not indicate where the link will take them.

Recommendation. Set the default view either in the settings or right before the user opens the emagazines so the reader does not have to change it to Text View every time they move to another article. As well, consider moving the cursor to the beginning of the article when a link is clicked.

Mac OS Safari with VoiceOver

The items in the main menu are read out by VoiceOver when the menu is hidden. However, the tester was not able to click on any of them unless they first clicked the “Menu” button, but this button is located at the end of the list of all the other Menu items as they are read out by VoiceOver. Since users encounter the menu items first, it is important that they only appear when they can actually be used.

Recommendation. Ensure that the menu is well and truly hidden until the menu button is pressed.

While using the website in Safari, users can browse and check out ebooks and emagazines. Testers noted that though emagazines can be read in the browser, in order to read ebooks the user must use Adobe Digital Editions. Unfortunately, this app is not accessible to users relying on screen readers.

Recommendation. Enhance functionality in the browsers to allow users to read ebooks, and ensure that any external app is compatible and usable for screen readers.

Often when loading a new page, VoiceOver's focus gets shifted to the very bottom of the page, and onto one of the social links. This happens most often when clicking on the title of an ebook or emagazines to go to its information page. This makes is difficult for a user to know where they are in the app, and impacts their ability to clearly and easily navigate to new pages. It is common for screen-reader users to look for headings to denote the end of navigation, and the start of the page content. Testers noted that for most pages on the RBdigital website the first heading is "Download Mobile Apps," which comes after all the other content on the page. This again makes it hard for the user to know where they are within the app. A heading would help a user to determine exactly which page they are on, since currently the top of each page is identical to users with screen readers.

Recommendation. When a new page opens, make sure that the cursor is not sent to the end of the page. It would also be helpful to have a heading to mark the beginning of the content on each new page.

The tester found there are three main sections of the emagazines reader (the page list, the reading controls, and the page content.) These sections are not separated by any clear headings or other meaningful dividers. This makes it challenging for the user to navigate between them. Testers also noted they were unable to jump to the start of a page to read the contents.

Recommendation. Add headings at the top of pages and below the navigation section. Add headings or landmarks to separate the sections of the emagazines reader to aid with reading navigation. As well, add a setting to make Text View the default for emagazines.

Computer Media Players

In this section we present results from the Media Managers. As those players are still available, they are part of the usability experience.

Windows with JAWS and NVDA

The RBdigital Media Manager is a legacy utility for side loading MP3 audiobook players, and is slated to be discontinued later in 2019. Although Recorded Books suggested that results from the Media Manager testing are not relevant for this report, we decided to include them because they are still available, and still are one piece of the usability experience of patrons accessing RBdigital through their public libraries. While this may be something more to do with the library side of things, we believe it is important to report our findings since older versions are still being downloaded by users. It is important that the vendor makes sure that users with the legacy version are aware that upgrades are coming, which could perhaps be done through alerts to the users through the older versions.

Several parts of the reading experience worked well for a screen reader in Windows. Testers discovered the app to be responsive and not sluggish, and the most crucial features are either well-labeled or easy to find. They also noted that the menu bar is easily invoked with a press of the Alt key; a feature that is essential to navigation for screen reader users. However, some other main features were found to be difficult to access (e.g. playback window for audiobooks.)

Accessibility Priorities

The following is a list of what the testers identified as top priorities for recommended improvements for the Windows app to work well with screen readers per the March 2019 RBdigital software versions tested.

Our testers found that several controls cannot be highlighted with the Tab key. This is problematic for users relying on assistive technologies and who are unable to use a mouse. Blind users explore the available controls with the keyboard, and unfortunately untabbable elements are often overlooked when designing apps and websites. This means that important controls and elements cannot be found by the user: they won’t even know the control exists. The only way to troubleshoot this issue is for the user to explore using the arrows as well as the screen reader’s mouse cursor, which is a very long and difficult process that is not always reliable. It is good that all elements are displayed in a somewhat logical, left-to-right order. Nevertheless, the fact that there are so many buttons that are not labeled correctly, makes the process of trying to find tabbable controls particularly disorienting. This leads to high user frustration for anyone relying on assistive technology to interact with the app.

In order to add a title, a user needs to click “Browse for a Title” with the mouse cursor. The next screen has a “Search” link, which pulls up a “Keywords” edit box that is proceeded by three buttons to select the desired content. This process was found to be accessible, but the tester discovered that after pressing Enter to perform the search they had to tab out of the search box before they could use navigation keys, and that all the search results populated into a pane below without refreshing the page. This means the user is not immediately aware that the results have appeared on the screen.

Recommendation. Have the page refresh when presenting the search results to prevent any confusion.

Testers found that when a user clicks on a title it pulls up an accessible page with a “Checkout” button, book description, and tabs with other information. Although it is possible for users to navigate this information, it is not clear that they are on a new page, or in a new section. This content should be prefaced with a Level 1 Heading. Currently, no heading begins the content, making it cumbersome to find.

Recommendation. Separate search results and new sections with a Level 1 Heading.

When filtering search results, each category presents as an edit box, with an unlabeled button to activate a list box to enable the filter. This button is presented above each box, but because of the many filters it is unclear whether the button is presented directly above or below the box. It should therefore be labeled with text for clarity.

Recommendation. Ensure the buttons filtering search results have are all labelled clearly and appropriately.

Our testers found that not all buttons and elements are labeled throughout the app, and that the playback window for audiobooks was completely inaccessible through Windows. Consider labeling and enabling tab support for playback controls, or having an option for an accessible, popup control window instead.

Selecting a title to “Play” or “Return” within the app is challenging, since the list does not contain text labels for each item. One must use the arrow keys within the list, then tab to the “Title” box to hear the title of the currently-selected book.

Recommendation. Consider labeling and enabling tab support for playback controls available when the audiobook is playing, or have an option for an accessible, popup control window instead.

Testers noted that there are alerts that pop up on the pages with no audible queue to their existence, and some that suspend execution of the requested task. These create confusion and frustration for the user by interrupting their interaction with the app.

Recommendation. Consider sending a browser alert that gives an audible clue to their location, such as "Click OK or Cancel at the top of the window" when "Remove this hold" is clicked.

Testers found that the Playback window is completely inaccessible. When an audiobook is playing, the tester found no way to pause the narration, or select a different chapter or navigate within it. The only way to get it to stop seems to be to close and reopen the application. When the user pressed the “Play” button again, the narration resumed at the beginning, and not at where they left off. This lead to user frustration and the tester quit the application.

Recommendations. Ensure that all controls for playing audiobooks are accessible. Add an audible indication stating that the book is being downloaded and would be played as soon as the first section is available.

The ebooks have to be read by using Adobe Digital Editions or another compatible reader. This means that the reader has to download a “.acsm” file type while using the Windows RBdigital app, but then open the files in this different application (any Adobe compatible reader). This poses a serious accessibility barrier since the standard Adobe Digital Editions has a tendency to crash in Windows when using screen readers.

Recommendation. Allow for people using Windows to read within the app itself, or with another application of their choice that is more compatible with screen readers.

The emagazines tested appeared completely graphical in Windows until the testers clicked the “Text” identified by the screen reader as a link at the bottom of subsequent sections. Only then was the text of this section instantly displayed. Once they are in Text View, selecting pages and sections within a magazine is easy within the browser, as is navigating by paragraph and heading, spelling words, and reading sections uninterrupted with a screen reader. The “Text” link for a magazine’s section is a good way to incorporate accessibility. However, having this link unavailable for unsupported sections - such as the Cover page - could lead some users to believe text is not available for that publication.

Recommendation. Allow users to set Text View as the default for emagazines. Always offer the “Text” link in the navigation pane, and display the image with an Alt tag in the text window. That way, screen readers can perform OCR on the image if users need access to its content.

Mac OS with VoiceOver

Most of the testing on the Mac was performed using the legacy RBdigital Media Manager, which is a side loading MP3 audiobooks utility. Testing the app in Mac OS produced the least favourable experience of all platforms. This app is a simple utility to download audiobooks previously checked out by users.

Accessibility Priorities

The following is a list of what the testers identified as top priorities for recommended improvements for the app to work well in Mac OS with VoiceOver.

The RBdigital app in Mac OS is very challenging to use for people who are blind or have visual impairments, as there are barriers that prevent the screen reader from accessing some of the features. There is a labeled link in the app to browse the RBdigital site within Safari, but testers found that almost nothing is straight forward when exploring and interacting with the app itself. This is mainly due to unlabeled buttons, and a lack of accessible options available to the users to interact with the app overall. Although the menus are accessible, the only options in them are the “Help System,” and “Creating and Managing Profiles.”

When opening the app, there are many unlabeled buttons, which makes the experience of using the app a bit of a guessing game since users are unsure where they are, or where they are going, within the app. For example, the main window contains four unlabeled buttons which appear to be dimmed, or greyed out, and testers were unable to find out what these buttons do. Even with troubleshooting by routing the mouse to them and manually clicking these buttons did not work to solve this issue.

For checking out a book, pressing the “Refresh” button inside the app will show the new book in a checkout table, but the tester was not able to read the titles of the books, and was not able to open them either.

Recommendation. Make titles clickable items so that users relying on VoiceOver can activate them using the keyboard. We would also recommend that if the user adds books using the iOS app, or the website in the Mac OS app, the books in the checked out table could have their own context menus available for them, thereby allowing for a variety of commands. This would be an intuitive way for VoiceOver users to quickly perform actions on a selected book, and would be a good option to have available for mouse users as well.

The controls to play and read books are not accessible within the app, but the app does download audiobooks that users have previously checked out in the iOS app. Once it is downloaded the user can start playing the book by finding the files associated with it in Finder on their computer, which then opens the associated files and plays them in the RBdigital app. Because the controls are not accessible, the only way in which the tester was able to stop playback was by closing the app, with Command+Q. When the tester opened the file again in finder, RBdigital did remember where the tester had left off.

It was very challenging to read the text content of ebooks. One tester was able to read a page of the ebook, but none of the usual VoiceOver commands to read worked consistently.


In this report we highlighted the main barriers of the RBdigital platform for readers with print disabilities. We also recommended some improvements to make it a better option for users relying on assistive technologies.

Testers discovered that the most important priorities across all platforms (iOS, Android, Windows and Mac) are:

By amending the development process and interface of this app, readers with print disabilities will be able to experience what RBdigital has to offer them.

Recorded Books has released new versions of their apps, but we have not tested them. As of June 28, the latest versions are as follows: iOS 4.7.7; and Android 4.7.8.


The following people contributed to this report, including testers and editors.

Appendix A: Evaluation Questions

Testers answered the following questions using an Excel document to record their findings and provide relevant details. The first questions are about the application tested, the platform and screen reader used. The rest of the questions require a yes/no answer, or a 1 to 5 rating of the accessibility of each function: 1 (not accessible) to 5 (very accessible.) If any of the questions was not relevant to the application tested (e.g. if there are no options for creating notes) testers recorded N.A. (not applicable.)

  1. Print disabilities are defined by Canada’s Copyright Act and include visual, mobility, or comprehension impairments such as dyslexia.

  2. A screen reader is software that runs at the same time as other programs in a computer or mobile device and reads aloud the text that is displayed on the screen.

  3. A Braille display is a hardware device that connects to a computer or mobile device and converts text into Braille in real time. It contains sets of pins which are raised and lowered to form the Braille encoding.