DOCX | PDF

May, 2022

This report was written with support from the Government of the Northwest Territories, Public Library Services, Department of Education, Culture and Employment, and the Government of Canada’s Social Development Partnerships Program – Disability Component.

The opinions and interpretations in this publication are those of the author and do not necessarily reflect those of the Government of Canada or the Government of the Northwest Territories.

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. 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

Many of the resources available through World Book are difficult or impossible to access using assistive technology. All website pages contain multiple accessibility barriers that would render the resource inaccessible to readers with print disabilities using assistive technologies.

To begin to make the website accessible, developers need to implement the improvements discussed in this report. This includes adding a correct and consistent heading hierarchy across the site, improving image alt-text, and using valid HTML to identify buttons and links.

Introduction

The World Book website provides resources geared toward students from pre-k through high school. The available types of content include articles, timelines, dictionaries, encyclopedias, activities, and games.

This assessment aims to determine the usability experience of readers with print disabilities[1] and to what extent they can access content through their local public library 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 World Book itself. Some functionality may not be discussed at all or in-depth.

Our testers found significant barriers to navigating the site with a screen-reader, with many improperly labelled links and buttons. Some types of content were partially or entirely inaccessible which will be discussed below.

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 also be sent to a refreshable braille device[2]. 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 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 during testing the World Book apps and website. Below you will find the testing results and their related recommendations as they pertain to:

• Library Access
• Signing In
• Browsing Content
• Interacting with Content
• Visual Adjustments

Finally, the development recommendations section contains suggestions for improving the interface. These suggestions will be relevant to any issues or observations noted above.

Signing In

There is a mix of contrast schemes on the login page that is an accessibility barrier because it makes the text difficult to read for low-vision readers. The welcome message sentence (that notes testers used Northwest Territories library system to logon) is low contrast (mid-grey on blue) and an opposite contrast to the rest of the text on the page. This problem can be found in various forms on nearly every page, particularly in the top and bottom sections. Low-vision users would benefit from high and consistent contrast across the website.

Screen-readers do not identify the “remember me” control as a checkbox, nor do they report whether it is checked or unchecked. The checkbox has an unnecessary ARIA role of “group,” which causes the screen-reader to identify it as a grouping rather than a checkbox. If this role is removed from the HTML code, the checkbox functions correctly, though it still has a confusing ARIA label of “library checkbox save.”

Homepage

The “Super Home Page” appears after logging into the website and includes a navigation menu leading to other important sections of the site. Testers noted that screen-readers do not identify these navigation items as links. Each of them is simply a clickable icon that has been visually styled to look like a link. This approach prevents screen-reader and keyboard-only users from navigating through the menu efficiently. Each navigation item also includes an icon with alt-text, so screen-readers read each item twice.

Each page contains a footer menu with items that can be expanded or collapsed. Screen-readers do not report whether these items are expanded or not, and the “close” button for each is simply labeled “x.” Ideally, these menus should indicate their expanded state correctly and be keyboard-accessible (with the arrow keys and escape to close the menu.) However, the expanded menu items appear in the correct place and can be activated with a screen-reader.

Early Learning

The Early Learning section contains stories, videos, games, and activities. Much like the Homepage, these menu items are presented as clickable icons and pieces of text. Consequently, screen-readers will read the name of each menu item twice, and there is no easy way to jump directly to these items using a keyboard (as would be the case if they were correctly coded as buttons or links).

A childlike text-to-speech (TTS) voice reads the selected items while moving around with the keyboard or mouse. This is a nice feature to have in general, but for screen-reader users, it can be distracting and can clash with the existing TTS voice, sometimes reading a completely different item. An option to disable this feature would be helpful.

There is an artistic typeface on the page, which low-vision testers found challenging to read even when magnified. The text-to-speech function was helpful in this case.

Each of the items listed under the category headings has duplicated controls (“play,” “watch,” or “read”) and duplicated titles (due to each image having alt-text that contains the title). This alt-text is redundant if the title is shown in text form. Each section has an additional image whose alt-text reads “image of item” and once a section such as Stories is opened, this unhelpful piece of alt-text appears as part of every title listing.

There is no heading or landmark at the beginning of the list of titles, so navigating to the main content of the page is inefficient with a screen-reader. All screen-reading software has functions for moving between headings on a webpage, so a good heading hierarchy is one of the most important aspects of accessible design.

Stories

Since stories are heavily text-based, they can be read with screen-readers, and the text can be adjusted. The story reader also contains a text-to-speech option by way of “play” buttons next to each paragraph. Like the other interface elements, the play button is simply a clickable image that screen-readers will not read correctly. When it is pressed, keyboard focus is shifted outside the story reader, which causes screen-readers to lose their cursor position.

Testers using screen-readers also found that pressing the escape key would set the keyboard’s focus to the main page with no way to return to or close the player. Since most of the page navigation is hidden when the story reader is opened, the page is effectively nonfunctional until refreshed.

Videos

For screen-reader users, the video player is usable, but most of the buttons are incorrectly labeled, and some are only clickable images. For instance, the full-screen toggle has a label of “fullscreen button image” and is not a button. The play and mute buttons contain the word “button” in their label, which is unnecessary. A screen-reader will correctly identify these as buttons, resulting in spoken phrases such as “play button button.”

Though videos in the Early Learning section tend to have a lot of spoken words, blind people are excluded from the visual content and may miss out on important context. Including an audio description track on video content would go a long way toward making this website section more accessible.

Games

None of the games are fully accessible. There is no keyboard navigation available, and images are often used to display text, even in text-based games such as True or False. Screen-reader users cannot read this text, and magnification users cannot adjust the appearance or increase the size without quality loss. There is also no keyboard alternative for drag-and-drop games.

When exiting a game, the text “Are you sure you want to quit?” is shown in artistic font, making it difficult for low-vision users to read.

Kids

The Kids landing page is a hub for numerous types of informational content. It consists of a search field, a carousel for articles, and links to animals, maps, games, science projects, dictionaries, and biographies for important people. Unfortunately, many of the accessibility-related bugs noted above are also present here.

Aside from using proper links, the design of these pages includes almost no meaningful HTML. For instance, there are no landmarks for search, navigation, or the main content in general, no heading structure whatsoever, and no list styling for the list of categories. On this and other pages, many controls are meaningless clickable images or pieces of text, which prevents screen-reader users from navigating to them using keyboard commands. Information is often duplicated in the image’s alt-text, causing screen-readers to read each item twice. This persists across many sections of the site, such as the items on the Explore page or the list of occupations on the Important People page.

In the advanced search screen, the options are all presented as clickable items rather than links, so screen-readers have no way to move between these options easily.

Articles

Articles are quite readable, but the reader view still comes with several accessibility challenges. Much like the landing page, articles have no heading structure. At a minimum, the beginning of the article should have a level 1 heading before it so a screen-reader user can easily jump past the top controls and begin reading. On all tested pages, the first heading is “How to cite this article” at level 3.

The Tools and Table of Contents toggles have no control type; they are simply clickable images with a label. These should be buttons with an expanded or collapsed state. (This can be done in an accessible way using the aria-expanded property.) With the current design, screen-reader users cannot quickly jump to these controls, and the screen-reader is unable to detect whether they are collapsed or expanded. The control to close the tools menu is a clickable piece of text called “close button,” but it is still not an HTML button.

When using the keyboard to adjust voice settings (for the read-aloud mode), you must use the left and right arrow keys to change the selected voice and the reading speed. This is not typical behaviour for a combo box, and many users may conclude that these settings cannot be adjusted with a keyboard at all.

Images have descriptive alt-text, but it appears to be a copy of the accompanying caption. Alt-text is intended to describe the image and convey contextual information unavailable in the text. In this case, it is being misused, causing screen-readers to read each caption twice.

Note: The above information also applies to activities, biographies, science experiments, and lesson plans, all of which use the same reader.

Compare Places

For screen-reader users, selecting two places to compare is cumbersome and confusing. This is due to the lack of announcement or instruction when new content loads and the fact that each place option is spread across three lines. For instance, the province of Saskatchewan is shown as follows:

• Line 1: Text that reads “Province (Canada)”
• Line 2: An image with the alt-text of “Saskatchewan”
• Line 3: Text that reads “Saskatchewan”

Each place is contained under a heading, but because of the placement of this text, navigating to a heading is quite verbose. NVDA announces the following:

“Heading level 2 Province (Canada) Saskatchewan graphic link Saskatchewan”

In this case, links contained in an HTML list would be a better choice than headings since having many place options would create immense clutter in the heading structure. The (Canadian province) text should be announced after the province’s name. The images should have alt-text that is either blank or meaningful.

When comparing two places, the chart is contained in a table, but this table does not appear to have any HTML structure. Ideally, the table should consist of three distinct columns of cells–Place 1, Criteria, and Place 2. The relevant information is contained in a single cell and is therefore not navigable in any meaningful way. With no structure in the table and therefore no spatial orientation, it is difficult for screen-reader users to tell whether a piece of information applies to “Place 1” or “Place 2.”

Games

Much like the Early Learning games, many of the options in the Kids section are visual and therefore not accessible. However, purely text-based games can be played easily with a screen-reader and keyboard. These include some–but not all–games in the Multiple Choice section. Many of the remaining games could be accessible simply by adding image descriptions to fill in the missing information.

Even when questions and answers are accessible, the page structure for multiple-choice games is not ideal for screen-reader navigation: Each answer is presented twice, and due to the lack of heading structure, there is no easy way to jump to the text of a new question after answering the previous one.

Students

The Students section contains resources such as maps/atlas, a citation builder, timelines, and articles. Unlike the Kids section, this page is filled with headings; however, the hierarchy is incorrect. Ideally, a single level 1 heading should come before the start of the main content, and subsequent headings should never skip levels. There are four level 1 headings on the page, none of which come before the main content, and subsequent heading levels seem to have been chosen based on visual appearance rather than hierarchy. To a screen-reader user, this heading structure will make very little sense. There are so many headings that efficiently navigating the page–or even truly understanding its layout–is difficult at any level of proficiency.

Image alt-text is also inconsistent on this page, with labels such as “thimage2” and “carausalimage0.” Many more images have alt-text that duplicates a nearby article title or caption.

The article archive (accessed by clicking “See More” in the articles section) also has an incorrect heading hierarchy. All section headings are at level 2, including the main heading at the start of the page. Ideally, this first heading should be changed to level 1, and a landmark should be added for the page’s main content. Lastly, the combo box to select previous months will automatically load new content as soon as the arrow keys are pressed, causing focus to jump back to the top of the page. Windows users can work around this issue by pressing alt+down, which expands the list of options and allows arrow-key navigation. WCAG recommends adding a “Go” or “Submit” button instead so that new content is not automatically loaded until the user activates this button.

Overall, the article view in the Students section is slightly more accessible and streamlined than the one found in Kids. A single level 1 heading serves as the article title, and some of the controls are presented as HTML buttons and links. However, there are still several accessibility challenges:

After the text of an article, a set of images is often provided. These images have alt-text, but it is simply the picture’s title with the words “image title” before it. This causes screen-readers to read each title twice. There is also no meaningful separation between the article content and this list of images.

The “How to cite this article” section is difficult to find with a screen-reader because it is not separated from the rest of the content. It is also a clickable piece of text rather than a link or a button. For some screen-reader users, it is difficult to tell if this can be clicked, and this problem is made worse by the lack of an alert when the citations have loaded.

The menu button is contained in a menu landmark, which is good. Unfortunately, it is still just a clickable graphic rather than an HTML button, as is the case with the settings toggle. The controls are also labeled as “hamburger-icon” and “setting-icon.” Ideally, these should be HTML buttons with clear labels.

When the settings menu is open, the “setting-icon” does not change to indicate this to a screen-reader. Changing this to an HTML button would also allow for the use of the aria-expanded property, which would tell screen-readers whether the menu is expanded or not. Instead, the settings menu silently appears below the icon with no meaningful separation from the rest of the content.

The “Change Voice” button also causes new content to load without a screen-reader alert. Apart from the combo box to select a voice, all the controls in this popup are clickable pieces of text. These would be much more useful as buttons.

Advanced

The advanced section seems to use pages that are similar to the Students section, with slight differences. The heading hierarchy is again incorrect, with no level 1 heading on “Headlines” and no landmark at the start of new content. There are also two unlabeled buttons under the “Featured” heading, which appear to scroll the carousel. Screen-readers do not report any changes when these buttons are pressed, even though new content has loaded. This gives the overall impression that these (unidentified) buttons do nothing at all.

If an article has a video, pressing “play” will cause the playback controls to disappear, and it becomes difficult to control the video with a screen-reader loaded. This player would benefit from a “Show Controls” button and a setting to prevent them from disappearing at all.

Search results are each denoted by a heading, but for screen-readers, the text is duplicated in a second link below each heading and the “Save to my Research” button includes a third instance of each result title. Navigating results by heading is quite efficient, but the extra labels are not necessary.

The article reader is similar to the one used in the Students section, but with some changes: The link to open the table of contents is called “Setting.” The “Back” button is a level 4 heading with no other control type. The navigation menu containing “Article,” “Media,” and “Related Information” consists of clickable pieces of text with no control type.

The button to start and stop the text-to-speech voice has no label. The button to adjust TTS settings is correctly labeled “Change Voice,” but the two words are rendered on separate lines, so screen-readers appear to read two separate buttons called “Change” and “Voice.” The voice adjustment settings are not separated from the rest of the page in any meaningful way, and they cannot be closed with the escape key. The two sets of radio buttons are rendered out of order, so when using the tab key or reading with a screen-reader, the user will see “Male,” “Slower,” “Female,” and “Faster.” Lastly, when navigating with the tab key, keyboard focus appears to land on the label of each radio button rather than the radio button itself. The screen-reader will not identify the controls as radio buttons or announce whether they are checked or unchecked. Most of these bugs are minor, but together they create a confusing experience when interacting with this popup.

Other Tools

These tools were found in multiple sections of the site and will be discussed here to avoid redundant information.

Activity Corner

Much like other sections of the site, the information on this page is readable with a screen-reader, but the lack of HTML markup means that navigation is inefficient.

In the Activity Corner, the first heading on every page is level 1, but it is placed on a “Classroom Project’s Logo.” This label does not change when a new page is loaded, so although the heading is a helpful way to find the start of the main content, it does not indicate the name of the page being shown.

When the landing page for Activity Corner first loads, the search field has the words “search by keyword” typed into it. This text is not highlighted, so typing an actual search term will not clear it; instead, the user will have the words “search by keyword” appended to their search query. While this is a general usability issue, it impacts screen-reader users who may not notice that the text field has extra words typed into it.

Search results are contained in a list with no headings on or before the results. Ideally, screen-reader users should be able to jump directly to the list of search results and move from one result to the next.

Activities can be filtered by several categories, including age range, time to complete, and cost of materials. Each of these filters has a “Select” link to open or close the filter choices. Screen-reader users often navigate directly to the next or previous link, so labels such as “Select” or “Click Here” can make this process unnecessarily cumbersome. When one of the “Select” links is activated, the page reloads, and screen-reader focus is brought back to the top, so it is necessary to navigate back to the category in question to read the choices. The categories themselves are links on a search results page, so their labels are clearer; however, the page still reloads whenever a filter category is expanded.

Once an activity is selected, the information page has a redundant level 3 heading before the instructions. There is also no heading before the list of materials. The “print,” “save,” and “email” icons are read twice by screen-readers. Since the text labels are rendered as links, it should be safe to remove the alt-text of these icons.

Timelines

The Timelines feature suffers from a lack of conventional HTML, making it difficult and frustrating to navigate with a screen-reader. Categories, timelines, and other controls are rendered as clickable pieces of text, each with an image whose alt-text mirrors the text label. Screen-reader users, therefore, have no choice but to navigate through every item on the page twice with no way to jump to specific sections of the page. The page does not allow for any keyboard navigation via the tab key; the only keyboard-accessible control on the page appears to be the search field.

While it is possible to expand categories and select timelines, there is no clear distinction between them. There is no indication of whether a category is expanded or collapsed. There is no announcement or focus change when the page updates with new or modified content, such as a category populated with new subcategories or a timeline of events appearing further down the page. Screen-reader users, therefore, found it difficult to determine when and where new content had loaded. The lack of headings or other meaningful page structure created further difficulty in exploring the content efficiently.

Much like the activity corner, the search field is populated with the words “search timeline” before any text is typed into it. Search results are loaded below the list of timeline categories with no meaningful HTML separation, so it is necessary to manually navigate past these categories to reach the list of results. Since there is no screen-reader announcement when results have loaded, they are easy to miss altogether.

When a timeline has loaded, the default view is very cluttered and difficult to navigate: Depending on the current zoom level, a collection of years is shown above the list of events (for example, 1900, 1905, 1910, etc.) There is no meaningful separation between these years and the events themselves.

Pressing the “switch view” link causes the timeline to be presented in table format. This view is much more navigable with a screen-reader and easily the most accessible portion of the entire timelines area. The table contains columns for the “event date,” “event description,” and “additional notes” (which do not appear to exist in the default view). Screen-readers are equipped with commands to navigate in any of the four directions within a table, so this view is intuitive and straightforward. The column headers are contained in an entirely separate HTML table, which means that screen-readers will not be able to read them automatically when navigating, and the page still contains no headings.

Development Recommendations

• Ensure all actionable controls (anything that does something when clicked) are coded as buttons or links to better facilitate screen-reader navigation
  • If it is not possible to change the HTML tags, these changes can be made using ARIA roless)
  • If the control has a state (checked or unchecked, expanded or collapsed), it must also be indicated via HTML, not just with a colour change.
• Ensure consistent colours with an accessible contrast ratio (4.5:1) are used across the site.
• Avoid using an image for the main heading of a page.
• Improve heading hierarchy across the site by adding a level 1 heading at the start of the main content and ensuring subsequent heading levels make sense. Include headings on search results.
• Remove alt-text when it is a duplicate of the text label. A simple alt=”” will cause screen-readers to skip over images that are not contextually relevant.
• Remove the role and label attributes from the “Remember My Library Card” checkbox on this login page so that it reads and functions correctly with screen-readers.
• Ensure essential textual information is not presented as an inaccessible image that cannot be properly magnified or read with a screen-reader.
• Improve access to games, particularly when the content is heavily text-based.
• Prevent screen-readers from reading two of every answer choice in text-based games
• Add an option to disable the child test-to-speech voice in the “Early Learning” section.
• Facilitate audio-described videos if the system does not allow for them already. If any future content includes an audio description, it will then become available to users.
• Ensure video playback controls can be shown with the keyboard when a video is playing.
• Ensure dropdown menus such as the filter choices in Activity Corner facilitate easy keyboard navigation, perhaps by using a combo box instead of a custom control.
• On the Timelines page, use HTML lists for categories (and nested lists for subcategories) to give the page some semantic structure for screen-reader users.

Conclusion

World Book is a unique and useful resource for students of all ages, offering free access through participating public libraries. Unfortunately, many of the available resources are difficult or impossible to access using assistive technology, and all pages of the site contain multiple accessibility barriers that would render the resource inaccessible to readers with print disabilities using assistive technologies. Most of the controls on the site are nonstandard with no accessibility enhancements, image descriptions are redundant and unhelpful, and colour schemes are not consistent between pages.

Systems and Assistive Technology

The following browsers and screen-readers were used while testing World Book:

• Browsers
  • Google Chrome 83, 87, 91 (Windows)
  • Google Chrome 91 (Android)
• Screen-readers
  • Jaws for Windows 2020 and 2021
  • NVDA 2021.1 (Windows)
  • TalkBack (Android 10)
• Screen Magnification
  • ZoomText 2020 (Windows)

Contributors

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

• Peter Field
• Maryse Glaude-Beaulieu
• Simon Jaeger (Lead Writer)
• David Kopman
• Riane Lapaire
• Ka Li
• Laetitia Mfamobani
• Deanna Ng
• Megan Sellmer

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

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

[2] 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.