Accessibility Testing of Libby App for OverDrive

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

Report date: 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 author 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


Summary

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 Libby apps for OverDrive for people with print disabilities and found that they present several barriers for users of assistive technologies. The results show that the Libby apps have accessibility issues that constitute barriers to accessing audiobooks and ebook material.

This report presents the results of the accessibility assessment of the Libby app in iOS and Android, as well as the Windows app. It highlights the accessibility barriers of the Libby mobile apps and website, as well as 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.

Introduction

OverDrive supports two apps for reading –OverDrive and Libby– and we have done accessibility assessments of both. This report presents the accessibility experience of the Libby apps (iOS version 1.8.1 and Android version 1.7.0). As of June 20, 2019, OverDrive released new versions of the Libby app for iOS (2.0.0) and Android (version 2.0.0). The release notes indicate that both apps have some accessibility enhancements, specifically better handling for accessibility settings, like font sizing and color inversion. We did not test the newest versions for this report, and look forward to doing so in the very near future.

The Libby app provides access to audiobooks 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 app across different platforms.

The objective of testing the Libby app is to assess the usability experience of readers with print disabilities,1 and to what extent they can access audiobooks and ebooks 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 Libby app was tested on iOS and Android mobile devices, as well as Windows 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 assessment can be found in the Systems and Assistive Technology section of this report.

Information on the mobile versions of the app are presented first, and organized by sections grouping similar features, followed by information of the Windows app. 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. For the list of questions please refer to Appendix A. The last section of this report includes information on the usability of the Libby website using browsers in desktop and laptop computers running Windows and Mac 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. The Libby 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.

Summary of Priority Issues Across All Platforms

The Libby app has a range of accessibility issues in the three platforms tested; something that is acknowledged by the developer. When users relying on screen readers launched this app, a "secret message” for screen readers comes up most of the time, indicating that the Libby app is not very accessible, and recommending using the OverDrive app instead.4 Clicking the hide button did not dismiss this message, which, for the entire testing, remained at the top of users’ screens, in the active section of the app. This was the case in iOS, Android, and Windows alike. Testers said they consider this app virtually unusable by readers with assistive technology as it is.

While testers could search and borrow titles, accessibility barriers prevented them from actually listening to audiobooks or reading ebooks, which is the essence of the app. With the recommended improvements laid out in this report, the Libby app would make a better option for users with print disabilities relying on assistive technologies.

The most important priorities across all platforms (iOS, Android and Windows) are:

iOS with VoiceOver

The iOS version of Libby has many accessibility issues. In general, there are many unlabeled buttons where VoiceOver will just say “Button.” Testers also noted that there are other buttons and links that are labeled in an unclear manner, which do not explain to the user what their functionality is; this includes wordy and/or repetitive labels. For example, some links share the same label, and even when looking at the surrounding text or controls it was difficult to determine what these links do.

It was also noted that the “Menu” button on the main screen did not react when a tester tried to access it with the double-tap gesture. If this button displays new content, VoiceOver is not able to read it. This suggests that those users relying on VoiceOver are likely missing the ability to explore some of the app's functionality, with one tester reporting that they could not find the settings screen.

VoiceOver uses flick gestures to go through the order of controls. Ideally, VoiceOver will read controls from top to bottom, left to right, and the elements displayed on the screen should make sense relationally to this approach. It was found by testers that the flick order of controls is not defined in an order that is compatible with the screen reader. These elements include the “Menu” button, “Loans,” “Tags,” and “Activities” tabs to name a few. As it is currently designed, these elements appear near the bottom of the flick order when swiping through the app, but visually they are displayed at the top of the page. This can be confusing to the user as they are trying to navigate through the app, and functionality would be improved if the elements read by the screen reader matched the order that is presented visually.

Testers discovered that VoiceOver would often read a field not currently displayed on the screen, and would instead read the last field that was accessed by the screen reader; this is termed “backfield interference.” As old dialog boxes stay on screen when new ones appear, the focus does move to the updated portion of the screen, but this is not always the case. When focus remains on the old dialog, it can cause confusion and user frustration. Testers did note that there are sometimes spoken cues that are helpful, such as “You are on loans,” but in general the backfield interference occurs enough to have a negative impact on accessibility.

There was also an issue with the screen reader maintaining focus for popovers. This meant that the user had to search the entire screen to locate the popover, since its content mingles with the rest of the content on the screen. This lack of focus for screen readers when interacting with popovers makes them not only hard to find, but also hard to close. They also reported that pull-down menus cannot be closed at all, with one tester reporting that this particular issue resulted in them needing to restart the app 14 times in a 6-minute period.

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

The Android version of Libby has similar issues for users relying on TalkBack, including backfield interference and unclickable buttons and links. These elements were also found to be labeled in an unconcise manner, or not labeled at all. For example, one tester noted that links on the Library Interface repeatedly read as “Shevron” and “BubbleTail.”

Testers reported problems with scrolling. When TalkBack is enabled, screens in Libby cannot be scrolled. Testers also found that TalkBack frequently reads pulldown menus as if they were visible, although visual confirmation indicates they are not. This makes swiping down to activate content cumbersome, and, most importantly, presents options that cannot be selected because they are not really on the screen.

It was also found that the information on the different screens is separated into what seems like random different sections without any clear headers, which makes it hard to know if the different sections are related. For instance, there is text that indicates what the user can do in a certain text box, but it was not clear what text box the content is related to. When a tester did find a text box, it was challenging for her to find the buttons below it in order to interact with it.

Overall, testers found it very challenging to listen to audiobooks and read ebooks due to, among other issues, unlabeled buttons and problems with scrolling. These issues are further described below in the corresponding sections.

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 us 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: http://www.daisy.org/accessibility-screening-methodology-guidelines-and-checklist.html

Six testers with print disabilities reviewed the Libby 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 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

Libby Application Versions

Operating Systems and Assistive Technologies

Libraries

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

Notes

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 Libby mobile apps and website. The Libby 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.

Testing Results and Recommendations

In this section we dive deeper into specific accessibility issues of the different features of the Libby 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 list of questions, please refer to Appendix A.

Library Access

For this evaluation, Library Access includes all features related to accessing Libby and the content it offers through a user’s public library, including signing-in, searching for audiobooks or ebooks (including filtering searches,) downloading and removing books and publications.

Signing In

iOS with VoiceOver

Testers were able to sign in, although they encountered unlabeled buttons. They also found the scrolling single-page design to be less intuitive than the average sign-in screen. After each step, the testers had to scan down the screen with a finger to check if any new content had loaded.

Recommendation. Ensure that VoiceOver can read any alerts to indicate to the user whether the screen changed, or if they made a mistake when entering their library card PIN.

Android with TalkBack

Testers found that the sign-in screen consists of a series of simple questions, but after the tester answered one and proceeded to the next, TalkBack would reread the answered question (even though it was no longer visible on the screen.)

Recommendation. Ensure that each screen of the user interface is free and clear of old controls and text.

After the testers entered their library's name, they were then presented with a button for the correct branch. When they selected this button there was no response. The tester discovered that they first had to close the keyboard before the button would appear to be clickable. There were also issues reported with the Library Card and Pin boxes. The Pin box area is directly after the Account Number, but it could not be filled until the “Next” button was selected. Having items appear to be functional, when in fact they are either hidden, or need more steps taken before becoming functional, does not match accessibility standards and causes high levels of user frustration.

Recommendation. Ensure buttons and controls that are not visible on the screen cannot be read by TalkBack, and simplify the steps to enter information and navigate text boxes.

As testers worked to enter the correct information in the boxes, the app kept trying to sign in before the Account Number and Pin were filled in correctly. Testers reported that this process took several tries before they were able to sign in. One tester noted that the first time they had to swipe all the way to the bottom to correct the information, but the second time it was necessary for them to start at the very beginning of the sign-in process.

Recommendation. Improve functionality of the sign-in section of the app to allow users relying on TalkBack to enter their information independently.

Searches

This applies to all content types—ebooks and audiobooks.

iOS with VoiceOver

Testers noted that the search field is properly labeled, however, it is difficult to determine where it is located since the flick order does not match the positional elements on the screen—as mentioned in earlier in this report. Having said that, one of our testers was quickly able to locate the search field when they moved to the bottom of the screen and then swiped back a few times. Overall, there were different results from different testers, with some being able to find it at the bottom of the screen, while others could not find it at all. In these cases it appeared to be hidden, even as these testers explored the same area of the app.

Recommendation. Make the search box appear consistently in one place, so that all users can access it.

Although the filter categories under search were found to be fairly accessible, when the tester selected a filter there was no notification that the options had appeared. The tester was able to find them at the bottom of the screen, and not close to the filter category area.

Recommendation. When the buttons for the filter categories are clicked, the user should be able to find the different options close to the same area. For VoiceOver this would be with a flick to the right.

Navigating the search results and the curated lists is easy since the layout for both sections is the same. Also, the relationship between elements in the list made sense when flicking through, and when the tester used explore by touch. The tester reported that they could easily find each item as well as their associated buttons.

Recommendation. To make the list even more accessible, add headings for each book title. This would speed up a user’s ability to quickly go through a list.

The "Refine List" element was noted to be cumbersome and time consuming to use. Testers noted they were able to filter criteria on the list, but they had to go in and add one item at a time, and then click on "refine refine list”, as they could not choose all the options they wanted at once. They also noted that each category has the word “chevronright” at the end of each category title, such as “language 1 of 1 chevronright”.

Recommendation. Improve functionality for filtering by allowing users to select several categories at once, and relabel the categories.

While the book information screen was fairly easy to navigate, and flicking order made sense, testers found that the “Borrow,” “Read Sample,” and “Tag” controls did not indicate their role as button or link.

Recommendation. Ensure all controls can be identified by VoiceOver as functional and clickable.

Testers found that images did not have any alt-text, which meant that this content is completely inaccessible to users relying on assistive technology. While they did find that the tables were marked up properly, it was noted that the cells containing the author and publisher information had extra text that read “chevronright”.

Recommendation. Ensure that images have alt-text, and clean up any extra text that could be picked by screen readers.

Testers noted that it was time consuming to navigate through the search results, as they were not clearly separated. One way of separating information, which is compatible with screen readers, is to add headings. By creating a clear and navigable separation of sections, users will have the ability to quickly move focus to different elements by using shortcuts to buttons, headings, landmarks, and more.

Recommendation. Add a heading for the beginning of the main content, and another one for the synopsis, to provide for efficient navigation to those sections.

Android with TalkBack

Testers found that they could search for titles and navigate through the list of search results. Nevertheless, they did report a similar issue to VoiceOver with the location of the options at the bottom of the screen being hard to locate, and navigate to. If a user relying on TalkBack chooses either the “List Preferences” or “Refine Refine Search,” they have to explore by touch to find where the options appear on the screen. Testers noted that if they swiped to locate these options, it would be time consuming due to issues with scrolling using gestures. For instance, while users can flick to the right from the top field, when they try to swipe to the left from the bottom, the focus gets stuck at the top boundary web view element containing the content. This makes it difficult to go to an element near the bottom of the screen.

Recommendation. Fix scrolling issues to enable TalkBack users by swiping left from the bottom as well.

Checking Out Titles, Browsing the Bookshelf and Removing Titles

iOS with VoiceOver

Four of the five testers found that borrowing books is a simple process that they could accomplish with VoiceOver.

Android with TalkBack

Accessing the bookshelf worked well, with the options to Borrow, Return, Place on Hold, and View the holds list well labeled.

Reading, Listening and Navigating Content

Audiobooks

iOS with VoiceOver

None of the testers could successfully play an audiobook. When they press the “Open” button from the Library, the screen that comes up has many controls that have confusing labels. Even with troubleshooting, testers could not figure out most of the functions of these controls. For instance, there is a jpg image that has a long string of hex characters between curly brackets {}, followed by "Img100.jpg". Testers also discovered many controls that were visible as they swiped right, but proved to not be functional when they attempted to select them. For instance, there are sets of three unique controls (each containing a hyphen, a number, and the letter S) that VoiceOver read as: "-5S", "-10S" and so on, all the way to "-60S". Testers were also able to find controls for time for the audiobook (e.g. "7 hours, 15 minutes, and 0 seconds",) but again, when they tried to interact with this control nothing seemed to change.

Recommendation. Ensure all buttons are labeled appropriately and are responsive and functional with VoiceOver gestures.

One tester was able to locate the "Now Playing," "Library," and "Shelf" tabs across the bottom of the main screen, but noted that these buttons need enough padding to fill the entire bottom strip of the screen to avoid users relying on gestures from accidentally touching content that surrounds the tabs. The way they are set up at the time of this report, it is easy to accidentally touch the space between them, which will usually just announce the control above, but could still lead to user confusion. The tester did note that on pages such as Loans, this behaviour doesn’t happen; the user can touch anywhere at the bottom and reliably find a tab.

Recommendations. Enlarge icons to enable VoiceOver users to find them quickly and efficiently.

Android with TalkBack

Testers were able to read the book description when an audiobook was opened, but the controls were almost completely inaccessible. It was noted that the “Play” button is a graphic, which is found between “Library” and “Shelf.” This button is too small to find by tapping around the screen, and even more difficult to click to activate once it is located. Once it is activated, the “Pause” and other navigational buttons are also just read as graphical buttons.

Recommendation. Ensure all buttons and controls are large enough to be activated by gestures, and that they are marked as functional controls.

One tester noted that when he closed the app, the audiobook continued to play. Since he was no longer in the app, it was frustrating and difficult to get back into the app to select the “Pause” button because the audiobook was talking over TalkBack.

Recommendation. Consider adding a setting for screen reader users to select an option to stop audio when they close the app.

It should also be noted that the “Mute” button can cause serious accessibility issues if it is not properly designed; a user could accidentally mute the app without being aware of what they did.

Recommendation. Ensure that the “Mute” button has a notification option of a yes/no confirmation dialogue before it can be activated.

Ebooks

iOS with VoiceOver

The section of the app to read ebooks contained some unlabeled buttons as well. Testers also noted that the internal links did not work when selected, and they were therefore unable to navigate the content. Although they could view a single page of an ebook at a time, they were not able to successfully turn pages. Chapters themselves do not appear in VoiceOver's navigation order, and there is no indication that the chapters screen is open. One tester found that the “Back” button and all other buttons on the screen stopped functioning until they pressed the "Chapters" button. It should also be noted that the same tester discovered that sometimes this action froze the app, and at other times simply opening the ebook froze it as well.

Recommendations. Label all buttons and ensure that buttons and links can be activated with VoiceOver. Enable scrolling of the text with VoiceOver gestures.

Backfield interference was also an issue in this section of the app. When going from the Loans menu to an ebook, VoiceOver would read the previous screen instead of the actual ebook. This made it impossible for testers to read any content.

Recommendation. The screen should be clean of old text of controls when the user moves to a different page or section of the app.

Android with TalkBack

Testers found that when an ebook is opened, that visually only small parts of the text were rendered, and it was also not possible to scroll through the content. Through trial and error, one tester located two unlabeled buttons that were found to skip forward and back. It was also discovered that there are many other unlabeled controls on the ebook page that TalkBack does not recognize, and seemed to not activate when clicked.

Recommendations. Label all buttons and ensure that buttons and links can be activated with TalkBack. Enable scrolling of the text with TalkBack in this section of the app.

Backfield interference was again reported; with one tester noting that when they navigated away from the ebook to another section of the app, the screen reader continued reading the ebook screen. This made it impossible to navigate to any other section since the screen reader failed to read any content or elements in the new section.

Recommendation. The screen should be clean of old text of controls when the user moves to a different page or section of the app.

Visual Adjustments

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

iOS

Although it is possible to change the size and type of the font, and to change the colour of highlighted text, there is no option to change the colour of the background text. The tester discovered that under Reading Settings > Book Design, there are pre-defined style themes, such as Open Dyslexic. There are also a few options for font and background colours here, but it is not possible to select a specific colour of choice for the font or background. The tester also noted that one of the available themes is called Bright, which offers white on black text, but found no other option to change brightness. People with low vision should have the options to change the colour of the font and background to fit their needs, such as yellow on blue. It is also important to be able to adjust font style, size, kerning, and line alignment.

Recommendation. Allow for customizable font and background colour, as well as wider options for font style, size, spacing and alignment.

Android

It is easy to change font size, colour, justification, and style. Though, again, it would be better to have more customizable colours, so the reader can create a contrast that works best for them. It is good to see that the dyslexic font is available. The tester did discover though that the number of choices for other font types was very limited, with only Serif and Sans Serif as options. It should be noted that the iOS app has six choices.

Recommendations. Increase the selection for font types and consider providing more options to change text and background colour independently of each other.

The Libby App in Windows with JAWS and NVDA

In this section we present results from the assessment of the Libby Windows app. We highlight the main aspects of the app and the accessibility priorities, followed by descriptions of the main features of the app with recommended improvements.

Summary

The main screen appears to JAWS and NVDA as though it's a webpage. Testers found it possible to arrow through all of the content on the page, which the screen reader identifies as buttons. They reported that the main screen is mostly readable, until they reached the bottom where they encountered several unlabeled buttons whose function is not clear even after selecting them. As with iOS with VoiceOver, selecting the "Menu" button did not seem to change anything about the page. When other menus, or popover screens, were located and opened there were no notifications that they had in fact opened, and the options within usually appeared well below the button they clicked.

Testers reported that, similar to the Android experience, links on the Library Interface repeatedly read as “Shevron” and “BubbleTail.” The tester assumed these are icons for some visual purpose, but found it frustrating to hear the screen reader repeating their descriptions constantly.

It was also noted that multiple blank lines break up the content in various sections of the app, which are read as "lones;". These blank lines are between the top navigation and the page content, and testers reported that it was frustrating and time consuming to skip them. For example, the Home Library page has six blank lines near the bottom, between "Subjects and Spotlights,” and the Search Menu. These types of breaks are commonly used to indicate that the end of a page has been reached, but in this case they have been over used. A single blank line would be more user friendly.

Overall, the screens were found to be cluttered with too much information and no options for navigation. For instance, a tester noted that after opening the “Help” and “Advanced Search” features, they could not close them. As these features stayed open, they added further clutter to the interface. Therefore, the longer they used the app the harder it became to use. The only way to declutter the screen was to close and reopen the app. A consistent approach is crucial to efficient navigation with adaptive technology, and very little seemed to be consistent in this app. For instance, at some point throughout one tester’s exploration of the app, the buttons to return to Library and Bookshelf vanished from the bottom of the page. Testers also found that there are rarely headings or landmarks to indicate different sections of the screen. This means that users relying on screen readers may not know whether new content loaded, whether the part of the page that changed is the desired section, or, in the case of unlabeled buttons, what the button does and where they should expect to be after they press it.

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.

Specific Features

The sign in process was fairly accessible, but testers noted that it was time consuming. They reported that each new step appeared below the last, and rather than changing the entire screen each time; this meant that testers had to scan through all the buttons from the previous steps to get to the next one. While the screen reader announced some screen changes later on, it did not announce anything when confirming each step.

Recommendation. If the single-page style is necessary, we recommend making each step a region and adding a consistent Level 1 Heading to the beginning with a descriptive name. The screen reader also needs to get a notification that confirms that the last entry went through, or announce that there was an error.

One tester tried using the option to import their card from another device, but found that it was not possible for them to find the text field to enter the library card pin. They also noted that there were three unlabeled buttons that seemed to do nothing when clicked. Another tester noted that while the process to sign in with the library card was possible, a press of the Tab key did not move out of the edit fields; these fields had to be closed with the Escape key. This creates what is known as a "keyboard trap" and can make the functionality of the interface for people used to standard keyboard navigation incredibly hard to interact with.

Recommendation. Ensure that all text fields and controls are operable using the keyboard, and ensure there are no keyboard traps.

The search feature at the bottom of the page worked well, although the “Search” button does not appear until "More Options" (Advanced Search) is clicked. Otherwise, the only buttons are "Clear Search" and “Cancel.”

Recommendation. Fix functionality of the “Search” button on this page so that users don’t have to click on “More options” to access it.

In the search results page, testers could not find a way to determine whether a title is in audiobook or ebook form. When they selected a title, the screen reader would read out “Star Rating” five times. Testers were also unable to accessibly view book information, such as publisher. As with the other platforms, testers reported that it is time consuming to navigate through the results page, and noted that headings would help to separate the results.

Recommendations. Provide format information in text form next to the book’s title. The graphics to rate titles should all be placed on one line so they can be skipped more efficiently. Add headings to each search result so a screen reader user can navigate to them more easily.

The same issues came up with the filter options being located at the bottom of the screen. The available filters show up near the bottom of the page, and when the tester clicked on a filter, the options for that filter showed up at the very bottom of the page.

Recommendation. Consider making the filters into submenus that bring up their options directly beneath.

Testers found that functions for checking out titles, browsing the bookshelf and removing titles were less accessible for Windows users with JAWS and NVDA. The issue of blank lines was even more problematic on the screen to borrow books; one tester found that there are around 30 consecutive blank lines between the top of the page, and the borrow confirmation button. It was also noted that there is no tab key navigation on the Loans screen; tabbing should be built into each page to match best practices.

Recommendations. Enable keyboard navigation on the Loans screen with tabbing, and eliminate unnecessary blank lines.

Overall, testers were unable to play audiobooks. All testers reported there were many unlabeled buttons, and they were not sure what their functions were. One tester was able to play an audiobook by accident when trying to determine the functions of the unlabeled buttons.

Recommendation. Label all buttons, and ensure that all controls are operable from the keyboard, without a mouse.

Testers were also unable to reliably access ebooks in the Windows app. It was noted that there is an unlabeled button next to each title, regardless of format. It was found that this button sometimes opens the title, but not consistently. It was also discovered that selecting the “Chapters” button did not actually load those chapters, and it did not close the Table of Contents. There was also no separation between some elements, even though they are visually part of a different button group. For instance, a tester noted that there was a “Menu” button directly after an ebook at the bottom of their library, but it was not clear if this button is part of the bottom navigation, or an action button for the ebook itself. When the button was selected there seemed to be no change.

Recommendations. Label all buttons, controls, and links, and ensure that they can be activated via the keyboard, to allow screen reader users to access ebooks.

The Libby Website in Desktop and Laptop Computers

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

In this section of the report we highlight the problematic issues as they relate to the different parts of the Libby website as it was tested in Windows (Firefox and Chrome) and Mac OS (Safari) browsers in desktop/laptop computers; but we do not elaborate on each of the features. Since many of the findings related to the website are similar across the different sections and in both platforms, we describe these issues more broadly, and present specific examples to illustrate some of the barriers.

Overall, testers accessing the Libby website using browsers in Windows and Mac OS reported that while they could use sections of the app, they could not read ebooks or listen to audiobooks.

Windows Browsers with JAWS or NVDA; Safari Browser with VoiceOver

It was noted for both platforms that there are barriers to access the website with screen readers. These barriers are explored in more detail below. Overall, this makes the usability experience confusing, time consuming, and frustrating.

Similar to all other versions of Libby, all testers found that the "secret message for screen-readers" did not disappear after pressing the hide button. They did note though that the sign in process is quite simple and easy to use. However, testers discovered that each new step appears below the last one without any announcement of a screen change. As there is no confirmation, users must enter a piece of information, and then scroll down the screen to find out whether it actually changed or not. This process is not intuitive for screen reader users.

As with the in-browser apps, testers of the website noted that they could not figure out how to close popups, such as Table of Contents. This resulted in extra controls that persisted on the screen, and could not be dismissed.

There is also an issue with separating different elements and areas of the website. For example, the ebook Menu appears at the bottom of the page in Safari, which is the same area where the main navigational controls are located. For any user relying on a screen reader this section will read as one continuous group of buttons, which can cause confusion and frustration when trying to navigate through an ebook and accidently navigating to a new page of the website. It was also discovered that there is no clear separation between titles when browsing a collection, or on the search results page. To troubleshoot this, the user must move to the next button, which navigates to the “Author,” “Title,” “Borrow,” “Sample,” and then the “Wish List” buttons for each title. This type of navigation is not intuitive for screen reader users, and can be slower since there are so many buttons they have to scroll through for each title.

As previously mentioned, there are many controls which have unclear or missing text labels. There are also buttons labeled as "mascot" everywhere, but testers were not able to determine what they do, they did not work when pressed. There are also other controls that appear to not be activated when selected, which include a "Back To" button and a "Dismiss" button. Though searching was accessible, the buttons to adjust preferences, such as format and language, seemed to have no effect when selected.

Like in the mobile versions of the app, testers using websites in their computers were unable to listen to audiobooks or read ebooks. Nearly every button related to navigation was found to not have a text label. Testers were not able to turn pages in an ebook, play or pause an audiobook, or adjust reading settings. As well, they could not find a way to close the reader; one tester reported that they frequently had to go to the address bar and delete the part of the URL after "libbyapp.com" in order to return to the homepage and test something else. This is a cumbersome workaround that is not user friendly.

We would recommend the following changes, which should greatly improve the usability experience for the website across all platforms:

Conclusion

In this report we highlighted the main barriers of the Libby platform for readers with print disabilities. We also recommended some improvements to make it a better option for users relying on assistive technologies. The most important priorities across all platforms (iOS, Android and Windows) include: Label all buttons, controls, and links to convey information of what they are to users relying on a screen reader; and improve functionality of the audiobook player and ebook reader, which are mostly inaccessible for screen reader users.

We do take into account that Libby is aware their app is not accessible, and we hope that our recommendations will help improve the apps across multiple platforms. Some of the issues could be fixed easily, since the app appears to be using an embedded web-view. This would only require fixing some of the web code. Some sections, such as the ebook viewer and audiobook player, would require more work to provide access to those features. By amending the development process and interface of this app, readers with print disabilities will be able to experience what Libby has to offer them.

As of June 20, 2019, there is a new version of the Libby app for iOS (2.0.0) and Android (version 2.0.0). We did not test the new versions for this report, and look forward to doing so in the very near future.

Contributors

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 answers 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) and 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.↩

  4. The text of the “secret message” in the iOS app reads: “Welcome to Libby! This is a secret message for screen readers. We are working to improve your experience with this app. In the meantime, our OverDrive app is more accessible. You can find it in the app store. We thank you for your patience.”↩