Accessibility Report for Hoopla

July 2024

PDF | DOCX

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.

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 ebooks for Canadians with print disabilities, and an advocate for an accessible and equitable reading ecosystem for Canadians with print disabilities[1]. 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.

Accessibility Summary

The Hoopla website has significant accessibility enhancements which go a long way toward making content accessible to as many users as possible. Sections of the mobile applications are less pleasant, but experienced users can access core functionality of the platform. There are many accessibility barriers discussed in this report, but most of them are cosmetic and create confusion or inefficient usage rather than blocking access to functionality altogether. In some instances, Hoopla has tried to create a more accessible experience but has made usage less efficient. Text appearance within ebooks is highly adjustable on all platforms, and some titles have image descriptions which are rendered correctly in the web-based ebook viewers. Comics are not accessible to screen reader users, and none of the tested videos contain audio description. The inclusion, searchability, and filterability of accessibility metadata for all formats would be an extremely useful enhancement and it would set Hoopla apart from other library reading applications.

Introduction

Hoopla is a platform that provides access to ebooks, audiobooks, music, and videos through a website and mobile applications. Readers of participating public libraries can sign up for a free Hoopla account and borrow a set number of titles every month.

Our testers used screen-reading and magnification and screen enhancement software to assess the usability of the Hoopla website, iOS app, and Android app. The Systems and Assistive Technology section of this report contains a complete list of all the software and operating systems used in this assessment.

This assessment aims to determine the usability experience of readers with print disabilities and to what extent they can access Hoopla effectively and efficiently. While this report aims to provide an overview of the accessibility performance across supported platforms, this is not an in-depth review of Hoopla itself. As a result, some functionality may not be discussed at all or in-depth.

Introduction to Assistive Technology

All mainstream operating systems include built-in screen readers (Narrator on Windows, VoiceOver on Apple devices, and TalkBack on Android) that read the contents of the screen out loud, allowing users with visual disabilities to browse apps and websites, send and receive texts and emails, and accomplish many other tasks with ease. Keyboard commands and custom touch gestures provide a flexible way for a user to find and interact with the controls on-screen. Windows also has alternative screen-reading software available, most notably a commercial option called Job Access with Speech (JAWS) and a free and open-source option called Non-Visual Desktop Access (NVDA). The text spoken by a screen-reader can be sent to a refreshable Braille device. Mainstream operating systems are also equipped with user interface magnification, large text options, and high-contrast viewing mode to assist people with low vision.

To ensure usability and accessibility of an application by people with print disabilities, all functions and controls must be accessible using assistive technologies. The DAISY Consortium explains that the basic assumption of accessibility evaluations is that reading systems “should support reading with eyes, ears, and fingers.” (DAISY Consortium, 2017). It should be possible for users to read the content of the document by:

  • Reading the text with screen readers or self-voicing text to speech (TTS) applications.
  • Adjusting the display, including font size, alignment, and colour contrast, or a combination of some or all these options.
  • Reading the text with a refreshable braille display.
  • Reading with assistive technologies designed for persons with dyslexia or other disabilities.
  • Reading with the app’s built-in read-aloud functions.

Accessibility Performance and Recommendations

This section will dive deeper into specific accessibility issues encountered while testing the Hoopla website and mobile applications. Below are the testing results and their related recommendations as they pertain to:

  • Sign-Up and Login
  • Layout and Navigation
  • Searching and Browsing
  • Reading, Listening, and Watching
  • Visual Adjustment

Finally, the development recommendations sections contain suggestions for improving the interface on each platform. These suggestions will be relevant to any issues or observations noted above.

Hoopla Website

The Hoopla website was tested with a variety of desktop operating systems, browsers, screen readers, and magnification.

Logging In and Signing Up

While signing up does require a library card, the login process for Hoopla is e-mail based. The top of the Hoopla page has a login link, which was easy for all testers to locate. Further down the page, a “Get Started” link allows one to register for a new account. Both the login and registration pages are pop-ups, and both contain a back button with no screen reader label. A MacOS screen reader user noted that when first loading the registration page, VoiceOver was unable to read any of the web content. A page reload resolved this issue.

On the registration page, a list of libraries is presented. This is based on location but can be refined or modified by way of a search box. Each library choice is presented as a button, and while screen readers can activate these buttons, there is no indication of which library has been selected. Typically, these controls should be presented as radio buttons since only one can be selected at a time.

If the desired library is not in the list of choices, a search box allows users to find a specific library based on location, name, or postal code. Typing into this field will automatically narrow results, and the page will correctly indicate when no results were found. VoiceOver on MacOS exhibited unusual behaviour in this text field: When attempting to type into the field, despite the VoiceOver cursor focusing on the correct control, the text was entered into the address bar instead. To resolve this, the user needed to press “vo+space” to select the text field. The same behaviour can be observed when entering a library card number and PIN.

When pages dynamically update their content without reloading, screen reader users are not warned of these changes. The addition of an automatic announcement for errors and search results changes would be helpful, especially when the search query returns no results. The “You must select a library to continue” error is also not announced by screen readers. Typically, this is accomplished with an ARIA live region which populates with screen reader announcements.

On the login screen, there is one additional unlabeled button for toggling password visibility. Screen readers cannot identify it, nor can they determine whether the button is selected or not. Using a similar format to the “Remember Me” checkbox would alleviate both these problems.

A low-vision tester noted that the logout button has a low contrast ratio when using colour inversion, and suggested using the same design as the borrow button for increased visibility.

Home and Navigation

For screen reader users, the top navigation and search are quite well-structured. Buttons which invoke a menu are marked up with ARIA to indicate whether they’re collapsed or expanded, and the menus are fully keyboard-accessible and can be navigated with the arrow keys. The control for navigating to the homepage is seen as a menu item by screen reader users; a link would be easier to find.

Many low-vision users make use of dark mode, and the addition of a dark mode on the Hoopla website would be very welcomed.

On the homepage, a slideshow of promotional content continuously scrolls. This can be paused, and each slide can be individually pressed. For screen reader users, this is problematic for a few reasons.

  • Each of the promotional slides has a slightly cryptic screen reader label, such as “A promotional notification for BP_MW_GetHealthyUTV6-19-24”. This doesn’t adequately inform the user of the type of content. A more useful and engaging text label would go a long way toward making this section of the interface more user-friendly.
  • Below the active slide, a list of buttons allows one to move to specific slides. Because each button is a separate control and there are often more than ten available slides, these buttons create page clutter for those wanting to explore the interface top-to-bottom, or those who are navigating with the keyboard. A more user-friendly approach could consist of changing the individual buttons to a single slider which contains all the slides, and which can be navigated with the arrow keys.
  • Finally, there is no heading or other separation before the help text informing users of how many titles they can borrow, so users who move past the slideshow by going to the next heading may miss this text altogether. The text is directly above the “Recently Borrowed” heading.

The rest of the homepage consists of categories such as “Recently Borrowed”, “Recommended for You”, and “Trending”. Each of these categories begins with a heading and seems to use a carousel view to display a single recommendation at a time. For some of these categories, a “See More” link is available and will open the complete list on a single page. For others, the only way to navigate through the items is by repeatedly pressing the next button. This is cumbersome for screen reader users, and a low-vision tester on MacOS noted that scrolling with the mouse does not work either.

The previous and next buttons have a screen reader label of “Click to see next(/previous) titles”, which suggests it is possible to display more than one item at a time, but the interface seems to only display a single item. These labels are also unnecessarily verbose.

Browsing

The “Browse” button is part of the top navigation on every Hoopla page. When expanded, the menu includes options for all content types as well as binge passes.

Typically, after choosing one of these categories, the resulting page will be formatted much like the My Hoopla page, but with different category names based on the chosen content type. These pages still include a slideshow of promotional content with the same issues noted above, as well as a collection of carousels featuring titles in the chosen format. These carousels also feature Next and Previous buttons and only display a single title at a time.

Each carousel includes a “See More” link, which displays a full list of all the featured results on a single page. Depending on the carousel chosen, this might be a list of books or a list of genres. The list of genres is simply a long list of links, which sometimes lead to a list of subgenres using the same page format, and sometimes lead to a list of titles. Lists of titles use the same format as search results, which will be covered below.

Search

The search box is available near the top of nearly every page. An NVDA user found that when keyboard focus is moved to the search field, the screen reader sometimes loses track of the focus and instead announces that it is focused on a menu. Some investigation reveals that the menu of search suggestions seems to gain focus, even though key presses will successfully type into the search field. Since the screen reader is now focused on the wrong control, there is no speech or braille feedback when entering text, navigating the entered text, or deleting with the backspace key. Pressing shift+tab followed by tab appears to temporarily focus the text field correctly, but focus will sometimes jump back to the menu unexpectedly. Ideally, the outer menu should never be focused—only the suggestions which are menu items inside it, and even then, only when the user presses up or down arrow. As soon as text is typed, focus should drop back to the text field. As it stands, it’s necessary to move away from the text field and manually review search suggestions using screen reader navigation commands. Each search suggestion is also a separate tab stop, making keyboard navigation quite clunky in this area.

The control to change search category has quite a verbose screen reader label, as do the menu items revealed by the control. The button itself is called “Currently searching within Everything. Click to change the search category.” This is accessible, but most users would find a shorter label preferable, such as “search category: Everything”. The screen reader would indicate the collapsed button, and the typical user would intuitively understand that expanding the button will reveal more search categories. Each menu item also uses this kind of language, e.g. “Click to search within Television”. At minimum, the “click to…” should be removed, as screen reader users are rarely using a mouse.

The advanced search page has no accessibility issues apart from an improperly-labeled close button. It uses the × symbol which causes most screen readers to announce it as “times button”. Experienced users will still know what it means, but adding an ARIA label would go a long way.

After searching, the results load without any screen reader announcement and the search suggestions remain navigable below the search field. It is necessary to go to the next level-1 heading to find the actual results.

Search results use the same format as browse results, so the below information applies to both.
The Format, User Rating, Release Date, Date Added, and Language filters are technically accessible to screen readers, but they’re lacking some of the markup that would make them truly intuitive and easy to use. Each filter is a button, but there is no reported collapsed/expanded state. When the button is activated, there is no screen reader announcement to indicate the options have loaded. The escape key does not close the options or even return keyboard focus to the filter button. Lastly, unlike the other buttons which invoke a popup menu, each filter option can be reached with the tab key and the arrow keys will not move between these options. This makes keyboard and screen reader navigation more cumbersome than necessary.

The format of the list of titles has been modified for screen readers: Each title is under a level-3 heading and includes the book cover, title, author and format. However, screen reader users are presented only with a list of links to each title using an attribute called aria-label. Because the level-3 heading is contained inside the link element, this modification removes the headings altogether for screen reader users, though headings are not strictly necessary since each result is only a single link. More importantly, the modification removes the format, so screen reader users cannot determine whether a browse/search result is an ebook, audiobook, or something else. This page would have been completely accessible without any modifications, so it’s unclear why these controls were designed in such a way. With the aria-label removed, there is some redundant page clutter because the alt text of each book cover is set to the title of the book, but this is also not correct—if there is no photo description and the title is written elsewhere, the alt text should be set to an empty string (alt=””). When this is done, the page is completely accessible and easy to navigate by headings—no overengineered aria-label required—and the format of each title is clearly shown as well.

If the aria-label is retained, a heading directly before the list of results would help facilitate more efficient screen reader navigation, as users currently need to move past the filter controls or use link navigation to find the first result. “Next” and “Back” links are placed before the list of results when applicable, allowing easy page navigation. As with other page changes, the page itself does not fully reload, and screen reader users are not notified that new content has loaded after activating these links. There is also no separation between the list of results and the pagination links at the bottom of the page. Again, a heading would be helpful.

Title Details

Since Hoopla has many types of content, the title details pages for each differ slightly. However, many of them share common characteristics. These include a set of rating buttons which have no screen reader label—they simply read as five blank buttons in a row. After rating a title, the selected rating is not indicated to screen readers and is indistinguishable from the other rating controls, so screen reader users are unable to determine their own rating choice. The average rating is also not shown to screen reader users, if it is available.

On details pages that include descriptions, the “See More” or “See Less” buttons appear to have their labels reversed for screen reader users. When the “See Less” button is pressed, it causes the full description of the item to appear, but the label changes to “See More”.

When selecting the “Borrow” button on any title, keyboard and screen reader focus is correctly shifted to the pop-up, which is fully accessible apart from a “×” button which closes the popup. The escape key also works as expected. Notably, this confirmation popup never specifies the name of the item being borrowed; this is not required but would be a useful aid in case a user accidentally selects the wrong borrow button on a page with multiple borrowable titles, such as a list of TV episodes.

On many detail pages, the title of the book is at level 1, and then the structure jumps to level 3 for “Find similar titles by category” and 4 for “Similar Artists”. These could be levels 2 and 3, unless it has been done this way for consistency with other pages. On pages with TV episode lists, the heading hierarchy is also not consistent, with the “Episodes” heading at level-4 and each individual episode under a level-2 heading. Further episode details are under a level-3 heading, which causes the page to be more cluttered for screen reader users moving by heading.

Depending on the screen reader used, the episode number and length can sometimes run together, creating confusing lines such as “EPISODE 145 min.” This seems to happen because both pieces of information are within the same level-3 heading and separated by a line break.

Currently Borrowed

A list of borrowed titles can be accessed from the My Hoopla menu. This is a minimal interface that specifies the number of remaining borrows and shows all currently borrowed titles. As with other lists of titles, each list item has been given a screen reader label which attempts to rewrite the interface in a more user-friendly way, including the use of commas for speech pauses. In doing so, it removes screen reader access to the book details page, which should be reachable by activating a link. Since only one control is seen per-title, screen reader users are not able to navigate to the details page for a book. This modification serves as another example of needlessly overengineered accessibility which removes useful functionality and doesn’t solve any real-world problems that couldn’t be solved by improving the page layout. While speech pauses might be useful for some users, others will access the site using a braille display, or a screen reader configured to read commas. Having each title under a heading and each author on a separate line would be much more user-friendly and would require very little in the way of duplicated or reengineered labels. Additionally, the screen reader label for ebooks is incorrect—it should say “Continue Reading”, not “Continue Playback”. Alternatively, this text could be normalized to “Open” or “Resume”.

Ebooks

The web-based ebook viewer opens after borrowing a title and selecting the “Read” button. It is contained in a modal, and some screen reader users found that the reader did not automatically gain focus until the tab key was pressed. The same problem persists when opening other popups such as the settings dialog, and in some cases, switching to a new chapter caused keyboard focus to leave the reader. Using the newer dialog element is one way to avoid this problem, as it contains such accessibility features by default.

The “Reader Settings Menu” screen reader label is misleading, as it suggests the button should only reveal settings. In fact, the menu contains several functions including search, bookmarks, chapters, and an option to close the reader. A better label could be “Menu and Settings” or just “Menu”.

When first opening settings, the new dialog often does not gain screen reader focus and depending on the screen reader, users may need to manually interact with it. Within the settings screen, most of the controls have unhelpful or missing screen reader labels—for instance, the toggles for bold text, scrolling view, and dual-page view all have a label of “Use Setting”. Some screen readers will automatically read the title attribute, which describes the setting further. Screen reader users are also able to read the name of each setting by exploring above the button, but associating the label with the control is good practice and eliminates a lot of confusion and extra key presses.

The visual settings in the ebook viewer are quite comprehensive, and include five colour themes, a highly-adjustable font size, a brightness slider, margin and line spacing adjustments, and 14 fonts including “Dyslexic”.

For screen reader users, both page and scrolling view have some accessibility barriers, but scrolling view is a much better experience. In page view, the entire chapter is rendered in the web document, which means the screen reader can read it; however, only one page is visually shown, and that might not be the page being read by the screen reader. For this reason, screen reader users cannot simply turn the page to go to the next chapter, as the visually shown page might be lagging behind. When the page is turned within the same chapter, no screen reader announcement is given, so users might simply believe the page turning functionality does not work. Depending on the number of pages in a chapter, the easiest way to navigate might be the Chapters menu, but this requires several steps and is much more cumbersome than simply pressing a key. There is no good solution for tracking screen reader focus across all software combinations, so the best approach might be rendering only one page at a time in this view.

In scrolling view, “Previous Chapter” and “Next Chapter” buttons are shown at the top and bottom of the current chapter, but the buttons disappear from the webpage when the page is scrolled away from the beginning or end. Since screen readers can often read off-screen text, screen reader users might find they need to manually scroll the webpage to the bottom to advance the chapter. Depending on the software combination used, this is not always an intuitive process. For instance, using any Windows screen reader, one needs to type a special command to pass the next key through to the browser, then press ctrl+end. Simply pressing ctrl+end on its own will instead move screen reader focus to the bottom of the document without changing the visual position at all. A MacOS VoiceOver tester found that pressing either of these buttons sometimes caused VoiceOver to lose focus and be unable to interact with the ebook viewer. A page reload is the only known resolution.

When searching for text, results are grouped by the chapter or section in which they occur. Each section should be a heading for easier navigability, rather than a piece of static text. This screen is otherwise accessible.

When moving to a bookmark or search result within the book text, screen reader focus is not correctly changed to the relevant area of the text. Since entire chapters are rendered at once, these functions are far less usable for screen reader users. In addition to highlighting the relevant text, keyboard focus needs to move to that text. Currently, it is more helpful to perform a screen reader search, possibly in addition to the built-in search function. A MacOS VoiceOver user found that moving to a bookmark or search result would occasionally cause the ebook viewer frame to be unreachable with VoiceOver, requiring a reload of the page.

When invoking the context menu after selecting text, the menu items are not keyboard-accessible and silently populate at the bottom of the document for screen reader users. While selecting text on a webpage is problematic with a desktop screen reader, the menu items should conform to the same accessibility standards as the rest of the reader controls. Adding a highlight also reveals many unlabeled controls, and one labeled “Aa”. Neither the menu items nor highlight controls are using any kind of HTML markup to define them as menu items and buttons, so screen readers see them as nothing more than pieces of text. Narrator is unable to interact with these controls at all because they have “no primary action”; other screen readers work around this by simulating a mouse click.

When closing the reader using the “Close Reader” function found in the reader menu, the website sometimes asks for a rating. Much like the rating controls on details pages, these buttons are not labeled.

Audiobooks

Audiobooks can be played in the background while browsing the website. The player therefore has a collapsed and expanded view. When first selecting an audiobook, the player is collapsed. For screen reader users, the player controls will render at the bottom of the page. Enclosing this player in a complementary landmark would make it easier to find, though the title of the playing audiobook is contained in a level-1 heading. Low-vision users also found that the banner easily blended into the background of the page and could be missed entirely when the page is zoomed. Adding customizable colour options within the Hoopla settings or changing the colour of the quickplay banner to be a high contrast black or Hoopla blue would increase visibility.

When the player is expanded, screen readers can navigate away from it and view the rest of the page, but this seems unintentional since many page controls outside the player do not work correctly. For instance, the “Browse” and “My Hoopla” menus simply will not open until the player is collapsed. If these controls are disabled, they should not be available for screen reader users who may then be confused about why they don’t function as expected. The label for the “Expand Player” button does not change to “Collapse Player” when the player is expanded, causing further potential confusion. The “Close” button (which stops playback and closes the player) might also benefit from a clearer label such as “Close Book”.

Within the player, all buttons have clear labels. Time information is available for the chapter and the entire book. JAWS users found that the elapsed and remaining times ran together, resulting in text such as “4:3129:35”. Other screen reader users did not experience this problem.

The Chapters, Sleep Timer, Bookmarks, and Playback Speed buttons all have the word “Menu” written into their text labels, which is technically not correct—they open dialogs instead. The “Menu” is not required here, and there are ways of indicating that a button opens a dialog. Within all these dialogs, the close button is labeled with the × symbol.

In the Bookmarks screen, the button next to each bookmark has no screen reader label. It opens a second popup where one can add a note or delete the bookmark. A label of “Edit” would be appropriate here. After saving a note or deleting a bookmark from this “Edit” popup, focus is not correctly returned to the bookmarks list because it is contained in a separate modal. Using the dialog element can help eliminate this problem as it has relevant accessibility features built in. Notably, most popups of this kind will close with the escape key, but this one does not.

Music

The music player exhibits many of the same behaviours as the audiobook player. It uses the same collapsed/expandable format with the same visual and nonvisual accessibility barriers. Finding the player with a screen reader is more difficult compared to the audiobook player, as there is no level-1 heading around the name of the song or album. When the player is collapsed, it shows many more controls than the audiobook player, including repeat and shuffle buttons, time readouts, and a volume slider. It is therefore far less necessary to expand the player unless one needs to choose a specific track from the album. Since the repeat and shuffle buttons switch between more than two options, the label for the button should be set to the current mode, rather than the mode that is activated with a press of the button.

When music is playing and the player is collapsed, the space bar will pause or resume playback. This is the same command used for activating buttons, particularly on Windows. While the website automatically disables this keyboard command for top navigation controls, other buttons cannot be activated with the space bar because the play/pause binding is still active. These include (non-exhaustively) the “Search” and “Advanced Search” buttons, the buttons for scrolling carousels, the “Borrow” or “Return” button, the rating selectors, and (confusingly) the “Expand Player” button. These buttons typically activate with the enter key or other screen reader commands. The audiobook player does not seem to use the space bar for pausing or resuming, so this behaviour is only observed in the music player.

A MacOS user experienced further unusual behaviour in this player: When the previous or next track button is pressed, the play/pause button becomes unreachable with VoiceOver. When the mute/unmute button is activated, VoiceOver becomes unable to focus on the volume slider. Lastly, when expanding the music player, VoiceOver is not able to focus on the track list at all. The reason for this is not clear, but the behaviour is consistent.

Video Content

Videos open in a full-screen player which obscures the rest of the page. The video content is contained in a dialog with the player controls inside a nested dialog, so when using NVDA, one must interact with both dialogs to find player controls. While the video is playing, one tester (using NVDA and Firefox) found that keyboard focus was frequently shifted away from both dialogs, requiring an extra press of the tab key to regain focus. Pressing any of the arrow keys will also shift keyboard focus away from the video player. Another tester on MacOS found that Voiceover focus was shifted away from the controls so frequently that the video player was unusable.

Within the “Closed caption settings” popup, there is a section to select an audio track. This is likely used for language selection, but it also makes way for enabling audio description on future videos which include it. With a screen reader, it is not possible to determine which subtitle/audio option is currently selected.

When captions are set to use a larger text size, they can obscure the video content. Moving them to the bottom of the screen would improve visibility.

Comics

Low-vision users found that comics were sufficiently high-quality to zoom in, although zooming too far can sometimes cut off portions of the panel. Comics are typically completely image-based, so text cannot be further customized and cannot be read with screen readers.

Screen reader accessibility of the comic reader is mixed: All buttons are clearly labeled except for the zoom controls, which have no label at all. The comic viewing area has alt text of “your browser doesn’t support our comic player, please update your browser to use this feature”. This text is intended to display for people who have an unsupported browser, but it is also shown to screen reader users even when the comic is visible and could cause them to believe they simply need a different browser to read the text.

The settings screen only has two settings, both of which are toggle buttons. Similarly to the ebook viewer, these toggle buttons are labeled “Use setting” and therefore the actual name of the setting could be missed by some screen readers.

Development Recommendations

  • Support dark mode on all sections of the site, including search.
  • Label the close buttons on popups such as the login and register screens and borrow/return confirmations.
  • Indicate the selected library to screen readers during registration.
  • Use a link for the “Go to Home” navigation item (right now it’s a menu item).
  • Clean up labels and slide buttons in promotional carousel.
  • Remove text such as “click to change” from the screen reader labels of buttons and menu items.
  • Fix search field so keyboard focus consistently lands where it should.
  • Fix filter options to use the same accessibility markup and keyboard navigation as other menu buttons.
  • Remove aria-label from titles in search results.
  • Remove alt text on book covers unless there is a meaningful description of the cover image available.
  • Add a heading before search results.
  • Add labels to rating controls on title details pages, and indicate the currently selected one with an attribute such as aria-pressed or aria-current.
  • Add the name of the relevant title in the “Are you sure you want to borrow this title?” prompt.
  • Fix heading structure on title detail pages.
  • Addition of accessibility metadata for all formats.
  • Remove custom screen reader label from titles in the Currently Borrowed section and improve accessible layout instead.
  • Ebooks: In scrolling view, keep the chapter navigation buttons in the DOM even when they are not visible.
  • Ebooks: In page view, render only one page at a time.
  • Ebooks: Move screen reader focus to relevant word or paragraph when searching text or returning to a bookmark.
  • Ebooks: Add keyboard and screen reader accessibility to the context menu.
  • Audio: Change the label of the “Expand Player” button when the player is expanded.
  • Audio: Add landmark to audio player (change the containing div to have `role=”complementary”`).
  • Audio: Ensure the site is not interactable while the player is expanded, if that is the intent.
  • Audiobooks: Remove the word “Menu” from button labels and indicate they open a dialog instead, using `aria-haspopup=”dialog”` or similar.
  • Music: Prevent the space bar from pausing or resuming playback while focused on an interactive control such as a button.

iOS

Signing In and Registering

The registration screen is the only section of the login area which scales to the user’s chosen text size; however, a sufficiently large text size setting can cause the interface to be unusable. On an iPad, the library pin, local library and consent checkbox are all hidden using the maximum level of accessible text size. One is unable to scroll through the text box with these enlarged text sizes. If a new user doesn’t know about these text boxes and therefore does not fill in their information, Hoopla does not display an error; instead, it simply continues to the home screen with no logged in account. This could cause endless frustration while a low-vision user goes in circles trying to complete a registration process with incomplete information and no meaningful errors.

For VoiceOver users, the registration interface is usable but still lacks accessibility polish. The home screen will be discussed below, but it has a mess of unlabeled images whether the app is logged in or out. On the first registration screen, the terms and privacy policy buttons are unlabeled. When a library choice has been selected, Voiceover reads a “Selected” image next to the library choice, but the state of the button does not change. The card number and pin fields are correctly labeled, but the state of the consent checkbox cannot be determined by VoiceOver. Logging in with an existing account is a comparatively accessible process.

Home and Browse

The Kids Mode button is simply labeled “Off” (or presumably “On”), and one must activate the button to find out its purpose. After the popup appears explaining how kids’ mode works, there is no VoiceOver-accessible way to return to the interface without enabling kids mode or force-quitting the app.

When browsing the catalogue with adjusted text size, the titles, authors and other relevant information do not scale to the chosen text size. Additionally, our low-vision testers found that the author and format were low-contrast and more difficult to read.

For VoiceOver users, the home screen is a confusing mess of disconnected clutter and unlabeled images. It features a list of horizontally scrolling carousels containing categorized titles, including trending and recommended. The cover image, title, author, format, and play button are all separate controls. Repeatedly swiping right will typically cause Voiceover to read all controls in logical order, but in this case, VoiceOver moves through each of the cover images, then each of the titles, then each of the authors, and then each format. This is extremely cumbersome to navigate and creates a disconnection between the metadata wherein a user cannot determine which book is by which author and in which format. Since users encounter so many unlabeled images before any textual information, it would be easy to conclude the carousels are not accessible at all. Some carousels feature “See All” buttons, which open a much more accessible vertical list of titles.

At the top of the home screen, one can swipe past 13 unlabeled images to reach the list of formats. Choosing a format from this section is the best way to browse and discover titles using VoiceOver. After choosing a format such as Ebooks or Music, a subpage will open with more carousels. The titles in each of these carousels consist of only one control which contains all the relevant information, including title, author and format. The “See All” button on each carousel also opens a vertical list, which is fully accessible with Voiceover.

There are no headings on the carousel headers, so moving between the carousels is unnecessarily cumbersome and best done using explore by touch (moving one’s finger around the screen rather than swiping and right). Using proper heading controls would allow VoiceOver users to navigate to the next or previous heading and reach each carousel.

Search

Search functionality is always reachable through a dedicated bottom tab. Below the text field, trending searches are prominently displayed.

After choosing a search suggestion or entering a custom one, results are displayed in a vertical list similar to the “See All” section of homepage categories. Additionally, sort and filter options are available at the top of the screen. Both sets of options share the same screen, but these two buttons serve as shortcuts to each of the tabs on that screen.

Sorting and filtering are largely accessible; however, filtering options have the word “section” appended to the end (“Release Datesection”). There is no visible close or dismiss button on the sort and filter screen, but the scrub gesture will reliably close it and return to the search results. When results are sorted, the Sort button is reported as “Selected”, but the current sorting option is not shown or spoken. When filters are applied, the filter button includes the number of filters in its label.

The advanced search has no notable accessibility barriers and serves as another way to browse titles if one wants more sorting options or simply can’t work around the home screen carousels. It is possible to leave all text fields blank and simply select a format, a release date, or other criteria to see a complete list of matching titles. Some of the advanced search criteria turn into filters, most notably the chosen format, which means the results page will immediately load with one active filter when searching for all titles of a given format.

Title Details

The title details screen contains all metadata and rating details for a title. While many sections of the app do not scale to a user’s text size, the title details text does adjust correctly.

All controls on this screen are labeled and accessible to Voiceover. The “Share” and “Favourite” controls are not identified as buttons, even though they surround the correctly classed “Borrow” button. Ratings are correctly read by VoiceOver, and double tapping the rating allows one to rate the title using labeled buttons.

TV shows are displayed one season at a time, but only one episode can be borrowed at a time. Therefore, all episodes are listed individually, each with its own borrow button. This section would benefit from some control grouping as well, since the episode number, season, episode title, length, description, and borrow button are separate controls. This would be a great excuse to use a custom Voiceover label around each episode, as mobile applications lack the granular navigation of websites.

My Hoopla

The My Hoopla tab lists current borrows and favourites. For a current borrow, VoiceOver reads the automatic return date after the title and author. Each title is only a single control with a rotor action to play the current title. If one double-taps the title directly, the details page loads. Swiping down and double-tapping will activate the “Play” action, which loads the title instead. Some types of media need to be downloaded first, and in those cases, the play action is still available but will only load the details page. A “Download” action would be helpful in such cases.

Ebooks

For VoiceOver users, the ebook viewer seems to be modified to provide better accessibility. While it largely does so, it fails to account for VoiceOver users who may still wish to read the book visually. As such, there is no way to access appearance settings once VoiceOver is enabled. Additionally, if one can open appearance settings and then re-enable VoiceOver, they will find that the themes are not labeled. A user should not need to choose between one method of access and another; they should always be able to use both interchangeably.

For visual readers, the ebook viewer provides a range of settings like the web-based viewer, including font face and size, line spacing, and margins. A scrolling view is also available and is enabled by default for Voiceover users.

The scrolling view is ideal for screen reader users, as it allows VoiceOver to continuously read to the end of each chapter. A “Next Chapter” button is available at the end of the current chapter, and VoiceOver navigates to this button consistently.

The Close, List, Search, and Bookmark buttons are typically reachable with VoiceOver, but one must move to the top of the screen and then swipe left to reach them, as they are hidden by default. A setting to keep these buttons on-screen permanently would be helpful for both blind and low-vision users.

When using VoiceOver’s custom scrolling view, the page number never seems to update beyond the initial number displayed when loading a chapter.

Since VoiceOver’s text selection integrates well with the system, creating highlights on iOS is an accessible process. After selecting text, one can triple-tap to perform a long-press, which reveals the highlight creation screen. The only section which is inaccessible to VoiceOver is the colour picker. Voiceover users are only shown a single control called “Aa”, which cannot be double tapped.

Audiobooks

Visually, the audiobook player is easy to use and navigate. With VoiceOver, it is navigable but with some challenges:

The “Sleep Timer”, “Chapters”, “Bookmarks”, and “Playback Speed” controls are duplicated, with one labeled button and one piece of text for each. These pieces of text can be hidden from screen readers as the buttons themselves already have accessible labels. Notably, the playback speed button has an accessible label of “Playback Speed” while the text simply says “Speed”, suggesting that these are two separate labels. Double-tapping on a text label does not bring up the corresponding popup; one must double-tap the button.

When adjusting playback speed, several preset choices are shown, but many common ones are missing, including 1.25X and anything above 2X. One can also choose a custom speed, but this process is not intuitive with VoiceOver. Typically, VoiceOver users can adjust a slider by swiping up and down (regardless of the slider’s orientation), but this seems to have no effect. Instead, one must double-tap and hold, then drag to adjust it. This produces an immediate effect when playing the book, so it is possible to drag the slider and hear the result in real time, then let go once a desired speed is reached. The current speed is indicated as one of the first controls reachable with VoiceOver. The sleep timer popup behaves identically, with many preset options and a custom slider which can only be adjusted with a manual drag.

The elapsed and remaining time readouts lack any actual time values when reading them with VoiceOver, so users have no way to know their reading position in the book or chapter.

Visually, the five media controls are presented with the play button in the middle, but when using Voiceover’s swipe gestures, the Play button is read first, followed by the other four buttons instead of the buttons being read from left to right with play as the third option. The experience is the same for those using a keyboard and the arrow keys to navigate the app.

In the list of bookmarks, each bookmark has VoiceOver “rotor actions”, allowing users to swipe up or down to select a custom action. These custom actions are “Delete” and “Edit”. Rotor actions are a great way to expose multiple actions to the user without cluttering the screen with multiple controls, and they are used well here.

Music

The music player is quite minimal and quite accessible. When first launching an album on iOS, the user is presented with a helpful hint that explains how to swipe left or right to see different sections of the music player. For VoiceOver users, this translates to a left or right three-finger swipe. Users should already be aware of this, but if Hoopla is defining custom behaviour for VoiceOver users, a slight modification to the hint wouldn’t go amiss.

On an iPad, one tester found that switching between landscape and portrait orientation didn’t correctly resize the sections of the app. In landscape view, the track list, player controls, and repeat and shuffle settings are visible on one screen. When switching back to portrait, the three sections do not resize to fill the screen; they are centered within a small portion of it which significantly impacts low-vision users.

Videos

Visually and non-visually, testers had no trouble using the video player. The controls are well-labeled and seem to always remain on screen. Notably, the iOS video player contains a playback speed option, which is not present in the web player.

Comics

For low-vision testers, comics are easy to navigate. Panel view is especially helpful, but lacks a pinch zoom, which makes the process of zooming in more cumbersome.

For VoiceOver users, Hoopla has implemented a feature called direct touch which passes all gestures through to the application. For VoiceOver users with enough vision to read comics, this might be helpful for interacting with the gesture-based comic viewer; however, it creates an accessibility barrier wherein a user relying completely in VoiceOver. It is not able to effectively navigate the viewer, even to exit the screen. There is only a small section of screen on each adjacent control which responds to VoiceOver gestures. Even if a VoiceOver user locates the done button, double-tapping just slightly off the touch target will pass those taps through to the viewer, potentially hiding this button.

Development Recommendations

  • Scale to a user’s chosen text size for all textual interface elements.
  • Fix cut-off controls in registration screen when text size is large.
  • For VoiceOver users, group library choices together on the registration screen and properly indicate which is selected.
  • Label Kids Mode button and provide a way to exit the popup using Voiceover.
  • In home screen carousels, group controls together so VoiceOver reads and navigates to a single control per-item. Ensure VoiceOver is still able to read the title, author and format.
  • Add headings to carousel headers to facilitate heading navigation.
  • Remove the word “section” from search filter criteria.
  • Group controls associated with TV episodes together, so Voiceover reads all information at once.
  • Replace the “Play” rotor action with a “Download” action when streaming is unavailable for a given format.
  • Allow VoiceOver users to access ebook reading settings.
  • Fix VoiceOver accessibility of colour selection during highlight creation.
  • Remove redundant text labels on bottom buttons in audiobook reader.
  • Allow VoiceOver to adjust the speed and sleep timer sliders by swiping up or down.
  • Fix resizing bug when switching from landscape to portrait view in the music player on iPadOS.
  • Decrease the vertical size of the direct touch area in the comic viewer to avoid a focus trap for Voiceover users.
  • Inclusion of accessibility metadata for all formats.

Android

Signing In and Registering

Controls throughout the login and registration process are labeled well, but many controls which should be buttons are not announced as buttons. Instead, the TalkBack screen reader simply reads their name. This includes the “Log In” and “Sign Up Today” buttons, the “Let’s Go” button on step 1 of the registration process, and each of the library choices. When a library is selected, its “selected” state should also be announced by TalkBack, but there is currently no way to determine whether the desired library has been chosen.

Home

The top of the home screen includes a “Kids Mode” button and a “Help” button. Neither of these are announced as buttons, and the state of the Kids Mode toggle is not indicated by TalkBack.

The main content begins with a carousel with 14 unlabeled controls, which could easily lead a user to believe the entire home screen is inaccessible. These controls seem to correspond to the formats in the carousel, so they should likely just be hidden from TalkBack entirely to avoid any confusion.

After these blank controls, a TalkBack user will encounter the list of browsable formats, such as ebooks and music. These correspond with the blank controls, but because of the way the carousel was designed, users will first encounter all the buttons and then all the corresponding formats. Below this carousel, several other carousels are arranged in a vertical scrolling view. These include popular, recent, and favourite titles. The items in these carousels are labeled, and each carousel has a “More” button to open a vertical list of all the relevant recommendations. Notably, the carousel headers are not headings, so navigating between carousels is unreasonably cumbersome for a TalkBack user. Headings would facilitate heading navigation, which is a useful way to move between important sections of an app.

After choosing a format from the first carousel, a similar screen will open with the format narrowed down. The top of this screen begins with another series of unlabeled controls followed by more carousels with recommendations. This time, the unlabeled controls correspond to featured or promoted recommendations which are placed at the very top of the screen. There is no corresponding text label; users need to double-tap on each unlabeled button and read the details page to learn anything about the title in question. This is not desirable, and most TalkBack users will skip to the subsequent carousels with labeled recommendations.

Search

The search tab reveals a search field, an advanced search button, and a list of trending search suggestions. Every applicable control on this screen is missing a button role, except the “Navigate Up” button which is a system control for going back to the previous screen.

This interface is very minimal and presented no major accessibility barriers to users. Notably, there are no filters available on search results pages—or if they are present, TalkBack cannot reach them. The advanced search provides the only way to perform a search with specific criteria or format requirements.

On the advanced search page, the TalkBack label for filter controls is unnecessarily verbose—for instance, “Filter search results by title format. Currently filtering by all formats. Double tap to change this filter.” Most of this is redundant and slows down usage of the interface. “Filter by format: all formats” would be a more concise alternative.

Title Details

The title details button is shown when any title is selected, whether from search results or the home screen. In addition to all relevant information about the title, it contains buttons to borrow, return, download, or open the selected item; a share button; rating details and an option to add the book to favourites without borrowing.

Unfortunately, this screen contains several accessibility issues. The close button is not labeled, and the “Borrow”, “Share”, and “Favourite” controls have no button role. The user ratings and self-rating functionality is inaccessible to TalkBack. The button to rate a title is unlabeled, with no surrounding text entry. A seemingly random number near the button may or may not indicate the number of ratings, but the rating average is the most important piece of information and is not shown. Finally, after pressing the unlabeled button to rate a title, a TalkBack user will find themselves on a screen with no interactable controls. This screen can only be closed with the system back button.

The release year, length, language, and abridged status are read as a single control with no pauses between the information. This would be easier to navigate as separate controls, or with some comma separation.

Conversely, fields such as author and narrator are broken up into two controls which TalkBack reads separately. These should be grouped into a single control for improved readability.

After a title is downloaded, more verbose buttons appear, such as the “this title is downloaded tap to delete” button and the “tap here to return this title” button. In both cases, labels such as “delete download” and “return” are sufficient.

My Hoopla

The My Hoopla tab shows titles that are currently borrowed as well as titles which have been added to favourites. For TalkBack users, each title consists of several controls including an unlabeled button and a verbosely-labeled “tap here to play this title” control. Each title should only consist of one control with TalkBack actions to play the current title, or two controls if separate play buttons are easier.

Ebooks

Ebooks open in a scrolling web-based view with controls that appear or disappear when the screen is tapped. This is standard functionality for mobile ebook viewers, but a hint when first opening an ebook would help more users understand how to access settings and other functionality. After the controls appear, TalkBack is still able to navigate the text even though the menu obscures it. Users would need to touch the middle of the screen to reset focus inside the menu. The dismiss button is unlabeled, as is one other control which appears to do nothing. All other controls in the menu are labeled, but some have overly verbose names such as “Back button, tap here to exit the book reader.”

The ebook viewer renders entire chapters in one long scrolling view. When the end of the chapter is reached, the “Next Chapter” button is shown, though sometimes Talkback is unable to swipe to it and claims there is “no next default” instead. The button is easy to locate by touch.

Though many reader settings have verbose button labels, the reader has a good variety of visual adjustment options including a collection of 14 fonts, brightness, text size, alignment, margins, two-column view, and five colour schemes. While Talkback is turned on, the scrolling view toggle is dimmed, and a note indicates that this setting cannot be changed until Talkback is disabled. This is likely due to the difficulty of creating horizontal page views which function well with TalkBack.

Audiobooks

The audiobook player is usable by an experienced Talkback user, but contains a variety of poorly labeled, poorly separated, or redundant controls. The player begins with three “Navigate Back” buttons which are actually “Back”, “Car Mode” and “Add Bookmark”. The elapsed and remaining times are readable, but there is no text to indicate which is which—the exact opposite of iOS. The next and previous chapter buttons are called “Fast Forward” and “Rewind”, which is quite confusing when placed next to the “Fast Forward 30 seconds” and “Rewind 30 seconds” buttons. One must remember that the buttons with no time increment are for chapter navigation. In addition to the “Change Playback Speed” button, separate controls called “1.25X” and “Speed” are shown.

The chapters, bookmarks, speed, and timer menus do not properly obscure the other controls, so Talkback is able to navigate to the rest of the player and does not immediately focus on the new popup after it loads. The close button for these popups is unlabeled, and swiping past the speed adjustment options will lead back to the first “Navigate Back” button, so users could very easily close the entire player instead of the popup. Within the timer and speed popups, the minimum and maximum values are spoken after the current one. For instance, at the default speed, Talkback reads the top heading as “Playback speed: 1.0X, list, 0.5X, 4.0X”.

Listing and navigating to chapters and bookmarks is simple when one learns to avoid swiping forward to the player controls. Bookmarks can be edited with notes or deleted. The name, location, and timestamp of bookmarks is read in a concise and understandable way.

Music

The music player has only one small accessibility issue: The button to switch between the player controls and the track list has no label. It is the only unlabeled control on either of the screens, but users may not realize they can bring up a track list until discovering the button by accident. All player controls, popup menus, and textual information appears fully usable by all testers.

Videos

Videos use a standard player with controls to seek, play or pause, or adjust subtitle settings. Talkback users noted that the controls can easily be revealed with a labeled button, but they disappear after only a few seconds. A user cannot realistically explore all the controls within their initial five seconds, so will have to reveal them multiple times to find the desired button.

Development Recommendations

  • Add button roles to actionable controls where necessary.
  • Indicate whether library choices are selected or not.
  • Hide unlabeled controls from top carousel on home screen and format-specific screens.
  • Add headings to carousel headers within home and format-specific screens.
  • Add TalkBack-friendly label to indicate user rating for titles.
  • Inclusion of accessibility metadata for all formats.
  • Clean up verbose accessibility labels on buttons, including removal of the word “button” and any instance of “tap here” or “double tap”.
  • Use interactable controls for assigning a rating.
  • Add labels to unlabeled buttons in the ebook viewer, especially the button to dismiss the menu.
  • Do not allow Talkback to read book text when the menu is visible.
  • Keep the chapter navigation buttons visible at the top and bottom of the scrolling view to facilitate better Talkback navigation.
  • Fix unlabeled and mislabeled buttons in audiobook viewer.
  • Do not allow Talkback to explore outside popups in the audiobook viewer.
  • Fix missing button label on music player track list.
  • Keep video controls on screen when Talkback is loaded.

Conclusion

On all platforms, Hoopla has significant design choices that facilitate better accessibility, particularly for screen reader users. Some of these choices result in a much better experience, while others remove important functionality or lead to slower navigation due to verbose labeling. On several occasions, the Hoopla mobile app designers have fallen into the trap of designing their app to explain basic screen reader functionality to the user. Most of the unintentional accessibility barriers are not severe, but they do sometimes combine to create a much worse experience for the user. The most serious example is the plethora of unlabeled and disorganized controls on the home screen of the mobile applications. Most testers found browsing, searching, reading and listening could be accomplished on all tested platforms, excepting the strange behaviour observed with VoiceOver on MacOS, which made most media consumption largely or completely unusable. NNELS hopes the Hoopla developers will continue to take steps toward a very accessible Hoopla experience.

Systems and Assistive Technology

  • Operating Systems
    • Windows 10, 11
    • macOS 14.5
    • iOS 17.4.1
    • Android 14
  • Mobile Applications
    • Hoopla 4.58.2 (iOS)
    • Hoopla 4.75 (Android)
  • Browsers
    • Chrome 126 (Windows)
    • Safari 17.5 (MacOS)
    • Firefox 130 (Windows)
  • Screen Readers
    • NVDA 2024.2 (Windows)
    • JAWS 2024 (Windows)
    • Narrator (Windows)
    • VoiceOver (macOS, iOS)
    • TalkBack 14.1 (Android)
    • Orca (Linux)
  • Magnification
    • Fusion (Windows)
    • Zoom (iOS, MacOS)
    • Magnification (Android)

Acknowledgements

The following testers and editors contributed to this report:

  • Patrick Bouchard
  • Tait Hoyem
  • Simon Jaeger (lead writer)
  • Michael Krupp
  • Riane LaPaire
  • Ka Li
  • Melody Shih
  • John Ylioja

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

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