Accessibility Testing Techniques for Web Controls

Overview

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>

accessibilityblog_1

Evaluation Techniques:

  1. 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
    accessibilityblog_2
  2. 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
    accessibilityblog_3
    So the screen reader reads “row 2 summary column 1 Table Caption” because the table header and the table cell are associated
  3. 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.

B. Forms

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.

accessibilityblog_4

Evaluation Techniques:

  1. 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.
    accessibilityblog_5
  2. 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:
    accessibilityblog_
  3. 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.
    accessibilityblog_7
  4. 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.
    accessibilityblog_8

C. Tabbable Controls

Evaluation Techniques

  1. 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.
    accessibilityblog_9accessibilityblog_10
    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.
  2. 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?
    accessibilityblog_11

D. Links

Evaluation Techniques

  1. 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.
    accessibilityblog_12
  2. 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.
    accessibilityblog_13
  3. 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
    accessibilityblog_14
  4. 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.
    accessibilityblog_15
    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.

E. Images

Evaluation Techniques

  1. 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.
    accessibilityblog_16
  2. 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.
    accessibilityblog_17

F Deprecated HTML Tags

Evaluation Techniques

  1. 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

Deprecated tags:

Below is a list of the most commonly used deprecated tags

Deprecated TagsDescriptionReplaced Tags
<acronym>Defines and acronymUse <abbr> instead
<applet>Defines and embedded appletUse <embed> or <object> instead
<basefront>Specifies a default color, size, and font for all text in a documentUse CSS instead
<big>Defines big textUse CSS instead
<center>Defines centered textUse CSS instead
<dir>Defines a directory listUse <ul> instead
<font>Defines font, color, and size of textUse CSS instead
<b>Define bold textUse <strong> instead
<i>Defines italics textUse CSS instead

PIC

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.

Evaluation Technique

  1. 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.
    accessibilityblog_18
    To resolve the problem given above, there should be a “Next” label on the button.

Conclusion

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.

Sayyed Akram Ali

Sayyed Akram Ali

Module Lead QA Engineer

Sayyed Akram Ali is a Module Lead QA Engineer in 3Pillar’s Noida office. He has around 7 years of experience in Software Testing in various domains such as finance, e-commerce, and Learning Management Systems. Sayyed has extensive experience in software testing with quality assurance, as well as great knowledge of Accessibility, WCAG 2.0 Guidelines, Section 508 Standards, VPAT and extensive knowledge of assistive technology and screen readers like NVDA JAWS. He has worked in all phases of the software development life cycle, including requirements analysis, design, development, and integration. Prior to joining 3Pillar, he worked for AonHewitt India.

Tapan Garg

Tapan Garg

Quality Assurance Engineer

Tapan Garg is a Quality Assurance Engineer in 3Pillar’s Noida office. He has around 4 years of experience in Software Testing. He likes to work with Manual Testing, Accessibility Testing and Automation using Selenium WebDriver. He has extensive knowledge in using various assistive technology, WCAG Standard 2.0, Section 508, as well as in creating VPAT. He is always trying to gain more knowledge of the best practices in software testing and keeps himself updated with the latest technologies.

Leave a Reply

Related Posts

Why You’re Crazy for Not Building Your Products With a... Full disclosure: I am an external product development partner for several highly successful companies - gaining market share and having successful exi...
Real-Time Analytics & Data Visualization, with Dan Gree... 3Pillar Global's Dan Greene, Chris Graham, and Sayantam Dey join us on this episode of The Innovation Engine podcast to talk about the present and fut...
Take 3, Scene 24: The Influence and Evolution of Blockchain,... On this episode of Take 3, we're joined again by Michael Lisse and Derek Tiffany to hear their fresh insights from the Consensus Blockchain Summit in ...
Take 3, Scene 23: The Influence and Evolution of Blockchain Michael Lisse and Derek Tiffany join us in the studio for this episode of Take 3 to talk about the influence and evolution of blockchain in the financ...
The Innovation Engine from TechCrunch Disrupt New York For a very special episode of The Innovation Engine, we're bringing you a number of interviews from the floor of last week's TechCrunch Disrupt New Yo...

SUBSCRIBE TODAY


Sign up today to receive our monthly product development tips newsletter.