November 25, 2015
Accessibility Testing Techniques for Web Controls
Web Accessibility means that different types of impaired users can use the application without difficulty. Web accessibility can adapt to various impairments that create barriers for using the application including blindness, auditory, mobility, speech, cognitive, and color blindness disabilities. It can also help people who have no impairment, such as if a normal user wants to access the application using only the keyboard. Nowadays, the web has become an important resource in many aspects of life like education, banking, healthcare, government and many more, so it is mandatory that the web should provide equal access and equal opportunity to disabled people as well.
We have a couple of years of experience in web Accessibility testing. We have tested the accessibility of webpages based on both ‘WCAG 2.0 Guideline’ and ‘Section-508 Standards – United State Access Board’. These guidelines tell the user about ‘What to test for Accessibility point of view’ but we will begin with hot to test the accessibility of a webpage. During our work on Accessibility testing, we found various Accessibility Testing techniques for web control; therefore, we thought of writing this blog to talk about these techniques.
Commonly-Used Web Controls
A. Data Table
A table is a data table when row headers, column headers or both are present. However, a layout table does not have logical headers that can be mapped to information within the table cells.
Screen Readers treat layout tables and data tables very differently; with layout tables, they simply read the content of the table based on the source code order while with data tables, they will identify presence of the table, including the number of columns and rows, provide table navigation functionality, and read the row and column header.
So how does a screen reader know if a table is a data table or a layout table?
The screen reader performs some analysis of the table markup and structure to understand what kind of table is present. An example of this is the data table markup will include <caption>, <th>, which are never used in layout tables.
While testing a table from an accessibility standpoint, we will take an example of a table as given below and will discuss points that need to be considered while testing this table.
<table> <caption>Accessibility Testing Status Report</caption> <tbody> <tr> <th>Summary</th> <th>Success Criteria</th> <th>Status</th> </tr> <tr> <td>Table Caption</td> <td>1.3.1</td> <td>PASS</td> <tr> <tr> <td>Images ‘Alt’ text</td> <td>1.1.1</td> <td>PASS</td> <tr> </tbody> </table>
- The table should have a caption
When screen reader users navigate the web page, if they want to identify the table, Table 1.1, they use the screen reader shortcut keys. If the webpage developer used a caption below the table, the screen reader will read the Caption as below
- The table header and data cells should be associated
Now that the user has identified the table as Table 1.1, if they want to access the data in it they must press the down arrow key to read the table. The screen reader reads the table as shown below
So the screen reader reads “row 2 summary column 1 Table Caption” because the table header and the table cell are associated
- The table should be avoided for the purpose of webpage layout
It’s always easy to make a web page layout by using <table></table>. This creates a layout for the webpage; however, when a user uses a screen reader to identify any tables on the webpage, the screen reader may actually read a table that is not there. This creates a lot of confusion for screen reader users, so it’s recommended that designers not use tables for layout purposes. TIP: If the developer finds it difficult to create web page layout (complex web page) without using a table then they should use ‘Role=Presentation’ while creating table. This will allow the screen reader to skip the table.
Forms are the complex part from an accessibility standpoint, so they must be properly handled. The following points illustrate how a form should be accessible.
- The label should be associated with the form field
When screen reader users fill the form, Form 1.1, they use screen reader shortcut keys. The screen reader reads the form field as below:
The label “First Name” is associated with its text field so when a screen reader user brings the cursor in the text field, the screen reader reads both the label and the text field together.
- Instructions should be provided at the top of the form
When screen reader users fill the form, Form 1.1, all necessary instructions should be listed at the top of the form as shown below:
- Form errors should be listed at the top of the form as a list
When any of the required fields are left blank and the form is submitted, errors are generated at the top of the form in the list. In the example below, the heading reads ‘Below fields are required’ and the errors are listed just below it. When errors are encountered, screen reader users search for headings from the top of the page, which will catch the heading shown in red text, and use the down arrow key to understand the errors.
- Grouping between related form fields should be present
When screen reader users fill the form, Form 1.1, all related fields should be associated properly, as shown below. The male and female options are grouped together under the legend “Gender,” so when a screen reader user presses ‘r’ (from the NVDA shortcut key ‘r’ for radio button), it will read the male option first.
C. Tabbable Controls
- Keyboard actions should not be trapped on any web controls
If multiple controls are available on a web page and the user wants to access the controls using the keyboard, then the user should be able to navigate the web page without any interruption. The user should not trapped in any control.
In screenshot 1 above, a keyboard-only user is currently focused on the element “How we do it.” When they press the tab key, it moves to the next element, “who we do it for.” Now when the user presses the tab key, they get trapped in between these two controls and can’t move on from them. Designers should ensure that this doesn’t happen when creating web pages.
- Logical tabbing/reading order should be followed
When a user navigates the page from top to bottom, it should be logical. A logical tabbing/navigation order is shown in this image. The logical tabbing/reading order: Email or Phone, Password, Keep me logged in, Log In, Forgotten your password?
- Link focus
If there is any control that can be operated through a keyboard, it should get proper focus when a user focuses on it. In the image below, when a user focuses their keyboard on the “Leadership and Staff” link, the color of the link changes from blue to red and also gets surrounded with dotted lines. That specifically shows the current keyboard focus.
- Link text and normal text should be properly differentiated
Link text should be properly differentiated from normal text. In the example below, the link text on the left side (blue with underline) is properly differentiated from the normal text on the right side (simple text in black). This helps help users to identify the links available on the page.
- Links opening in a new window/external web page should be labeled
Links that open in a new window should be easily identifiable, because screen reader users may be confused when a link opens in a new window. This “Opens in a new window” (programmatically hidden) text is read by the screen reader, which will allow the user to understand what will happen if they click the link
- Link text should be descriptive enough to avoid ambiguity
Most screen readers provide a way to navigate a web page by the links available without having to navigate the entire web page. This requires the link text to be descriptive enough to understand without context. TIP: “Click Here” and “Read More” link texts should be avoided because they are not meaningful.
In the image above, the link text should be “Click to read more about Moving From Concept to vision” and it should be programmatically hidden. Having it read this will help screen reader users to understand the purpose of the link.
- Images should have “Alt” text attribute
Most of the assistive technologies like screen readers read the “Alt” text of the images that helps screen reader users to understand the images. In the image below, the “Awards and Achievements” image has the “Alt” text “award_achievements,” which is not helpful. TIP: Alt attributes should be crisp, concise, and meaningful, and should be descriptive of the image.
- Complex images should have text description
If an image is a complex image (e.g. graph, chart, maps, etc.), a text description should be provided. In the given image of peacock, if a designer only provides the Alt attribute text then an assistive technology user will not understand the features of the peacock like color, feather of the head being short and curled, white strip above the eyes, etc. So in complex images text description is necessary.
F Deprecated HTML Tags
- Deprecated HTML tags must not be used
HTML tags that have been deprecated should be avoided in web development. They are not supported by latest version of assistive technologies like screen readers
Below is a list of the most commonly used deprecated tags
|Deprecated Tags||Description||Replaced Tags|
|<acronym>||Defines and acronym||Use <abbr> instead|
|<applet>||Defines and embedded applet||Use <embed> or <object> instead|
|<basefront>||Specifies a default color, size, and font for all text in a document||Use CSS instead|
|<big>||Defines big text||Use CSS instead|
|<center>||Defines centered text||Use CSS instead|
|<dir>||Defines a directory list||Use <ul> instead|
|<font>||Defines font, color, and size of text||Use CSS instead|
|<b>||Define bold text||Use <strong> instead|
|<i>||Defines italics text||Use CSS instead|
G. Sensory Characteristics
Any type of information or instruction should not be conveyed using only shape, size, location, or sound. It should be properly communicated with more than one sense of instruction.
- Instructions should not be based on shape/size/location
At some places, instructions are given in the form of shapes/size/location; in the following example, the next icon is shown, but a user will not understand that they need to click on it.
To resolve the problem given above, there should be a “Next” label on the button.
This is not an exhaustive list of form elements to be tested for accessibility; instead, it is essentially a list of the most common ones that may appear. We have tried to capture our experience, best practices, and tips that can help even a beginner to start with accessibility testing.