Tools to follow along:
Study Group Session 2
Last week, we looked at and listened to the symphony of dynamic webpage content. If Session 1 was the quiet theory of Section 508, Session 2 was the loud, blinking, scrolling reality of the web. We tackled the trio of auto-playing audio, moving/blinking content, and auto-updating information, along with a critical detour into flashing content and seizure safety.
The overarching theme of the session was the Number 3: Whether it’s a button to pause an audio track, a link to stop a scrolling ticker, or a dialog to hide a live update, the Trusted Tester process demands that the mechanism to control these elements be found within the first three interactive elements a user encounters, or within three elements before or after the moving content.
It’s a strict, pragmatic rule designed to ensure that users aren’t forced to hunt for a “stop” button while being bombarded by sensory input.
2.A Audio Control: The Three-Second Threshold
We started with the basics of audio. If audio plays automatically for more than three seconds, a mechanism must exist to pause, stop, or control the volume independently of the system volume. We walked through several examples: a passing case where a “Stop Ad” button sat right at the top of the page, and a failing case where a “Silent” link was buried fifteen elements deep, forcing keyboard users to tab through a maze just to find relief. The lesson? If the mechanism exists but is hard to find, it fails. Accessibility isn’t just about having a feature; it’s about making it reachable.
2.B Blinking, Moving, and Scrolling
Next, we looked at visual motion. Any content that moves, blinks, or scrolls for more than five seconds in parallel with other content requires a pause, stop, or hide mechanism. We debunked a few myths: a loading spinner that prevents interaction is often considered “essential” and thus exempt, but a scrolling news ticker is not. We also saw a clever example where a blinking “Submit” button could be stopped via a keyboard shortcut (Ctrl+S), proving that text instructions can count as a valid mechanism—if they actually work. Unfortunately, we also saw a failing example where the shortcut was documented but broken, reminding us that documentation doesn’t equal functionality.
2.C Auto-Updating Content & 2.D Change Notificaiton: Live Regions and Dialogs
The session then shifted to content that changes on its own, like stock tickers or sports scores. Here, the rules are similar: users need a way to pause or hide the updates. But we also introduced 2.D Change Notification. If content updates automatically, how does a screen reader user know? We explored three valid methods: a keyboard-accessible dialog, moving focus to the new content, or using an aria-live region. Using the ANDI tool, we visualized how live regions highlight in purple, making it easier to spot if dynamic content is properly announced. We saw a passing example where a hockey score update was contained in a live region, and a failing one where a dialog box appeared but couldn’t be triggered by keyboard, rendering it useless for many.
3.A Flashing Content: The Seizure Safety Net
Finally, we touched on the most critical safety issue: flashing content. While the Trusted Tester process marks flashing content as “not tested” (since it requires specialized tools like the Photosensitive Epilepsy Analysis Tool - PEAT), we strongly emphasized that this doesn’t mean it’s safe to ignore. Content that flashes more than three times per second can trigger seizures. We reviewed examples where a “stop animation” button existed but was too far down the page, and where blinking text was indistinguishable from flashing. The takeaway: even if the formal test says “not tested,” the ethical and safety obligation to prevent seizures remains.
Some Extra Notable Things
Knockout Criteria
A recurring point in the session was the knockout nature of these tests. If a mechanism fails any applicable test condition (like color contrast on a “Pause” button, or keyboard accessibility on a dialog), the entire feature fails. It’s a rigorous standard that leaves no room for partial credit.
Homework
Your task this week is to complete the knowledge checks for auto-playing, auto-updating, and flashing content. If you haven’t installed ANDI or the TPGI Color Contrast Checker yet, now is the time! You will need them.
Next Session: Thursday 12 March
Get ready for a deep dive into Keyboard Access and Focus. This is a massive topic, so we’ve moved the next session to Thursday, March 12th at 18:00 GMT+1 (note the day and time change!). We’ll be covering focus order, visible indicators, and keyboard traps. It’s going to be a long one, so bring your coffee, tea, or assorted snacks.
Resources
As always, the slides, transcripts, and a condensed summary are available on the respective GDG Vienna event pages as well. I also created a GitHub repository for it.
Top comments (0)