Edit: please ignore the mistake in the thumbnail
Links and images are usually an easy win for web accessibility. Then why do they require 2 and 5 test IDs respectively? Because according to the latest WebAIM Million report, the “easy fixes” such as missing alt text, and empty links or buttons remain the top offenders, affecting nearly half of all homepages. So apparently, most people still don’t know how to fix them.
Not among the top 6 greatest hits of web a11y issues, but also included in this session was topic 8: Adjustable Time Limits.
Topic 6: The Purpose of Every Link
6.A Link Purpose
Let's start with test ID 6.A Link Purpose: Can a user determine where a link goes just by reading the link text or its surrounding context? It sounds obvious, but the reality of the web is riddled with "click here" links or empty social media icons that offer no clue to a screen reader user.
The rule is strict: the purpose must be programmatically determinable. This means that when you run the ANDI tool, the output for a link must clearly state its destination or function. If you have a row of social media icons, the accessible name should tell you which platform it goes to. The surrounding text can help, but it cannot be the only source of truth. There is one exception, for the sake of mystery: If a link is part of a game or an intentional surprise, like "Door 1" or "Door 2" in a guessing game, vagueness is acceptable.
But for 99% of the web, ambiguity means failure.
6.B Change Notification
Once you know where a link goes, you need to know what happens when you click it. This brings us to Test ID 6.B, Change Notification. When a user interacts with a link, the page might update, a menu might expand, or a new window might open. The critical question is: does the user know something changed? If a link expands a sub-menu, the link itself must announce that expansion. A visual cue like a downward-pointing arrow isn't enough for someone who can't see it; the accessible name must indicate that selecting the link will reveal more options. If the change happens silently, or if the focus jumps to new content without warning, the user is left disoriented. The fix is often simple: ensure the link's name describes the action, or use ARIA live regions and keyboard-accessible dialogs to announce the change programmatically.
Topic 7: The Many Faces of Images
If links are the roads, images are the scenery, the landmarks, and sometimes, the roadblocks. Topic 7 is a deep dive into the five distinct ways images are handled in the Trusted Tester process, ranging from the purely decorative to the security-critical.
First up is Test ID 7.A, Meaningful Image. This applies to any image that conveys information, emotion, or function. The golden rule here is that every meaningful image must have an equivalent text alternative. This doesn't always mean a literal description of pixels; it means a description of the image's purpose. For a search icon, "Search" is better than "Magnifying glass." For a complex diagram, the alt text might simply point the user to the detailed explanation in the adjacent text. The goal is to ensure that if the image were removed, the user would still understand the content.
7.B Decorative Image
On the flip side, we have Test ID 7.B, Decorative Image. These are the images that exist solely for aesthetics—swirls, spacers, or generic bullet points. They should have an empty accessible name so that assistive technology ignores them completely. The trap here is leaving them with meaningless text like "spacer image" or, worse, forgetting to mark them as decorative when they contain no information. If an image is decorative, it must not be in the tab order, and it must not be the only way to convey important data.
7.C Background Image
Then there are the tricky background images covered in Test ID 7.C. Just because an image is behind the text doesn't mean it's invisible to the user. If a background image contains text or critical information, that information must be available elsewhere on the page. We tested this by using the "Hide Background" feature in ANDI. If hiding the background removes the button text or the agency name, the page fails. The information must persist even when the visual flair is stripped away.
7.D CAPTCHA Image
Security measures bring us to Test ID 7.D, CAPTCHA. In an age of sophisticated bots, CAPTCHAs are everywhere, but they can be insurmountable walls for users with disabilities. The rule is clear: if you use a visual CAPTCHA, you must provide an alternative that doesn't rely on vision, such as an audio challenge. Conversely, if you use an audio CAPTCHA, you need a visual alternative. You cannot force a user to choose between vision and hearing; you must offer both.
7.E Image of Text
Finally, we addressed Test ID 7.E, Image of Text. Generally, text should be text, not an image of text. This allows users to zoom, change colors, and use screen readers effectively. The only exceptions are when the specific visual presentation is essential, such as a logo or a specific font that defines a brand identity. If you use an image of text for a paragraph of content, you must provide controls that allow the user to customize the font, size, color, and background without pixelation. Browser zoom isn't enough; the customization must be built into the webpage itself.
Topic 8: When the Clock Starts Ticking
The final topic of the session, Test ID 8.A, Adjustable Time Limits, addresses a stressor that affects everyone but hits users with disabilities hardest: the ticking clock. Whether it's a timeout on a banking session or a timer on a timed exam, the web must not punish users for needing more time.
The standard requires that for any time limit set by the content, the user must be able to do one of three things: turn the time limit off entirely, adjust it to at least ten times the default duration, or receive a warning with at least twenty seconds to extend the limit with a simple action like pressing the spacebar. This ensures that a user who is navigating slowly with a switch device or who needs extra time to process information isn't abruptly kicked out of a session.
There are, of course, exceptions. Real-time events like auctions, essential activities like timed exams where extending the time would invalidate the test, and time limits longer than twenty hours are exempt. But for the vast majority of web interactions, the clock must be flexible. If a user is logged out after five minutes of inactivity with no warning and no way to extend the session, the site fails. The user must always have the power to control their own pace.
Your Cheat Sheet for Session 5
To wrap up, here is your quick reference guide for the three topics we covered. Remember, these are not just rules; they are the safeguards that ensure your digital content is usable by everyone.
Links: Ensure every link has a clear purpose derived from its text or context. If a link triggers a change, the user must be notified either through the link's name, a dialog, focus movement, or a live region. Ambiguity is only allowed for intentional surprises.
Images: Distinguish between meaningful and decorative images. Meaningful images need equivalent text alternatives; decorative images need empty accessible names and must not be in the tab order. Background images must not hide critical information, and CAPTCHAs must offer both visual and audio alternatives. Images of text are generally forbidden unless they are essential logos or fully customizable by the user.
Adjustable Time Limits: Users must be able to turn off, adjust, or extend time limits. The extension must be simple and allow for at least ten times the default duration or a twenty-second warning period. Exceptions exist for real-time events and essential timed activities, but the default should always be flexibility.
As we move toward our next session on Repetitive Content and Content Structure, take a moment to run the ANDI tool on your own projects. Look for those empty links, missing alt texts, and rigid timers. The WebAIM Million report showed us that these issues are pervasive, but with the knowledge from this session, you have the tools to identify them and advocate for better, more inclusive design.
Happy testing, and see you in the next session!
