Unlocking the Full Potential of Table Accessibility Testing: Advanced Strategies and Techniques

Guidelines for Table Accessibility (as per WCAG)

To ensure that tables are accessible to all users, including those with disabilities, it is important to adhere to the following WCAG (Web Content Accessibility Guidelines) success criteria:

• Success Criterion 1.3.1 Info and Relationships (Level A): Simple tables should be marked up in HTML, while complicated tables should contain column and row headings. Including these heading ensures that the content within the tables can be understood clearly.
• Success Criterion 2.1.1 (Keyboard Accessible): Make sure users can use the keyboard to navigate and interact with the table without the assistance of a mouse or other pointing device.
• Success Criterion 1.3.2 Meaningful Sequence (Level A): The order in which information is presented should prioritize the comprehension of users relying on assistive technology. It is crucial to ensure that the delivery of information follows a logical sequence that closely mirrors how it would be spoken aloud.

Beyond the Basics – Essential Considerations for Accessible Table Design

To implement accessibility in tables, one needs to include the following important criteria in the table design:

Accessibility for Table Structures

• Table captions are brief descriptions of the material that help readers understand the table. Table captions can be read by screen readers, making them accessible to non-sighted users and allowing them to understand the contents of the table. Here’s an example: The initial component after the opening table> tag needs to be the caption> element.
• Contrary to popular misconception, the table summary is NOT the same as the table caption. The caption identifies the purpose of a table while a summary provides orientation or navigation hints in complex tables.
• Table header markup <th> and Table data markup <td> should be used to build a structure that makes it possible for users to comprehend the contents of the table. The “scope” attribute can help determine if the header pertains to a row or a column.
• One needs to associate each data cell to the corresponding header cell for the data to be understood by a person using assistive technology. For a simple table where we have a single header, using header <th> and data <td> markup will suffice. However, if a table is complex and has multiple headers, we assign each header a unique identifier id which is referenced by the associated data cells.

Keyboard Accessibility

• Tables should be accessible to keyboard users using only the control + alt and arrow keys.

Table Color Contrast for Accessibility

• Contrast – Make sure the foreground and background colors of your table have sufficient contrast by using a color contrast checker. The contrast ratio for regular text should be at least 4.5:1, and the contrast ratio for large text should be at least 3:1.
• Colors – It is important to avoid relying solely on color as a signifier of meaning. When information is solely dependent on color, it becomes inaccessible to individuals with low vision and color blindness.
• Design – Tables must adapt to the size of the screen they are presented on since they require a specific amount of space to be readable. Therefore, responsive tables should only require one way of scrolling – vertical scrolling content at a width equivalent to 320 pixels and horizontal scroll content at a height equivalent to 256 pixels.
• Table accessibility on mobiles – There is a rationale behind the usage of 320px/256px. Mobile devices typically have a viewport width of 320 pixels; additionally, the width of the viewport is internally reduced to 320 pixels if you use a desktop browser on a 1280 x 800 screen and zoom in by 400%. To test this, we need to resize the viewport width to 320px by 256px and then the scrolling of the web page needs to happen in only one direction at a time. However, in cases where the table is very large and using a uni-direction scroll bar hinders the presentation of the content, bi-directional scroll bars are permitted.

Common Issues with Table Accessibility

There are some common issues faced in table accessibility testing that are present across most of the tables. These include:

i. Content presented as tabular data is not coded as a data table.

ii. Table headers are missing.

iii. The user is unable to navigate table cells using ‘Ctrl + Alt + arrow keys’.

iv. The screen reader is not reading the table as a table (reads the table as plain text).

v. The table summary is insufficient and inaccurate.

vi. The table title is not rendered as a table caption.

vii. An incorrect table structure is defined for the table.

viii. The screen reader reads the table content incorrectly.

ix. The table was incorrectly used for layout only.

x. Implementing numbered table rows using list markup.

Testing for table accessibility can ensure that all users, regardless of their diverse abilities, can access the information provided. During auditing tables for accessibility, one needs to consider important aspects like the table’s structure, readability, accessibility of alternative text, and keyboard navigability.

The new approach of shift-left – considering accessibility during the design phase – can establish an inclusive environment that is beneficial to everyone, including those with disabilities, the elderly, and individuals using mobile devices. The intent behind using tables is completely justified only if it helps us understand the data and derive correct conclusions.