Forem: Laura Wissiak, CPACC

[Boost]

Laura Wissiak, CPACC — Tue, 14 Apr 2026 08:42:42 +0000

Solving a sign language interpreter shortage

Jordan Harrison for Google Developer Group

Apr 10

I tried to make DevFest Ireland accessible - and ended up building a SaaS

#showdev #a11y #saas #startup

Comments 4

5 min read

Trusted Tester Study Group 5: Links, Images, and the Clock is Ticking

Laura Wissiak, CPACC — Tue, 14 Apr 2026 08:24:37 +0000

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!

Materials

Google Developer Group Vienna
Study Group GitHub
Study Group recordings playlist on YouTube
Session slides and transcripts on Google Drive
Short summaries on A11y News
GDG Vienna Accessibility Webinar Series
WebAIM Million Report
DHS Section 508 Coordinators: Quick Reference with Test Conditions

Things I learned from hosting a certification study group

Laura Wissiak, CPACC — Mon, 13 Apr 2026 15:46:00 +0000

Fun with time zones and daylight savings

If you also want to host an online study group, remember that the internet is for everyone. I started in February and by now, our usual time has shifted by 1 hour for everyone who's region doesn't do daylight savings. Adress it in the first session so people will know in advance!

People love interactive examples

At first I thought they would be more effort for me to add to the slides, copy the link into the chat each time, switch tabs to share the example and then edit the awkward silences from when I waited for the participants to complete them out from the recording. But once you've been talking for 1.5h, you start to appreciate those tiny breaks. And the participants loved them!

GitHub is great, not just for code

Now I collect all links to session recordings, slides, materials, cheat sheets, and written recaps in one repository instead of scattered across event descriptions.

People will drop off

In the first few events, there will always be some dropouts. But the 20 people who stick around? They’ll stay until the very end. And that loyal core makes it worth continuing, because consistency builds community.
You have to promote your own stuff: People don't know what you are doing unless you tell them about it. Even a quick post copy-pasted on all platforms has an effect on how many people show up.

The pros and cons of CC on YouTube

If you download a video, the Closed Captions option disappears. I didn't realize this for the first 4 sessions until a participant reached out. To fix this, I will reupload all sessions with Open Captions.

It takes so much more effort than you think.

Initially, I set the study group up for every other Friday only because I had calendar conflicts on some Fridays. Now I'm so glad I didn't make it weekly because editing and publishing materials from one session while already preparing for the next is time-consuming.

Forms Accessibility: The 8 Trusted Tester Test IDs You Need to Know

Laura Wissiak, CPACC — Tue, 07 Apr 2026 08:35:55 +0000

A developer’s guide to labels, context changes, error handling, and prevention based on the DHS Section 508 Trusted Tester conformance process.

You thought Keyboard Access and Focus was a big topic? Well, so was our 4th session of the DHS Section 508 Trusted Tester Study Group: Forms cover 8 Test IDs in total. Forms are where users give us their data, and where failures can block entire user journeys.

Your Forms Cheat Sheet

Labels are layered: Visual presence (5.A.), descriptive quality (5.B.), and programmatic association (5.C.)
Context changes require warning: Unexpected behavior disorients users, but warnings make changes acceptable.
Errors need both, a means of identification as well as remediation: Knowing something is wrong is only the first step, users need to know how to fix it as well.
Important submissions demand safeguards: Legal, financial, and data-modifying forms require either review mechanisms before submitting, an option to reverse submission or the page should flag errors and allow the user to correct them before final submission.

A cheat sheet for all Trusted Tester testing and evaluation steps is also in the Resources Drive folder.

The Three Pillars of Form Labels

Test IDs 5.A. - C cover form labels, splitting them into 3 smaller questions: Is the label visible? Does it make sense? Is it programmatically correct?

Note that the Trusted Tester process builds on WCAG 2.0. Due to this, I’ve included comparisons between WCAG 2.0 and 2.2 in each study group session. For all WCAG success criteria cited in relation to the topic 5 forms test IDs, neither the content nor level has changed between 2.0 and 2.2 and therefore I am only linking to 2.2 as well.

5.A.: Labels Provided (WCAG 3.3.2 Labels or Instructions)

Every form field must have a visual label or instruction that remains visible, even when the field receives focus. So no, placeholder text that disappears on focus does not count as a label. But table headers can count!

Note that this test only checks presence, not accuracy. For 5.A. we are only looking, if a label is there, not if it makes sense.

Placeholder text is not a label. If it disappears on focus, it fails 5A.

5.B.: Descriptive Labels (WCAG 2.4.6 Headings and Labels)

Labels must sufficiently describe the purpose and data requirements of each field. Users should know what data format is expected (phone number format, date format, etc.), and required field indicators must be clear. For both, clarification in text is also acceptable. Button labels must describe the function clearly, and error messages alone cannot substitute for upfront label clarity.

5.C.: Programmatic Labels (WCAG 1.3.1 Info and Relationships, WCAG 4.1.2 Name, Role, Value)
This is where we go beyond what’s visible on the screen: Form elements must have programmatic associations that assistive technologies can read. To determine this, the Trusted Tester process uses the ANDI tool: ANDI output must include all relevant instructions and cues. For general web accessibility testing purposes, you can also use the developer tools of your browser to inspect the label. Accessible names don’t need to match visual labels word for word, but they must still be adequate.

Radio buttons and checkboxes must be programmatically associated with the questions they are supposed to answer. In contrary to that, dropdown options themselves are not part of the form field description.

In the study group, our fail example was a form with multiple phone number input boxes (spaced to mimic the US phone number format of 3-3-4 digits) all reading as “phone” without distinguishing the segments for area code (3 digits), prefix (3 digits) and line number (4 digits).

Managing Context Changes

The next 2 Test IDs deal with what happens when users interact with form elements, and making sure they’re never surprised by unexpected behavior.

5.D.: Forms on Input (WCAG 3.2.2 On Input)

Changing form field values should not trigger unexpected changes of context.

To the diligent study group regular, this may sound familiar! We had a very similar test in the last session: Keyboard Access and Focus in , well, the focus part. The concept is the same, only the test ID name is different and limited to form elements instead of every keyboard accessible element on the page.

Users must be warned before a form automatically submits, new windows open, focus shifts, or the page redirects. “Unexpected” is the key word here: expected changes with warnings are acceptable.

The iconic fail example from the study group was a radio button selection for our birth year that immediately redirects to a Wikipedia page, without warning.

5.E.: Forms Change Notification (again WCAG 4.1.2 Name, Role, Value)

Users must be notified of any form-related changes on the same page.

Notification methods that pass:

ARIA live regions in which the error messages pop up.
Keyboard-accessible dialog boxes.
Focus movement to changed content with sufficient description.
Interface components that provide sufficient description of the change.

Our fail example: A ticket availability message appearing without live regions, focus movement, or any dialog notification. How are we supposed to know the show’s already sold out then?

Error Handling Excellence

The last three test IDs ensure errors are not only detected but also effectively communicated and corrected.

5.F.: Error Identification (WCAG 3.3.1 Error Identification)

Automatically detected errors must be identified and described in text, not just color or icons. The specific field in error must be identified, not just a vague “invalid input”, be precise which field is causing trouble.

Common failure: The error message consisting of only a red “X” icon or red outline without accompanying text description. Can we, as web design and development professionals, please move on already from sensory-dependent error handling? It has been plaguing UI accessibility for so long.

Note that this test does not require correction suggestions (that’s a spoiler for 5.G.)

5.G.: Error Suggestion (WCAG 3.3.3 Error Suggestion)

We have the error. Now what? When errors are detected, guidance must be provided on how to correct them. Provide suggestions on how to remedy the error, unless they would jeopardize security or purpose.

How could it jeopardize security or purpose? Great question! While most errors are outside our happy path, in certain scenarios, they can be part of the game. For example, if you are playing a guessing game

Online tests and exams are also exceptions because automated error suggestions here would go against the whole concept of testing your knowledge!

Pass Examples: Password requirements that are shown upfront, or specifying acceptable ranges for input (e.g. “input a number between 1 to 10” for customer satisfaction surveys).

Fail Example: A form asked us to input our work experience and simply answered with “Error: 5 is not acceptable” without specifying what unit or format is expected.

5.H.: Error Prevention (WCAG 3.3.4 Error Prevention)

Important transactions (we’re talking about legal, financial, and data-modifying context in particular) must allow review, confirmation, or reversal.

Three acceptable approaches are:

Submissions are reversible.
Data is checked for errors with an opportunity to correct.
Mechanism available for reviewing and confirming before finalizing.

Resources

Study Group Recordings
Slides and Transcripts
GitHub repository
Join the next study group session on GDG Vienna

Keyboard Access and Focus: DHS Trusted Tester Study Group Session 3

Laura Wissiak, CPACC — Fri, 20 Mar 2026 16:46:24 +0000

In the digital landscape, we often design for the mouse. We obsess over hover states, smooth cursor transitions, and the “joy of use” for pointer users. Yet, for users relying on keyboards, screen readers, or alternative input devices, the mouse stays invisible.

Session 3 of our Trusted Tester study group tapped into Topic 4: Keyboard Access and Focus. As you already know, the Trusted Tester Process is based on WCAG 2.0, but lucky us, the relevant success criteria on this topic stay the same in WCAG 2.2.

4.A Keyboard Access: The Foundation

The rule is simple but non-negotiable: All functionality must be operable through a keyboard interface.

This isn’t just about links and buttons, it covers dropdown menus, form fields, and even tooltips containing essential information. For example, during the session, we tested a shipping information form. While most fields were accessible, the “City” and “Area Code” input fields were completely unreachable via the Tab key. Even though they were visible on the screen, the lack of keyboard access meant the form was unusable for keyboard users.

If a user can’t click it with a mouse, they must be able to reach it with Tab, Enter, Space, or arrow keys. Setting custom key combinations for specific interactions is also acceptable, as long as you tell users what the combination is and it doesn’t include timing requirements because… that’s a spoiler for the next one:

4.B Keystroke Timing: No Race Conditions

Users should never have to race against the clock to activate a feature. This is not the great ticket master war, it’s WCAG 2.1.1 which explicitly states that functionality must not require specific timings for individual keystrokes.

In the session, our example was a survey tool where the only way to drag and drop a question type via keyboard was to hold Ctrl + Right Arrow for three full seconds. While the feature was technically keyboard accessible, the timing requirement excludes users with motor impairments or slower reaction times.

If a function requires a long-press or a timed sequence, there must be an alternative method that doesn’t rely on timing e.g. a simple Ctrl + C / Ctrl + V shortcut (which you also tell users about!).

4.C Keyboard Traps: Escaping the Loop

A keyboard trap occurs when a user moves focus into a component (like a modal dialog or a custom menu) and cannot move focus out using standard navigation keys (Tab, Shift+Tab, Escape).

In our passing example, we tested a file upload dialog. The focus cycled logically through the inputs, and pressing Esc or the “X” button returned the user to the main page. In this case, the loop within the dialog is intended behavior, not a trap.

However, in our failing example, a similar dialog box had an “X” button that was visually present but not focusable. The focus looped endlessly between two links inside the dialog. The user was stuck. Without a documented custom shortcut to escape, this was a hard fail.

Rule of Thumb is: If you can’t get out of a component with Tab or Escape, you likely have a trap on your fingers.

4.D Focus Visibility: Seeing Where You Are

For mouse users, hovering reveals the target. For keyboard users, the focus indicator is their only map.

WCAG 2.4.7 requires a visible mode of operation where the keyboard focus indicator is visible. We saw a login page where the focus indicator was a subtle, light-gray dotted line that blended perfectly into the background. Technically, it existed, but it was invisible to anyone with low vision or poor eyesight.

Another example was a test page where links had tooltips on hover, but no focus when tabbed to. A tooltip is not a focus indicator. If you can’t see where the focus is, you can’t navigate.

Tooltips are not Focus Indicators

Design Note: I know custom focus states are tempting, but don’t remove the default browser outline unless you replace it with something highly visible and high-contrast.

4.E Focus Change of Context: Don’t Surprise Me

When a user tabs to an element, nothing should happen automatically. No new windows should open, no pages should redirect, and no content should change unless the user explicitly activates the element (e.g., presses Enter).

We tested a “Peanuts” link that, upon receiving focus, immediately opened a new window and redirected the user. This is a Change of Context triggered solely by focus. It disorients users, especially those using screen readers who might be exploring a page and suddenly find themselves in a completely different context.

Similarly, a registration form that auto-submitted and showed a “Success” dialog just because the user tabbed to the submit button (without even pressing Enter) was a failure. Repeat after me: Focus is not activation.

4.F Focus Order: The Logical Flow

Finally, the sequence in which focus moves must preserve the meaning and operability of the page. In a well-implemented form, the tab order follows the visual flow: Name -> Address -> City -> State.

And then you have things like our failing example: A newsletter subscription page had a chaotic tab order that jumped from the “Name” field to the “Business Digest” newsletter, then back to “Street Name,” then back to another newsletter choice (probably also why subscribing to A11y News was not an option here).

This remixed order destroys the logical narrative of the form. While the user could eventually fill it out, the jumping focus makes it unnecessarily harder to. Alas, the Dark Souls of Accessibility strikes again!

Note: The focus order doesn’t have to be strictly top-to-bottom, but it needs to be logical for the target demographic. It must make sense for the content’s structure and the language setting, e.g., right-to-left could be appropriate for Arabic, Hebrew, or traditional-style Japanese formatting. This is a cultural question to consider in the design process.

Resources

Stop the Noise: Auto PLaying Audio Control and ARIA Live Region Testing

Laura Wissiak, CPACC — Tue, 10 Mar 2026 07:48:26 +0000

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.

DHS Trusted Tester Certification: What is Section 508? Functional Performance Criteria, Web Standards & Testing Tools

Laura Wissiak, CPACC — Mon, 02 Mar 2026 17:59:13 +0000

Together with the Google Developer Group Vienna, I am hosting a study group for the Trusted Tester certification. You can watch the previous session recordings on YouTube and access the presentation and transcript.

The next session will be on Friday March 6, 4 PM CET, on GDG Vienna. We will cover how to test auto-playing and auto-updating content, as well as flashing content.

What is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. that requires any ICT developed, procured, maintained, or used by the U.S. Federal government to be accessible to people with disabilities. It guarantees that federal employees and the public can use government‑provided software, websites, hardware, and documents.

The DHS Trusted Tester program is a manual‑testing methodology created by the Department of Homeland Security.

It follows the ICT Testing Baseline and produces repeatable, reliable conformance results, and gives you a concrete, audit‑ready way to prove that a product meets Section 508 – far more trustworthy than relying only on automated tools.

The study group is free and 100% online. We meet every other Friday for ~6 months to go over the testing topics and examples from the Trusted Tester course. To recieve a certification, you must enroll in and complete the DHS Trusted Tester course.

Session 1 covered:

Functional Performance Criteria

Vision: No‑vision (screen reader), limited vision (magnification), no colour perception (color contrast)
Hearing: No‑hearing (captions, transcripts), limited hearing (visual alerts)
Speech: No‑speech
Manipulation Limited: fine motor control (keyboard‑only navigation)
Reach & Strength: Ability to press large targets, use assistive switches
Language / Cognitive: Simple language, clear instructions, consistent navigation

These map directly to the POUR principles (Perceivable, Operable, Understandable, Robust) that you’ll see throughout the course.

Electronic content beyond the web

One of the most eye‑opening moments for many participants was the realization that “electronic content” is a catch‑all term that includes PDFs, e‑books, emergency alerts, automated emails, survey forms, and even kiosk interfaces. The same accessibility principles that govern HTML also apply to these formats, albeit with different testing techniques.

For PDFs, for instance, you still need proper tagging, logical reading order, and descriptive alt text for images.

For e‑books, the focus shifts to structural markup that allows a screen reader to navigate chapters, tables of contents, and footnotes. The overarching message was clear: once you master the core concepts, you can transfer them to virtually any digital artifact.

Your Homework, should you choose to accept it

If you plan on taking the certification at the end of the study group, here is your homework until the next session: Complete the first 3 modules we covered in the DHS CX Directive.

What is Section 508? – theory & history
Standards for Web – POUR, WCAG, Functional Performance Criteria
Testing Tools – ANDI, autoplay settings, and contrast checker

Explore the ANDI bookmarklet on a few of your own sites, and familiarize yourself with the contrast‑checker.
Also: Check how to enable your browser’s autoplay ahead of the next session because the topic will be “auto‑playing & Auto‑updating content”.

Should you encounter any broken links in the official course, let me know. I’ve saved copies of the older resources.

Materials

The Hidden Costs of Accessibility Audits: A Project Manager’s Guide

Laura Wissiak, CPACC — Thu, 11 Dec 2025 12:39:00 +0000

Pair accessibility audits with your standard QA process. It reduces the chance of late‑phase surprises that derail both your budget and your timeline.

Why Accessibility Audits Matter for Project Managers

As a project manager, you already juggle deadlines, budgets, and stakeholder expectations. Accessibility might feel like a “nice‑to‑have,” but neglecting it early on creates hidden costs that can triple in later project phases.

Boehm’s curve — which shows us that fixing problems later costs exponentially more — is a useful starting point. But there’s also what I call the Unknown Factor : Nobody does it wrong on purpose. Teams miss issues because they don’t know they exist, or they underestimate their impact. That’s why accessibility needs to be scoped and measured deliberately, not as an afterthought.

Step 1: Define What You’re Auditing

Accessibility is measured against WCAG (Web Content Accessibility Guidelines). Most legal requirements still cite WCAG 2.1 , but you’ll want to check against WCAG 2.2 to future‑proof your project.

Practical approach for PMs:

Keep the WCAG 2.2 open in one tab.
Create a document where you list which criteria apply, which might apply, and which don’t (with a short note why).
This gives you a scope baseline and a good defense if questioned later.

Step 2: Distinguish Between Objective and Subjective Criteria

Some criteria are easy to measure:

Alt text : Does every image have an alt-attribute? (SC 1.1.1)
Captions : Are they present for video? (SC 1.2.2)
Contrast : Does text meet the ratio? (Use tools like WebAIM Contrast Checker.)

Others require judgment calls:

Plain language : WCAG suggests content should be understandable. The EU’s Accessibility Act even requires B1‑level language for banking services. But jargon often makes this subjective.

As a PM, plan extra time for criteria that require human review , not just automated testing.

Step 3: Anticipate Common Failures

According to the WebAIM Million report (analysis of 1M websites), the most frequent failures are:

Low contrast text (79.1%)
Missing alt text (55.5%)
Missing form input labels (48.2%)
Empty links (45.4%)
Empty buttons (29.6%)
Missing document language (15.8%)

Contrast is tricky because tools can’t always test backgrounds like gradients or images. But the others? They’re pure tech debt : Things that should have been done right the first time.

Step 4: Address the Tech Debt

For PMs, here’s the takeaway:

Missing labels, empty links/buttons, and no document language aren’t “nice extras.” They’re baseline functionality that slipped through.
Fixing them later eats into timelines and budgets.
Make them part of the Definition of Done to avoid rework.

Step 5: Plan for Content Effort Too

Accessibility isn’t just development. Writing good alt text is nuanced. You need to decide:

Is the image decorative or informative?
What’s the context?
What description actually helps the user?

Use resources like the Alt Text Decision Tree or Nielsen Norman Group’s guidelines. As a PM, budget for content work — not just code fixes.

Summary: Don’t Freak Out, But Don’t Delay

Accessibility audits may feel overwhelming, but with the right process, they’re manageable. For project managers, the key is:

Scope early : Define which WCAG criteria apply.
Budget realistically : Factor in subjective criteria that need human review.
Prevent tech debt : Make accessibility part of your Definition of Done.
Expect ROI : Addressing accessibility early saves money, prevents fines, and improves user experience.

Accessibility isn’t just compliance. It’s risk management, cost control, and user satisfaction — all things good project managers are measured by.

If you’d like to stay ahead on accessibility without getting lost in technical jargon, check out A11y News — my newsletter breaking down complex accessibility and WCAG updates into actionable insights.

Tools & Resources for Accessibility Audits

Pro Tip: Pair accessibility audits with your standard QA process. It reduces the chance of late‑phase surprises that derail both your budget and your timeline. Here are some trusted tools and references that can guide your accessibility audits. From automated checkers to practical writing guides, these resources will help you move from theory to actionable improvements.

WCAG 2.2 Guidelines The official benchmark for accessibility compliance, with detailed success criteria.
WCAG‑EM Report Tool Helps you document which WCAG criteria apply to your product and track compliance.
WebAIM Contrast Checker A straightforward tool to test color contrast for accessibility compliance.
WebAIM Million Report Annual study analyzing accessibility barriers across the top 1,000,000 homepages.
WAVE Accessibility Evaluation Tool Automated checker that detects many common WCAG compliance failures.
W3C Alt Text Decision Tree A practical guide for deciding when and how to write image descriptions.
Nielsen Norman Group on Writing Effective Alt Text Best practices for writing descriptive, useful alternative text.

DevFest Vienna 2025: How Blind People Navigate the World, On and Offline

Laura Wissiak, CPACC — Wed, 03 Dec 2025 07:40:23 +0000

Watch this on YouTube: DevFest Vienna 2025

Online Navigation

Online navigation works quite similarly to offline navigation, only the tools differ greatly. For online navigation, we mainly have zoom, screen magnifiers, and screen readers (or SR for short). Zoom and screen magnifiers are pretty easy to wrap your head around, either because you tested it on purpose or accidentally hit Ctrl while trying to scroll and got a jump scare by gigantic UI elements: They make things big. Checks out.

But screen readers are more intimidating at first. You boot them up and suddenly everything starts talking! Most of us are not particularly fond of their device issuing unexpected noises because it’s usually a bad thing.

While text-to-speech (or TTS for short) is the intended functionality of text-to-speech screen readers (shocking, I know), it is overwhelming at first. Monotone, technical-sounding voices are simply not a joy to listen to, especially when you have to concentrate on understanding what exactly these voices are describing to you. On another note: Braille displays peacefully coexist with TTS screen readers and are a staple for web access!

It’s time to talk about the oh-so-dreaded screen reader testing!

Screen Reader Output

So screen readers read what’s on the screen? Wrong! They read what you wrote into your code! While a software tester who uses a mouse and screen might not notice that your menu exit button is actually a styled div, the SR will. And it will not work as well.

This is where the accessibility tree comes into play. The accessibility tree is how SR and other assistive tech users navigate through a website, climbing along heading levels and structures to find the desired information. The accessibility tree is sprouted by the browser based on the DOM (shorthand for Document Object Model) tree and accessed by platform-specific Accessibility APIs.

The DOM tree contains objects representing all the markup’s elements, attributes, and text nodes. This is precisely why following the h1, h2, h3 … heading structure is important. When you skip heading levels, you cut off the branches that assistive tech needs for a sound climbing route.

But not all screen readers are the same. Let’s briefly go over the differences in screen reader output: Below are 2 popular screen readers reading the same thing in the same browser and both outputting something different:

NVDA vs JAWS

The following table is from our workshop at We Are Developers 2024. The code for it is available under SR Table Navigation on Julia’s profile: CodePen.io/YuriDevAT. You can download NVDA screen reader and follow along.

Testing setup

NVDA 2024.1.0.31547 in Chrome v126.0.6478.127 on Windows 11 Enterprise
JAWS 2022.2204.20.400 in Chrome v126.0.6478.127 on Windows 11 Enterprise

NVDA will say:

“Choose your Starter Pokémon Table with 4 rows and 3 columns Choose your Starter Pokémon caption”

and JAWS will say:

“Table with 4 rows and 3 columns. Choose your Starter Pokémon. Colum 1, row 1, person.”

Same table, same code, same browser, yet 2 different outputs. That doesn’t mean that one is better than the other; they both get the job done. But be aware that there are some nuances between them.

Then what Screen Reader Setup is best for Testing?

Classic UX answer: it depends. Firstly, on your target demographic, but more tangibly, on the operating systems you are developing for. Every year, WebAIM releases a survey for screen reader users where they ask which SR-browser combination they use.

The latest survey was conducted between December 2023 and January 2024. Go check the Screen Reader User Survey #10 Results! While you’re at it, check out the WebAIM Million report as well. The Million report audited 1 million websites to give us a benchmark of progress in web accessibility over the years and the most common WCAG failures. (It’s still low contrast btw.)

Screen Reader Testing Summary:

JAWS and NVDA came out on top with 40.5% and 37.7% respectively. The 3rd place on the podium took VoiceOver with 9.7%. As for browsers, the big 3 are Google Chrome, Microsoft Edge, and Mozilla Firefox.

results for primary desktop or laptop screen reader use from https://webaim.org/projects/screenreadersurvey10/

results for browser usage with primary screen reader from https://webaim.org/projects/screenreadersurvey10/

Offline Navigation

The white cane

She’s an icon, she’s a legend, and she is not only at the moment but a consistently reliable tool for obstacle detection. Reliable because it detects obstacles, floor texture, drop-off points, or stairs going in both directions: up and down. Many startups in the assistive tech space try to replace the white cane, but to be honest, it only took me 2 weeks at Hope Tech Plus to uncover the groundbreaking insight that nobody who uses a white cane actually wants that — surprise, surprise!

But that’s not to say that our global icon for low vision is the solution for everyone. Carrying something around all day puts some strain on your wrists, and bumping into an obstacle can quickly be painful if you have joint problems. For different reasons, people might prefer other techniques, for example, guide dogs.

Guide Dogs

The best of good boys and girls, also known as the four-pawed part of a guide pair. Training takes around 18 months to 2 years in a “puppy boarding school” and includes socialization, basic obedience, and specific keyword training for everyday actions. Labradors, Golden Retrievers, and German Shepherds are the most popular breeds because of their temperament, size, and trainability.

Not every puppy gets to graduate! The most important criterion is the dog’s ability to focus only on their handler and ignore environmental stimuli, such as food on the floor, other people or dogs trying to get its attention, or loud noises. At the same time, they have to stay vigilant about potential threats or obstacles on the way, which requires a lot of concentration. It’s hard work!

According to the International Guide Dog Federation, only around 23.000 dogs are on active duty. Most dogs work up to the age of 10, but this varies depending on the guide pair. The 10th birthday isn’t necessarily the definitive retirement day, but around that time, handlers will start to notice a decline in concentration or less excitement to work from their dog.

Braille

Braille is a code made up of raised dots that can be read with your fingertips. It was invented by Louis Braille (another icon, absolute king behavior) in the early 19th century. It has been in use all around the globe since then, but that doesn’t mean that it’s the same language everywhere. After all, Braille is not a language; it’s a script code. Think of how the Vietnamese language uses the Latin script, yet that doesn’t mean that people who speak Latin-based languages can read Vietnamese.

It is an important tool for literacy. While Text-to-Speech screen readers are awesome, relying exclusively on audio output can lead to limited literacy and a decrease in vocabulary over time. It’s the same concept as why everyone wants their children to read more books: reading benefits one’s literacy. So good on you for reading this! Great job!

For more, check out Braille.ch: it’s a fascinating tactile rabbit hole to go down!

Refreshable Braille Displays

In the Tech world, there are refreshable Braille displays or Braille screen readers. They do exactly the same thing as Text-to-Speech screen readers, but with text output. How many letters they display at once depends on the size.

In April 2024, I hosted a workshop together with Tetragon, who are developing affordable braille products: everything from display to keyboard to printer! The prototype we workshopped with participants — for example, the EcoBraille — requires only one actuator for an entire line of dots, regardless of the length of that line. If it’s a 20-character line: 1 actuator. If it has 80 characters, still only 1 actuator. This means that the display can be disassembled and extended with additional 20-character lines!

And how do Braille displays work?

Speaking of actuators: Refreshable braille displays function by pushing individual pins up into the right position to form a braille letter. Each braille character cell holds 6 pins in a 2 by 3 arrangement. At the bottom of each pin is an actuator that gives the pin the command to jump up or stay put.

How does the device translate to Braille?

Braille Keyboards and displays have braille tables integrated. In addition to 6-dot braille, there’s also 8-dot braille. Looks exactly how it sounds, like 8 pins instead of 6 in a 2 by 4 configuration. The additional 2 pins allow for special characters beyond the standard Latin alphabet. Braille is pretty neat, right?

Self‑Taught, Not Self‑Neglected: Blue Beanie Day Tips for Indie Developers

Laura Wissiak, CPACC — Sun, 30 Nov 2025 10:32:53 +0000

Sunday, November 30th 2025, marks the 18th annual Blue Beanie Day. Okaaaaay, why is this relevant for inclusion?

Blue Beanie Day reminds us to pay attention to web standards in order to create sites that load faster, reach more users, and cost less to maintain. Accessibility is part of these standards.

The web was designed with accessibility in mind.

Exactly 10 years ago, Tumblr user BlueBeanieDay posted:

It’s a thrilling time to create web content and experiences, as more new coders join our ranks, using more new tools and frameworks to create more new kinds of content, experience, and interactivity. But in this environment that moves faster than reason, it’s too easy for our community—and the breathless media that reports on it—to lose sight of vital basics.
Progressive enhancement and accessible, semantic markup aren’t optional extras. They’re the foundation of a web that works for all people, of whatever ability, on whatever devices they choose to access it.

All of the above still stands true today. Web design and development have become popular career paths, with many emerging self-taught talents. Being self-taught myself, I know the pros and cons.

Pro: With no degree or anything to show, you really have to prove your skills through your skills.
Con: You only learn what you choose to learn. Many things can slip in between the grooves of your keyboard like crumbs, so close yet always eluding your fingertips.

You don’t learn what you don’t know, and with a severe lack of web accessibility curriculum standardisation, accessibility is unfortunately most often part of this category.

Even formal education isn’t a guarantee that you will know the basics of accessibility. Luckily, an increasing number of teachers and boot camps make a conscious effort to include web accessibility in their curriculum, but that remains an individual effort.

So let’s take Blue Beanie Day as an occasion to master the basics. I know, I know, plain HTML5 is not as sexy as the latest release cutting-edge tech stack (unless your name is Manuel). But it’s important to understand (and honor) the blueprints today’s web is built on:

The World Wide Web Consortium (W3C), along with other groups and standards bodies, has established technologies for creating and interpreting web-based content. These technologies, which we call “web standards,” are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the Web.
Designing and building with these standards simplifies and lowers the cost of production, while delivering sites that are accessible to more people and more types of Internet devices. Sites developed along these lines will continue to function correctly as traditional desktop browsers evolve, and as new Internet devices come to market.

WaSP - The Web Standards Project

Web Standards are what keep the web usable, independent of browser and device. Not only now but for the next decades to come.

*Digital accessibility is an integral part of web standards. *

The web was built on the idea that anyone, on any device, should be able to read, navigate, and contribute.

One of the biggest players in Web Standards today is the World Wide Web Consortium (W3C). That abbreviation rings a bell, right? Maybe because they have published the Web Content Accessibility Guidelines (WCAG) since 1999. Now we are feverishly anticipating version 3.0, growing from the original 14 guidelines to 85 success criteria grouped into 13 guidelines.

Take the blue beanie as a reminder to start small, but think big.

Today, spend a few minutes checking one of your own pages with an accessibility tester (WAVE, axe dev tools, or Google Lighthouse). Fix the most obvious issues: missing image descriptions, hierarchical heading order, and sufficient colour contrast. Then share what you learned on social media with the hashtag #BlueBeanieDay. By turning a single day into a habit, we keep web standards alive for the next generation of developers and designers.

Blue Beanie Day Resources

Resources for Developers
WaSP Web Standards Project
Web Standards by W3C
Accessibility Fundamentals by W3C
Designing with Web Standards, the book that started it all.
The original Jeffrey Zeldman also has a handy dandy post on How to join Blue Beanie Day.
Blue Beanie Day on Tumblr: #a11y is code for “Love Your Neighbor”

Making a Hackerspace Accessible – Lessons from the “Do It Blind” Meetup

Laura Wissiak, CPACC — Mon, 10 Nov 2025 14:23:13 +0000

Recently, I visited my local hackerspace for the “Do it Blind” meetup. Do it Blind is the in-house effort to make the hackerspace itself accessible for people with visual impairments.

My friend, who had invited me, was trying out how far he could get in the 3D printing process without any sighted assistance, only using his screen reader. While my holographic Eevee coin was printing, I followed along (minus the screen reader, plus the visuals) while he installed OctoPrint on Windows (which seems worth mentioning because the Linux users in the hackerspace believed it impossible).

I want to say “it worked”, but it would be more accurate to say “he made it work”.

There was a sign-up form with no form labels and a link instead of a button. Sure, with context clues, it’s kinda obvious what 3 consecutive text input fields would want you to enter: A username, a password, and password confirmation.

But the ultimate knock-out: a modal window with 2 options to close it, but neither was present on keyboard navigation. There was no way to get past it without using the mouse.

Regardless of the 2.1.1 keyboard navigation failure, this setup flow was far from accessible. The whole point of this experiment was to find out if the 3D printing process can be done with only a screen reader and a lot of dedication. But not all assistive tech users are power users like that.

Web accessibility best practices focus on assistive tech power users.

Maybe the aforementioned Linux users in attendance were already a clue, but generally speaking, the digital literacy (and 3D printing knowledge) inside a hackerspace is significantly higher than what you find in the average population.

Unlabelled forms and overlay-window softlocks are not uncommon issues - still, in the year of 2025 - and not only screen reader users but assistive tech users all over the world are left with no other option than to make it work. Somehow.

Dark Souls Level User Experience

Again: circling back to Dark Souls. If you don’t know it, all you really need to know about it is that this game is notoriously hard to beat. Which is why I like to call user flows that are “accessible/compliant in theory” Dark Souls UX.

I have compared using assistive tech to Dark Souls before, and I will say it again: Just because it is possible to do something with assistive tech does not mean that most users will have the nerve to complete it. Yet most accessibility evaluations only look at what’s possible for users with substantial digital skills. Just because your accessibility auditor, another power user who knows the differences between NVDA and JAWS in their sleep, can navigate the page just fine, does not mean all other screen reader users will.

Yes, you can get through it. You can make it work.

But at what cost?

Good Experience or Just… Experience?

"For the love of users, stop calling it a good experience if not everyone gets to have it." - Julia Undeutsch

Assistive tech users just don’t receive the same amount of love when it comes to user flow design.

But why aren’t hoverstates designed to delight keyboard navigation users?
Why isn’t microcopy written to seamlessly guide screen reader users through the flow?
Why don’t brand guidelines include instructions on how to write descriptive alt text in line with the tone of voice?

Accessibility is mostly regarded through the technical lens, not the human one. This makes it all too easy to forget that behind all those standards, regulations, and requirements is nothing but a person trying to make it work with their setup.

No A11y No UX

Laura Wissiak, CPACC — Wed, 08 Oct 2025 07:58:42 +0000

This one is inspired by Julia's "No Accessibility No UX".

The first thing I learned about usability issue prioritization was that if it prevents the user from using the product in the intended functionality, it needs to be addressed asap.

I started specializing in accessibility before the topic blew up with the European Accessibility Act deadline announcement, so my motivation originated more from a point of “I’ve worked several customer service jobs before, and have seen the disappointment on customers’ faces when they physically couldn’t partake". Changing the physical accessibility of a 17th century building is hard, but code can be changed anytime.

Now picture my surprised Pikachu face when I started my first UX internship, completed my onboarding UX review assignment, and was told, “Yeah, we will fix that later.” The ticket stayed in the backlog until I left the company.

How can we talk about good usability if users can’t even access it?

I am consciously choosing not to write “some users” here because this would minimize the issue: “some users”, “part of your target demographic”, “16% of the global population”, “1 in 6 people”, “1 in 4 Europeans/Americans”.

Doesn’t matter how big the number grows, it still sounds like a seperate minority compared to what we consider “the user base”.

Nothing describes 100% of your user base.

Julia writes:

And here’s the uncomfortable truth: a shocking amount of UX design today still caters to the designer themself — not to users. The only user in the room is the one holding the Figma file.

And she’s right: We all hold subconscious biases that skew our perception towards what’s familiar to us. We can do our best to grow aware of them, actively seek out different viewpoints, but we can’t change how we were socialized.

This is why diverse teams are highly effective. They expose the product they design to a diverse range of perspectives. Empathy is a highly valued skill for UX professionals, but when it comes to discriminatory experiences, no amount of empathizing can replace lived experience.

User Experience like Fine Dining

Think of it as setting the table at a fancy restaurant when you don’t know what the guests will order. You set up everything, preparing for all options.

Maybe you are keeping up with Tech YouTube news, then you may have heard about the sudden decline in view numbers, specifically on the geekiest content. Views suddenly dropped to 50% while video performance, likes and income stayed exactly the same. The reason: Adblockers stopped reporting views towards videos, meaning that half of the devices accessing the content were using adblockers.

You never know which setup a user is using. You may know their operating system, but are they using zoom to scale the UI up? Do they have an external screen magnifier plugged in? Are they using VoiceOver on their Mac or Dolphin SuperNova? (Sike! Dolfin is only supported in Windows)

To stick with our restaurant metaphor, inclusion is more like being a good host. Creating a welcoming and respectful environment, an ambiance that invites your guests to come in, enjoy the time and “Please, do come again!”

Leaving You with Closing Words from Julia:

Let’s get one thing straight: there is no such thing as user experience if not all users can experience it. The moment you exclude one person, your “user experience” becomes a partial experience — and partial UX isn’t UX.

Get your sh*t together. Design for everyone — not just the mirror version of yourself. And for the love of users, stop calling it a good experience if not everyone gets to have it.

The future of UX is inclusive by default.