Testing instructions
Screen reader programs can be used early on in the development phase to check for potential WCAG breaches that are not only common, but also serious for users. Examples of such criteria include:
- WCAG 1.3.1 Info and Relationships
- WCAG 1.3.2 Meaningful Sequence
- WCAG 3.1.1–3.1.2 Language of Page and Language of Parts
- WCAG 3.3.1 Error Identification
- WCAG 4.1.2 Name, Role, Value
- WCAG 4.1.3 Status Messages
Screen readers are particularly effective for verifying criterion 4.1.2 Name, Role, Value. It should be verifiable in all published code starting from the implementation phase; after getting used to it, the testing process will be straightforward. The browsing order (criteria 1.3.2 and 2.4.3) is also easy and important to verify when creating more complex so-called composite elements (see Module 3 / Document X) or when components are combined into a navigation system, for example. A third criterion that is easy to test but still important is WCAG 1.3.1, which requires that the name given to the form controls of the service, such as input fields, is specified in a manner that aid device programs are also able to interpret when the user focuses on the control.
WCAG 4.1.2 Name, Role, Value: Testing
When the user focuses on an element on the web page with a screen reader, the aid device conveys three key pieces of information about it: its name, role and value. Not all elements have all of these properties – at least not in a way that the screen reader is needed to convey. For example, a text paragraph (‘<p>’ tag) on a web page only contains a name (the text of the paragraph) without a specific value. It has the paragraph role, but this is normally not indicated separately, as describing the role of every paragraph would be very arduous for the user. Instead, the ‘anchor (a)’ tag has not only a name (link text), but also a role (link) and potentially a value or status, which is either “visited” or “unvisited”. The aid device indicates the role of the link because it is important for a user who is presumably unable to assess the page view visually to be able to distinguish the link from the so-called body text.
The trio of name, role and value is important to test when developing customised components. In other words, when a button is created from, say, an ‘<img>’ tag instead of a ‘<button>’ tag, the aid device must be able to indicate that this element that functions exceptionally (differently from a basic image) is actually a button by role. If the button in question is a menu button in particular (even more specific role), the screen reader must also indicate whether the menu is open or closed (value/status). Naturally, the name is the text of the menu button or another description intended for aid devices that can be given as an element attribute when there is no visual text or the text is inadequate. In the WCAG, ‘name’ refers to an accessible name that is a concept broader than the visual text content of the page. The materials for developers featured in Module 4 of Helsinki’s Accessibility Model provide more detailed information about setting the name, role and value attributes.
WCAG 4.1.2 can be tested by focusing on every customised component with a screen reader and assessing whether the name of the element is conveyed in the information produced by the screen reader. For example, if a dialogue is closed with an ‘X’ icon, the screen reader must still describe the element with a name, such as “close”.
The next step is to assess whether a role is conveyed from the element. For example, the role of the aforementioned closing button should be “button”; otherwise the user cannot know that the object in question functions specifically as a button. The third aspect to be assessed is whether the screen reader describes the element’s potential value or status correctly.
The aforementioned button does not have such a value, as its status does not change. But if the button is an instructional icon on a form whereby clicking on it opens a so-called pop-up area, it also has a status (“open/expanded” or “closed”) in addition to its name and value. The status depends on whether the pop-up related to the button has been opened or not. Correspondingly, the value or status of an element such as a check box is “selected” / “not selected”. Ergo, it depends on the element what its role and value/status should be or whether it even has a value/status. This takes some familiarisation with using a screen reader, but the process is quite clear once the tester has become accustomed to listening to elements, especially if they have a basic understanding of elements produced for web pages, at least at the level of HTML code.
Finally, the element is activated, i.e. “clicked” with the screen reader (selected, unselected or opened, closed, etc) while simultaneously assessing whether the change in status or value is also conveyed correctly.
This can be practised through means such as the controls in the ‘Buttons’ tab on the demo page of the Accessibility Model, the log function of which shows how the attributes of the test elements change.
WCAG 1.3.2 and 2.4.3
Reference to training materials. Reference next week.
WCAG 3.3.1 Error Identification
Reference to training materials. Reference next week.
Testing tools: Keyboard browsing
In addition to using a screen reader, an important aspect of accessibility testing is using the service with a keyboard and no mouse or screen reader. It is important to note that screen reader use is not equivalent to keyboard use, even though the screen reader of a desktop computer is often controlled with a keyboard.
‘Keyboard browsing’ refers to using and navigating the website with the Tab key. With this method, the browser moves the focus between the interactive elements on the page. Interactive elements include all links, buttons and form controls, as well as elements that are separately marked as interactive in the code. The browser will not – nor is it supposed to – focus on passive text content and images, while a screen reader will focus on all of the contents on the web page that are not separately hidden from aid devices. It is important to be aware of this difference when testing the service with a keyboard.
A keyboard is not an aid device for a browser. This means that the browser will ignore the WAI-ARIA attributes intended for aid devices when no screen reader is used. What follows is that it cannot be automatically assumed in the testing situation that because a part of the service works with a screen reader, it will also work with a keyboard. This is not automatically the case. For example, customised elements with missing keyboard processors or so-called tab indexing cannot necessarily be activated or even focused on with only a keyboard and no screen reader. The reason is that a screen reader will send a click event for the element, making it able to activate the same element as mouse/touch users. The focusing of the screen reader is not dependent on tabindex values, either. You can read more about this subject in the developer materials of Module 4.
Testing keyboard browsing in practice
Keyboard browsing is primarily subject to WCAG criteria 2.1.1–2.1.2. The criteria stipulate that all functions on a web page must be accessible with a keyboard and no mouse, unless the nature of a function is such that it can only be used with a pointer (e.g. some game-like functions or drawing). As such, the tester must check that every interactive element on the page is focused on in turn when the user is navigating the page with the Tab key. If the element can be activated (opened/closed, activated/deactivated, etc.) with a mouse, the same activation must be possible with a keyboard, e.g. with the Enter key or the space bar.
Keyboard browsing is subject to other criteria as well. WCAG 2.4.3 Focus Order stipulates that the elements on a web page must be focused on in a logical order, meaning that when the page is navigated with the Tab key, the focus “jumps” from element to element in accordance with the logical structuring of the page. For example, if the user has activated a menu button to open a dropdown menu, the focus should next move to the first object in the menu instead of moving forward on the page “under” the menu. In turn, if the menu is closed, the focus should move from the menu button to the next object and not inside the closed menu, for example.
The focus order often follows the layout of the page – from top to bottom and from left to right – but it can also deviate from this if the deviation is justified. You can find more information in the service design materials of Module 3 and the developer materials of Module 4.
If the browsing order is not taken into consideration in the implementation, the user may not encounter the aforementioned dropdown menu until they reach the end of the page, as the browsing order always follows the DOM order, not the visual layout. Accordingly, forms and modals are common problem areas in keyboard browsing (see Module 4 / developer instructions). These content types are paid special attention to in the testing of keyboard browsing.
Keyboard browsing is also subject to the visual testing criterion WCAG 2.4.7 Focus Visible. Further information and examples:
Module 3 / General instructions for service design:
Original version: Tero Pesonen / Siteimprove
Created: 3 April 2021.