Digital accessibility audit of the Readspeaker tool

How to get to these windows

Click on the the “Lees voor” button to open the player.

Click on the “Lees voor” button. The widget is added to the lower right corner of the page.

The Progress bar has a color contrast issues

The progress is indicated with an orange line (#EF6600) against a grey line (#677077). Here, only color is used to convey information about the progress. The contrast between these colors is only 1.6:1 and therefore too low to be clearly visible. (Fails 1.4.1 Use of Color)

If the orange line is displayed on a background that lacks sufficient contrast, it could hinder visually impaired visitors from perceiving this information effectively. (Fails 1.4.11 Non-text Contrast)

Focus order is not logical

When the “Lees voor” button is clicked, the focus moves to "Pauze" button. This is not a logical focus order. The focus must stay on the button "Lees voor". (Fails 2.4.3 Focus Order)

Vague accessible name of the close button on the popup player

The popup player features an "X" button designed to close the ReadSpeaker player. However, the button's accessible name, "Sluit," (“CLose”) does not sufficiently convey the specific function of this button. It’s not obvious that this button closes the player. (Fails 2.4.6 Headings and Labels)

Loading animation is missing proper markup

Upon clicking the "Lees voor" button, a loading animation is displayed. Unfortunately, this status message is not accessible to blind users. When a visitor triggers a specific process, the loading animation indicates that the application is busy and that the visitor must wait. However, the animation does not receive focus, despite conveying important information that qualifies as a status message. To ensure that screen readers can promptly announce this message, the animation should be assigned an appropriate role, such as aria-live="polite" or role="status". For more information on using role="status", visit https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA22 . (Fails 4.1.3 Status Messages)

Description

Each popup window contains buttons in the header and in the footer.

The header buttons:

The footer buttons:

Issues in the dialog windows

In the popup windows located in the header, there are buttons that open panels containing interactive elements. The volume and reading speed buttons reveal panels that include sliders, while the text mode settings button opens a panel featuring a text settings menu. These panels are designated with the role="dialog"; however, they lack accessible names. (Fails 4.1.2 Name, Role, Value)

These dialogs act as modal dialogs, which (among others) means that the keyboard focus should be 'trapped' within the modal dialog. This does not happen. (Fails 2.4.3 Focus Order)

Furthermore, the dialog elements are placed at the bottom of the DOM and the buttons to activate the dialogs and the dialogs themselves are not in any way connected. This means that the order is not meaningful. (Fails 1.3.2 Meaningful order)

Additionally, consider the panel of options that appears when the "More Options" button is clicked. This button becomes visible when the popup window is minimized in size.

Child roles that are not permitted have been assigned within a list element

In the popup windows located in the header and footer, the interactive elements are assigned the role="button". However, the first role of these button elements is "list." This results in the <ul> element containing direct children that are not permitted." To rectify this, ensure that the unordered list, defined by the <ul> element, contains only <li> content elements. Suggestion: place the button elements as a child element within the li element. (Fails 4.1.2 Name, Role, Value)

No accessible names for the slider elements

In the popup windows located in the header, the volume button activates a panel that contains a volume control slider. While the slider is appropriately assigned the role="slider" it lacks an accessible name. This same issue is also present with the reading speed slider. (Fails 4.1.2 Name, Role, Value)

Lang attribute must have a valid value

The lang attribute for the main content of the popup windows is currently set to "nl_nl." It is important to ensure that the language code specified in the lang attribute is valid. While some dialects can also be represented with specific codes, "nl-NL" is the preferred lang attribute for Dutch content intended for users in the Netherlands. (Fails 3.1.2 Language of Parts)

No alternative to mouse drag for repositioning popup windows

Users have the option to drag the popup window from its initial position to a different location using the mouse. However, there is no single pointer input alternative to achieve the same functionality. Some individuals may struggle to perform dragging movements with precision, while others rely on specialized or adapted input devices, such as trackballs, head pointers, eye-gaze systems, or speech-controlled mouse emulators, which can make dragging cumbersome and prone to errors. An alternative approach could involve a series of single pointer interactions, such as activating a target for movement. (Fails 2.5.7 Dragging Movements)

Focus possible on a non focusable element with tabindex=0

When opening the webReader menu, a non-modal dialog appears with the buttons "Instellingen" to "Help". After the last button "Help", the keyboard focus can land on the page underneath. This causes that the focus can be obscured. (Fails 2.4.11 Focus Obscured (Minimum)

How to get there

When the “Vergroot tekst” option is selected in the WebReader menu and the “Lees voor” button is clicked, an “Vergroot tekst” toolbar appears:

Accessible name of the close button is not meaningful

How to get there

Selected text menu is not accessible with the keyboard

The selected text menu, which appears upon text selection, can only be accessed by clicking with a mouse. This design excludes visitors who rely on keyboard navigation, including users with motor disabilities and those using assistive technologies. Consequently, keyboard-only users are unable to access the options offered by this menu. To enhance accessibility, the menu should also support keyboard interactions, ensuring that all users have equal functionality regardless of their input method. (Fails 2.1.1 Keyboard)

Focus can leave the selected text menu

When the selected text menu appears, it requires careful management of keyboard focus. Currently, the focus order is illogical, causing it to leave the menu and reset to the top of the page. While the menu is open, keyboard focus should be confined to the menu itself, preventing any shifts to elements outside of it. Effective focus management is crucial to ensure that visitors can navigate the menu seamlessly and avoid confusion from inadvertently interacting with content outside the menu.

To enhance accessibility, the focus should remain within the menu until the visitor closes it, such as by pressing the ESC key on the keyboard. Alternatively, the menu could close automatically if the focus shifts away from it. Implementing these changes will improve accessibility and enable visitors to navigate smoothly without encountering unexpected interactions. (Fails 2.4.3 Focus Order)

Time limit on selected text menu

When the Selected text menu is opened, and there is no interaction within 10 seconds, it closes again. This is a time limit that cannot be lengthened or adjusted. This causes problems for users who need more time to read and interact with the content. (Fails 2.2.1 Timing Adjustable)

Color contrast issue of the button border when it is focused

In the popup windows that open when clicking on the "Woordenboek" and "Vertalen" options, there is a button labeled "Ik begrijp het." When this button receives focus, a gray border appears around it. However, the gray border, which has a color code of #A8ACB8, against the light purple background with the color code #F4F2FC, yields a color contrast ratio of 2.0:1. It is essential that this contrast ratio meets a minimum standard of 3.0:1 to ensure adequate visibility and accessibility. (Fails 1.4.11 Contrast UI)

Wait animation does does not get focus and the status message is not accessible to blind visitors

When text is selected, a menu is displayed. If a visitor chooses the "Woordenboek" or "Vertalen" option in the desired language, a wait animation appears. However, this status message is not accessible to blind visitors.

When a user initiates a specific process, a loader icon animation appears to indicate that the application is busy and that the visitor must wait. Since this icon conveys information that qualifies as a status message, it should have the appropriate role to ensure that a screen reader can convey the message promptly. This can be accomplished by using either aria-live="polite" or role="status". For more information on using role="status", visit https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA22. This problem also occurs in other places, for example with translating the text. (Fails 4.1.3 Status Messages)

How to get there

Note: the popup was checked with the following sentence selected on the page: https://www.readspeaker.com/nl/solutions/tekst-naar-spraak-voor-online-lezen/readspeaker-webreader/ : “Laat je digitale content voorlezen met levensechte tekst-naar-spraakstemmen”.

List indicators has low color contrast

Under the heading “Woordherkomst en -opbouw,” there is a list featuring numeric indicators. However, the color contrast of these list indicators is inadequate. The red numbers against the white background (#FFFFFF) achieve a contrast ratio of only 3.0:1, whereas the minimum requirement is 4.5:1. (Fails 1.4.3 Contrast (Minimum))

Footnote reference links lack descriptive accessible names

In the popup text, footnote reference links are provided with accessible names that consist solely of the reference number, such as "1" under the heading "Woordherkomst en -opbouw." While it is visually apparent that these links correspond to specific content, the numbering alone fails to convey the link's purpose to screen reader users. To enhance accessibility, additional context should be incorporated to clarify the purpose of these links for users who rely on screen readers. It is essential that link texts clearly describe their destination, which can be achieved by appending extra, non-visible text to the links.

Under the heading “Afgeleide begrippen,” a list includes a final item that contains a sublist. Within this sublist, several links are accompanied by an arrow-up icon. However, the accessible names of these links consist only of the arrow-up symbol, which may confuse screen reader users. The inclusion of the symbol in the accessible name does not provide meaningful information regarding the links’ purpose, as screen readers announce the symbol, potentially leading to misunderstanding. To address this issue, the accessible names for these links should explicitly describe their function without incorporating unnecessary symbols, thereby facilitating easier navigation and comprehension for visually impaired users. (Fails 2.4.4 Link Purpose (In Context))

Empty <th> in the data table

Under the heading “Woordherkomst en -opbouw,” there is a table where the first cell is a <th> element that contains no content. In a data table, it is essential that either the column header row or the row header column is formatted with <th> elements to clearly establish the relationship between these header cells and their corresponding data cells for screen reader users. Empty <th> cells can create confusion, leading blind visitors to believe that content is missing. To enhance accessibility, either populate the <th> cell with meaningful text or convert the empty <th> cell into a <td> cell. (Fails 1.3.1 Info and Relationship)

Proper markup is missing for the complex table

The table under the heading “Woordherkomst en -opbouw” is a multidimensional table; however, it lacks the appropriate markup. When a table includes both column headers and row headers, they must be correctly formatted. The column headings should utilize <th> elements, while the row headers can be formatted with <th> elements that have a scope="row" attribute. This allows data cells in the corresponding row to reference the IDs using a headers attribute. (Fails 1.3.1 Info and Relationship)

Single list is divided into several lists in HTML

Under the heading “Afgeleide begrippen,” there is a list of four items that visually appears as a single cohesive list. However, in the HTML markup, this list is incorrectly divided into separate lists, with each list item represented by its own <ul> element. This structure leads to accessibility issues, as screen readers interpret each <ul> element as an independent list, disrupting the perception of a unified list.

To address this issue, all items should be combined into a single <ul> element. This change will ensure that the HTML structure accurately reflects the visual layout, providing a clearer and more accessible experience for users of screen readers.

Additionally, the last item in the list contains an ordered sublist, but in the current HTML, the main list and the sublist are coded as separate lists. This separation can confuse users relying on assistive technology, as screen readers may see the sublist as an independent list rather than as part of the last item in the main list. Consequently, the logical flow and hierarchy of the content are disrupted, making it difficult for users to grasp the relationship between the list items. To enhance accessibility, the sublist should be properly nested within the last item of the main list in the HTML. This adjustment will ensure that assistive technology interprets it as an integral part of the overall list structure. (Fails 1.3.1 Info and Relationship)

How to get there

The accessible name of the input field is not descriptive

When the "Vertalen" button is clicked, the drop-down list opens, revealing a search field. However, the accessible name of this input field is set to "undefined," which is determined by the aria-label attribute and overrides other methods of providing an accessible name. It is crucial for an input field to have a meaningful and unique accessible name that clearly conveys the type of data a visitor is expected to enter. This ensures that users understand the purpose of the field effectively. (Fails 2.4.6 Headings and Labels)

Visible text is not part of the accessible name of the input field so the field can’t be activated with voice

The search field within the language drop-down list features the placeholder text: “Taal zoeken.” However, the accessible name of the input element is currently set to “undefined.” It is essential that the visible text is included in the accessible name of the element. If the placeholder text differs from the accessible name, the input field may not be voice-activated. To ensure optimal accessibility, the visible text should be incorporated into the accessible name, ideally positioned at the forefront. (Fails 2.5.3 Label in Name)

Part of content in another language

The popup contains text in a different language: “Powered by Google Translate.” However, there is currently no language code assigned to this content. As a result, the screen reader pronounces this text according to the language specified in the lang attribute of the HTML element, which in this case is set to "nl." To ensure the screen reader correctly identifies the language, the foreign-language content should have its own lang attribute. To achieve this, add lang="en" to the container that holds this content. Alternatively, you could translate this text into Dutch. (Fails 3.1.2 Language of Parts)

How to get there

Custom focus indicator on the selected tab lacks sufficient contrast

In the "Instellingen" popup, there is a side navigation menu consisting of four tabs. When a tab is selected and gains focus, its border changes color. However, this custom focus indicator has inadequate color contrast against the tab's background color. The background color is a dark purple (#6F4FF0), while the focus border is a light purple (#A690FF), resulting in a color contrast ratio of 2.0:1. This falls short of the required minimum of 3.0:1.

Unlike the default focus indicator, which automatically meets this success criterion and can be adjusted by users, the custom focus indicator cannot be modified by visitors, making it essential that it adheres to the contrast requirements. (Fails 1.4.11 Non-text Contrast)

Elements with the role ”tabpanel” have no accessible names

In the "Instellingen" popup, there is a side navigation menu featuring four tabs: "Highlighting," "Overige instellingen," "Sneltoetsen," and "Standaardwaarden herstellen." Each tab opens its corresponding tab panel; however, the tab panels currently lack accessible names. To improve accessibility, each element designated with the role of tabpanel must include the property aria-labelledby, which should reference its associated tab element. (Fails 4.1.2 Name, Role, Value)

The element with role="tablist" needs a name (with aria-label or aria-labelledby and aria-orientation="vertical". See W3.org Tutorial.

When selecting a tab, the focus needs to go to the contents of that tab. Now it first goes to the other tabs before it lands on the contents of the selected tab (Fails 2.4.3 Focus Order)

Buttons border color has insufficient color contrast against the background

The buttons used to control text highlighting feature a grey border (#999999) against a white background (#FFFFFF), resulting in a color contrast ratio of 2.8:1. However, this ratio must meet a minimum requirement of 3.0:1. (Fails 1.4.11 Non-text Contrast)

Unexpected behavior of buttons

In the "Instellingen" popup under the "Highlighting" tab, there are radio buttons labeled "Tekst highlighten." When the "Uit" button is selected, the settings in the "Wat te highlighten" section become disabled. While it is visually apparent that the buttons for "Woordkleur," "Zinskleur," and "Textkleur" are disabled, this information is not accessible to blind and visually impaired users who rely on screen readers. (Fails 1.3.1 Info and Relationships)

An attempt was made to use the "disabled" attribute on the buttons; however, this approach is ineffective since the attribute is applied to input elements that are hidden from the screen reader. Instead, the "disabled" attribute must be set on the elements with the role="radio." (Fails 4.1.2 Name, Role, Value)

The radio buttons still can receive keyboard focus. This is not a logical focus order. (Fails 2.4.3 Focus Order)

Also, when using a screen reader, you can still access the hidden information, and the radio buttons lack the accessible names. Hide the buttons for the tooltips from the screen reader and do not let them receive focus. Consider of hiding all this content as a whole and for all users.

Accessible name of button does not match the visible text

On the "Sneltoetsen" tab, under the "Sneltoetsen" label, there are buttons designated for assigning shortcuts. The accessible names for these buttons are defined using the aria-label attribute. For instance, beneath the "Voorleesknop en player" heading, there is a button featuring key icons as preset text and a visible label reading "Afspelen." The aria-label for this button states, "Toegewezen toetsencombinatie voor 'Afspelen'. Klik om deze sneltoets te wijzigen." Additionally, each button includes a title attribute that provides the same instructions as the aria-label, along with the assigned key combination.

However, this results in a significant discrepancy between the accessible name and the visible text, which can hinder accessibility for visitors who rely on voice activation technologies. To enhance voice activation effectiveness, the visible text should be incorporated into the accessible name, ideally positioned at the beginning. For example, the accessible name for the "Afspelen" button could be revised to "Afspelen Shift + Ctrl + Alt + L." The title attribute can then contain supplementary instructions, such as "Toegewezen toetsencombinatie voor 'Afspelen'. Klik om deze sneltoets te wijzigen." (Fails 2.5.3 Label in Name)

The same accessible name for the “X” buttons performing different actions

On the "Sneltoetsen" tab, each button assigned with a shortcut features an "X" button that removes the key combination from the button. However, these buttons share the same accessible name: "Sneltoets wissen."

While the visual context makes the purpose of these buttons clear, this clarity does not extend to individuals who are blind and rely on assistive software. When using the Tab key to navigate through interactive components, the identical accessible names can lead to confusion. Assistive technologies cannot automatically interpret context, which means that the accessible name of each button must effectively convey its function and significance.

Having multiple buttons with different functions but the same accessible name can be perplexing for screen reader users, as it becomes unclear which action each button performs. To enhance accessibility, it is essential that the accessible names accurately reflect the specific functions of the buttons. (Fails 2.4.6 Headings and Labels)

Checkbox accessible names do not include summary indicators information

On the "Standaardwaarden herstellen" tab, there are checkboxes accompanied by summary indicators displayed as numbers in parentheses next to each checkbox label. These indicators reflect counts related to each setting. However, the accessible names of these checkboxes do not include this summary information, which may render it inaccessible to screen readers. Consequently, users who rely on screen readers might miss this important contextual information, which is crucial for understanding the state or function of each checkbox option.

To address this issue, it is essential to incorporate the summary indicators into the accessible names for each checkbox. This adjustment will ensure that screen readers convey both the checkbox label and its corresponding count, thereby enhancing accessibility for all users. This issue is caused by the aria-label on the label elements. (Fails 2.4.6 Headings and Labels)

Button text is truncated when the tab “Sneltoetsen” is viewed at a screen resolution of 1280 by 1024 and zoomed in to 400%

When the "Sneltoetsen" tab is viewed at a screen resolution of 1280 by 1024 and zoomed to 400%, the text on the buttons that display key combinations becomes truncated. It is essential that the website remains accessible at this screen resolution and zoom level, ensuring that all page content is easily readable. Visitors with disabilities should have full access to the information presented on the page. (Fails 1.4.10 Reflow)

Excessive use of aria-label

The following observations are not outright incorrect but could benefit from improvement. However, in some cases it does lead to failures. Examples of these failures are mentioned in this report.

In the “Instellingen” popup, all tabs feature groups of interactive elements, such as those found under “Tekst highlighten” and “Wat te highlighten” on the “Highlighting” tab. These groups are appropriately structured in HTML using <fieldset> and <legend> elements. However, the inclusion of aria-label attributes on the <legend> elements is unnecessary and redundant.

Similarly, across all tabs, radio button groups, like the “Automatisch scrollen” option on the “Overige instellingen” tab, are marked up with <label> and <input type="radio"> elements, each accompanied by an aria-label attribute.

This redundancy can lead to the same information being announced multiple times by screen readers, potentially creating a confusing user experience. While the use of WAI-ARIA is intended to enhance accessibility, improper or excessive implementation can inadvertently result in accessibility issues. (Fails 1.3.1 Info and Relationships)

How to get there

Reading mask overlay is not keyboard operable

When the “Pagina maskeren” option is selected in the webReader menu, a reading mask overlay is displayed. However, this element cannot be operated using the keyboard. It is essential that visitors navigating the website without a computer mouse—relying solely on keyboard controls—are able to interact with all elements. All functionalities should be accessible via the keyboard. The buttons in this mask overlay are also not accessible. (Fails 2.1.1 Keyboard)

Close button accessible name is not meaningful

The reading mask overlay features a close button represented by an "x" icon, with the accessible name "Sluit." While the button's purpose is visually apparent within the context of the overlay, it may not be as clear for individuals who are blind and rely on assistive technology, particularly when navigating with the Tab key. Assistive software cannot automatically interpret the context of the button, making it essential to enhance its clarity for users of such technologies. Improving the button's description would provide greater accessibility and understanding for all users. (Fails 2.4.6 )

Color contrast issues of the buttons on the reading mask overlay

The reading mask overlay includes several buttons, but the color contrast of the following buttons may be insufficient against the webpage background: the buttons featuring the icons “-”, “+”, and “?”. The “-” and “+” icons are rendered in dark purple (#444464), while the “?” icon appears transparent on the same dark purple background. As a result, on certain page backgrounds, these buttons exhibit low color contrast, making them difficult to see. This can be solved by adding a light border to the buttons. (Fails 1.4.11 )

How to get there

Please note that the content of this popup varies depending on the page from which it is opened. The accessibility and functionality of this popup have only been verified on the page titled “ReadSpeaker webReader - ReadSpeaker.” As a result, there may be untested or inconsistent behavior when viewed on other pages containing different content.

Alt-text for image is in different language

The popup contains an image that illustrates the features of ReadSpeaker webReader. The primary language of the page is Dutch, while the alt text is provided in English. It is recommended to translate this alt text into Dutch for better accessibility. Alternatively, you could indicate a language switch for these texts using a surrounding HTML element with the attribute: lang="nl". The same issue applies to the text located beneath the image. (Fails 3.1.2 Language of Parts)

How to get there

Paragraph of text is missing proper markup

Under the heading "Toetsenbordnavigatie," there is a paragraph that begins with "Bij de uitleg van de functies lees ...". However, this paragraph is not properly marked up in the HTML. To accurately represent the visual structure of the information presented on the page, the text should be enclosed within a <p> element. (Fails 1.3.1 Info and Relationship)

List is lacking proper markup.

Under the heading "Privacybeleid," there is a list containing three items. However, the appropriate markup is currently absent. By formatting the list with a list element, such as <ol> or <ul>, the structural information conveyed by the text will also be accessible to assistive technologies. (Fails 1.3.1 Info and Relationship)

Change of context on focus

In the popup, there is a button labeled "Inhoudsopgave" that opens a menu containing navigation links. However, when a visitor tabs through the page, the focus shifts directly to the first link in the menu, even though the menu itself is hidden. Consequently, the content of the popup disappears, leaving a blank screen. This represents a significant change in context. Focusing on an element should not automatically trigger a context change unless users have been adequately informed in advance.

As visitors navigate through a page using the tab key, they may become disoriented or, worse, completely unable to access the content. This issue is particularly critical for individuals with visual impairments, cognitive limitations, and motor disabilities. Any component that triggers an event upon receiving focus should not alter the user's context. This practice will help ensure that all users can navigate the page in a consistent and predictable manner. (Fails 3.2.1 On Focus)

This issue also affects the focus order. The navigation sequence of focusable elements should be logical and intuitive. Focus should not land on interactive elements (such as links, buttons, or form fields) that are not visible, as this can result in the unintended activation of these elements. Only visible elements should be allowed to receive focus. (Fails 2.4.3 Focus Order and 2.4.11 Focus Not Obscured (Minimum))

Focus can leave the “Inhoudsopgave” menu

When navigating with the keyboard and opening the "Inhoudsopgave" menu, the focus initially lands within the menu. However, upon reaching the last item, the focus unexpectedly shifts to the interactive elements in the popup. This creates an illogical focus order. Ensure that the focus remains within the menu until the visitor closes it. (Fails 2.4.3 Focus Order)

Focus order in the pop-up

When the "Inhoudsopgave" button is clicked and a link is selected, the popup scrolls to the corresponding section, and a blue animated underline appears beneath the section heading to signify the selected content. However, this animated underline does not receive focus and is not announced by the screen reader as a status message.

The viewport moves to the content, but the focus doesn't, so people using a screenreader cannot continue reading this chapter. (Fails 2.4.3 Focus Order)

Multiple h1 elements within the popup

The following recommendations are advisory but can enhance the accessibility of the page. The popup currently includes multiple level 1 headings (h1). It is advisable to use only one <h1> per page. Although the HTML standard permits multiple <h1> elements on a single page (provided they are not nested), this is not considered a best practice. A page should typically contain a single <h1> element that effectively describes its overall content.

Animated gif is playing automatically and can not be paused or stopped

The “Hulp bij vertaling” popup features an automatically playing GIF, but it lacks any options to pause, stop, or hide the content. Moving, blinking, or scrolling elements can be particularly disruptive for individuals with cognitive impairments, as they may find it challenging to focus on the static content while being distracted by the animation. For any automatically initiated moving content that is displayed alongside other content and lasts longer than five seconds, it is essential to provide a mechanism that allows users to stop, pause, or hide it. (Fails 2.2.2 Pause, Stop, Hide)

Alt attribute is absent on img-element

The GIF image has been added using an <img> element, but it is missing an alt attribute. When including an informative image through an <img> element, it is crucial to provide an alt attribute; otherwise, screen readers will announce only the file name. This oversight renders the image inaccessible to visitors who are blind. (Fails 1.1.1 Non-text Content)

List indicators have low color contrast

The list indicators beneath the text "Hoe kun je vertalen?" exhibit inadequate color contrast. The yellow numbers against the white background (#FFFFFF) have a contrast ratio of 3.0:1, which falls short of the required minimum of 4.5:1. (Fails 1.4.3 Contrast (Minimum))