Accessibility

1.4. State of button elements is not announced to screen reader users 

1.4.1. WCAG 1.3.1 (A), 4.1.2 (A), 4.1.3 (AA) - Desktop, Mobile

There are several instances throughout the site where the state of interactive button elements are not announced to screen reader users. Sighted users can see the dynamic changes on the screen, however, screen reader users are not given this context.

For example:

• When a user selects the magnification tool in the Recite me toolbar, the state (enabled / disabled) is not announced to the user.

• On the Edinburgh fostering page, the state of the hamburger menu (expanded / collapsed) is not announced to users.

• On the Council Tax Change of address page on desktop and mobile, the state of accordion elements (expanded / collapsed) is not announced to users.

Furthermore, in some cases when the user selects this element, new content renders on the page dynamically. This new content is not announced to screen reader users.

Visually, there is some indication based on the change on screen (such as the magnifying glass or dictionary dialogue). However, note that even visually, the buttons themselves do not show any indication that they have been selected.

This is similarly persistent on other elements on the site: users are not informed when menus and accordion buttons are expanded on pages like the Edinburgh Fostering page, Pay a Roadworks Penalty page, and some of the mobile screens.

1.5. Buttons and links not programmatically associated with context

1.5.1. WCAG 1.1.1 (A), 1.3.1 (A), 2.4.4 (A), 4.1.2 (A) - Desktop, Mobile

On multiple instances throughout the site, there are buttons and links that are not programmatically associated with the corresponding context.

For instance, in the ReciteMe toolbar the colour theme button are visually associated with the context (Dark background and light background). These buttons are adjacent to the sections and are spaced out with dividers for additional clarity.

Similarly, on the Birth Registration journey, the ‘Book’ buttons are visually associated with the Date and start and end time" by being placed within the same row.

However, for screen reader users, these buttons are only announced as “Clickable A” or “Row 3 book button”. There are multiple buttons with the same label, and these do not provide users with any context as to their purpose.

2.1. Purpose of the Speak/Translate button is unclear 

2.1.1. WCAG 1.4.10 (AA), 2.4.4 (A) - Desktop, Mobile

When the user navigates to the “Speak/Translate” button, it is announced as ‘Speak / Translate’ button, this does not inform the user visually or programatically that the button opens the ReciteMe accessibility toolbar.

In addition, viewing the website on mobile with screen reader activated, it is announced as “button” which provides no additional context to help users understand the purpose of the button. This issue also occurs when 400% browser zoom is applied to the website, screen reader announces the element as “button” with no additional information.

2.2. Dictionary and Audio Download require mouse dragging movements

2.2.1. WCAG 2.1.1 (A) - Desktop

When using the ReciteMe toolbar, users are given the option to look up the dictionary definition of certain words or download the audio file of the text. Users can do this by selecting the desired words / text on the page.

However, this feature cannot be used by keyboard users. Selecting the text requires dragging movements using a pointing device such as a mouse. There are no keyboard-specific shortcuts for users to select specific parts of the content on screen. This results in an unequal experience between mouse and keyboard users.

This is related to WCAG 2.2’s Dragging Movements (to be released).

This is not an issue on mobile devices since the Dictionary and Audio Download options are not provided.

2.3. Title attributes are not available for sighted keyboard users

2.3.1. WCAG 1.1.1 (A), 1.4.13 (AA), 2.4.6 (AA) - Desktop, Mobile

In the ReciteMe toolbar, there are different buttons to aid with accessibility. The purpose of these elements is announced to screen reader users and mouse users can hover to see what the button does. However, keyboard users are not provided with the purpose of these elements as the mouse hover effect is not the same as when it receives focus and may avoid interacting with the buttons because they don’t know their purpose.

2.4. Sub-menu options announced without being expanded on mobile

2.4.1. WCAG 1.3.2 (A), 2.4.3 (A), 4.1.1 (A) - Mobile

When using the swipe gestures to navigate through the ReciteMe accessibility toolbar on mobile, TalkBack and VoiceOver announces the submenu options (such as Verdant, Comic Sans etc. within the Fonts menu or the radio buttons within the Settings menu) when the sub menu is not activated.

This can be very confusing for assistive technology users. Screen reader users would not know why these items are being announced and may think that they are missing out on relevant context. For sighted users navigating using just swipe gestures, they would not know where their focus is and might think that the page is not functional.

2.5. Sub-menu options are not accessible using swipe gestures (High)

2.5.1. WCAG 2.1.1 (A), 2.4.3 (A), 4.1.1 (A) - Mobile

The ReciteMe accessibility toolbar includes buttons such as the language selector which activates a submenu to appear with more options for users to choose from.

These buttons are accessible using standard touch features, however, these controls are inaccessible when VoiceOver or TalkBack is activated. Focus does not move into these sub-menus, so users would not be able to use all the features provided in the tool bar.

2.7. Non-focusable section announced by screen readers 

2.7.1. WCAG 1.1.1 (A), 2.4.3 (A), 2.4.4 (A), 4.1.1 (A), 4.1.2 (A) - Desktop, Mobile

When navigating the site using a keyboard, screen readers announce “section section” in the ReciteMe tool bar followed by “close Recite button” and “Recite logo button.” Upon inspection of the code, it is unclear why screen readers announce “section section”. This inconsistency between the visual presentation and what is announced by screen reader is likely to cause confusion for screen reader users. In addition, the focus order does not follow a logical sequence as focus moves from the close button and then to the ReciteMe logo. This does match the natural reading order of the page.

2.8. Language search results not announced (Medium)

2.8.1. WCAG 1.3.1 (A), 4.1.3 (AA) - Desktop, Mobile

Within the Recite Me toolbar, when keyboard users populate the Language search field, the screen

dynamically changes to reflect the results. However, these updates are only presented visually. Screen

reader users are not informed of these changes occurring within the list.

Furthermore, if a search does notmatch any criteria, nothing is displayed to sighted users or announced programmatically to screen reader users. Tabbing after a search yielding no results just takes users to the next button. This could lead to them thinking that the search button doesn’t function as expected.

2.9. Screen reader users not informed when audio is available for particular

languages

2.9.1. WCAG 1.1.1 (A), 1.3.1 (A), 4.1.1 (A) - Desktop, Mobile

The ReciteMe accessibility toolbar allows users to change the language of the page by selecting an option from the Language menu dropdown. Some of these languages have text-to-speech support. That is, users can avail the in-built audio function to have the content read out, even in a different language. The languages that offer this support are marked visually with a speaker icon. However, screen reader users are not provided with this additional context. There is no programmatic distinction between languages that offer this audio support and those that don’t.

2.10. Positive tab indices used

2.10.1. WCAG 4.1.1 (A) - Desktop, Mobile, Automated Finding

The elements of the ReciteMe toolbar make use of positive tabindex values to bring them into the focus order of the page. Tabindex values of 1 or greater specify an explicit tab / navigation order for page elements. Positive tabindex values are fragile  - whenever new content is inserted in the tab order, every subsequent tabindex value has to be updated. Failure to do this results in focus moving in unexpected ways, which causes much user frustration. The use of positive tabindex values is considered an anti-pattern, and should be avoided. Native HTML links, buttons and inputs all receive keyboard focus by default, so there is no need to add the tabindex value to them. This is an automated finding detected using WAVE.