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