Welcome back to the Section 508 Trusted Tester Study Group. In the previous session, we tackled the technicalities of language attributes and page titles. Now we go back to what is essentially web accessibility 101 with Topic 13: Sensory Characteristics followed by the more advanced Topic 14: Data Tables and Layouts.
The recording is also on YouTube.
Back to the basics! Topic 13 covers Use of Color, Sensory Characteristics and Color Contrast.
Color cannot be the only visual means of conveying information, indicating an action, or distinguishing one element from another. In theory, it is oh so simple, but in practice, it is somehow still the most common WCAG failure (WebAIM Million report).
Passing: An error message uses red text and an asterisk (*) or explicit text saying “Required.” A status column uses a red star icon and the text “Overdue.”
Failing: A pie chart uses only different colors to distinguish slices (without patterns or labels on/in close proximity to the slices). Links that are only distinguished by color without an underline or indicator.
Not Applicable: Decorative colors (in branding banners) or for color change of a visited link.
Instructions must not rely solely on sensory characteristics like shape, size, visual location, orientation, or sound. Attention: This test ID references WCAG success criteria 1.3.3 which has changed from 2.0 to 2.2: WCAG 2.2 explicitly added “color” to the above list.
If the instruction says, “Click the green button,” it fails. Easy fix: Add the button label (which we definitely have programmatically defined as we learned in topic 5) and change it to something like: “Click the green ‘Submit’ button”.
If a system alerts you with a bell sound, there must be a visual alternative (like a popup modal dialog or icon).
Failing Example: A timed test that says “Press space bar at the sound of the bell” with no visual countdown or indicator fails. This is not an audiologist appointment.
The Rule: Text and images of text must have a contrast ratio of at least 4.5:1 or 3:1 for large text. My contrast checker of choice is the WebAIM Link Contrast Checker (it allows you to check 3 colors againt each other), but any contrast checker tool will do.
What counts as ‘large text’? Let’s look at the WCAG:
large scale (text)
with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts
Exemptions: Logos, disabled elements, and incidental text in images (e.g., a scoreboard in a stadium photo that isn’t the focus).
Common Fail: Gray text on a light gray background, or any combination of white and yellow. Even a slight dip below 4.5:1 is a failure.
Here we are covering the different types of our tables and their assistive tech output, which should be clear. Heads up about these tables: All success criteria associated with topic 14 are based on WCAG 1.3.1 which didn’t change between 2.0 and 2.2. version.
For tables which contain data points (or any type of data that will vary depending on one or two different factors which are displayed alongside it), we need to ensure that they are programmatically identified as data tables so assistive tech can navigate them.
For the Trusted Tester, testing this is rather simple: Use the ANDI tables module. For ANDI to detect a table, at least one must use <table>, role="table", or role="grid". If the tables module does not show up in the list, it means that no programmatically defined table is present on the page.
If the table has role="presentation", it fails 14.A. (Spoiler alert: If it’s a Layout Table, you will see in 14.C. that 14.A. does not apply and a role="presentation" is exactly what we want.)
Building on 14.A. Data Table, this is the next step for such tables: Every data cell must be programmatically associated with its row and/or column headers, so that the content within the cell is accompanied by the relevant labels.
Testing 14.B.: Navigate the table in ANDI. Hover over a data cell (e.g., “2:00 PM”) and check the output.
Pass: Output reads “State and Market Square, 2:00 PM” (Header + Data).
Fail: Output reads only “2:00 PM” without the route name (Where are we going? On an adventure, apparently.)
Coming back to our spoiler from 14.A.: Tables used purely as an aesthetic choice, meaning as a visual layout only, must make sure that they are not misinterpreted as data tables. Basically, the opposite of 14.A. Data Table.
How to pass 14.C. Layout Tables:
Option 1: ANDI does not detect a table (no
<table>tag). For layout tables, this is perfectly fine!Option 2: The table has
role="presentation". This tells assistive tech to ignore the table structure.
TLDR: No <table> table tag, no <th> table header, or role="presentation". Otherwise assissitive tech will interpret the contents as data.
ANDI Accessibility Testing Tool (bookmarklet)
Read about the previous study group session below, and join the next session through GDG Vienna.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.