Websites when built with semantic code, applying all the native elements and attributes of the markup most of the accessibility features are taken care of. This is not possible with new dynamics in the modern web.
The modern websites have dynamic content, continuous live updates and most importantly custom components. Custom components are those built with one or more native elements to bring a different and easy experience to the users. They also help the users to see the only information while hiding the rest. Eg: In earlier days if a page contains 4 sections on the page they are displayed one after the other in the DOM. When the page is loaded the entire content is displayed before the user. It is the user who have to just scroll the page to view the required content. The same content in the modern websites may display only one section, probably the first one or sometimes none when the page loads. The user have to activate the section they need to display relevant content. This features not only saves the web real estate but provides the user only the information they need.
In case of live content, the modern websites have the capability to allow the user choose if they need the updates, if they need in what frequency do they need it e.g. each time they are available, once in 5 minutes , once in 15 minutes or completely to switch off the updates etc. In the older web, user has to refresh the page or the entire web page refreshes when the new content is available which is not the case now.
Coming to the problem, since these components are constructed with the group of elements, the same visual context that is provided on the screen is not same as what is provided for a screen reader user. In the first example, the content can be shown/ hidden or in other words the elements can be expanded or collapsed. Looking at the screen anyone can say that the content has this expand / collapse behavior. The same experience is not available for screen reader users in general. This means the current state of the element (expand/collapsed) is not exposed to screen reader users.
Custom components such as mega menus, tab panels, carousels, sortable tables have names, roles, states, properties and values. This success criteria talks about the accessibility problems of these custom controls.
Validation for names
A name or an accessible name is something read out by the screen reader when user focus on it. In the case of accessible name, the text read-out by the screen reader is not necessarily visible on the screen. In other words accessible name is different from a label.
- Open the page on the browser when the screen reader is switched on.
- Navigate to all the controls on the page e.g. links, form elements and other custom components.
- When the user reaches to each element, screen reader must announce its accessible name. e.g. cancel button where cancel is the accessible name.
- If all the controls have accessible names then this requirement of the success criteria is considered as passed, and the test engineer have to check other requirements of the success criteria described in the next sections.
- If any of the elements does not have accessible name, then this requirement of success criteria is considered as failed.
Validation for roles
A role is a simple information shared out to the user to understand the type of element and it’s behavior. By looking at a link one will understand that it takes to a different page, a button submits some data to the server or does an action for the user, a radio button selects an option from a group etc. These types of elements are called roles. A link is a role, a button is a role etc. When accessed with the screen readers each element except for a paragraph, line of text all other elements should have a role announced. In case of custom controls the tabs, menus also need to be informed to the user.
- Open the page on a browser when the screen reader is switched on.
- Navigate all the elements on the screen and check if all the elements have a role read out by the screen reader.
- If all the elements are having a role assigned ,
- Check if these roles are appropriate to the function of the element.
- If the roles are available and are appropriate then this requirement of the success criteria is considered as passed and the test engineer have to check other requirement of the success criteria described in the next sections.
- If the role for one or more elements are not provided this success criteria is considered as failed.
Validation for state
Few elements on the page have certain properties such as selected or not selected. E.g. A check box can be either checked or unchecked, a tab can be selected or not selected, an accordion element can either be expanded or collapsed. These properties of the elements are called as states. If the native elements of the markup are used, the states are automatically taken care. Specifically check the custom controls and components for this success criteria.
- Open the page on a browser when screen reader is switched on.
- Navigate the entire page and check if any elements exist that have a state that can be toggled by the user.
- Verify if the initial state is announced by the screen reader. It is not necessary that the elements are in unchecked or unselected states on page load. They can be even in selected or checked state.
- Change the state with actions such as space key or enter key. Verify if the change in state is announced by the screen reader.
- If the initial state and the changed state is announced by the screen reader this requirement of the success criteria is considered as pass and the test engineer have to check other requirements of the success criteria described in the next sections.
- If the initial state or the changed state is not announced this requirement is considered as failed.
Validation for properties
Some elements on the page has specific properties depending on how they can be used on a page. E.g. A menu on activation can pull down menu items, a column in the data table can be sorted using the column header. Unless these properties are exposed to the screen reader users they will not be able to use the functionalities. The properties of these kind of elements should be reported to the screen reader users with specific instructions in operating them if necessary.
- Open the page on the browser when the screen reader is switched on.
- Navigate through the page and check if any elements on the page have these specialized properties.
- If such properties are available verify if they are communicated to the screen reader users.
- If the properties are informed to the screen reader user, this requirement of the success criteria is considered as passed and the test engineer have to check other requirements of the success criteria described in the other sections.
- If the properties of the elements are not exposed to the screen reader user this requirement of the success criteria is considered as failed.
Validation for Value of elements
Certain elements on the page can change their values by the user. Remember the label or accessible name and the value are two different concepts. Taking an example of The volume controls of the computer, The accessible name of the control will be volume but the value can be anywhere between 0% to 100%. The change in this value has to be communicated to the screen reader users.
- Open the page on the browser when the screen reader is switched on.
- Navigate through-out the page and check if any elements on the page supports these controls.
- If such element exist, try changing the values and verify if the changed values are communicated to the screen reader users.
- If such values are properly announced to the screen reader users then this requirement of success criteria is considered as passed and the test engineer have to check other requirement of the success criteria described in the previous sections.
- If the changed values are not communicated to the screen reader users, this requirement of the success criteria is considered as failed.
Note: To say the entire success criteria is passed, all the criteria must be passed or few must be marked as passed while the rest are not applicable. In other words, if any one of these sections are failed, the success criteria is considered as failed.
WCAG Success criteria
4.1.2 Name, Role, Value (Level A)