DEV Community: Laura Wissiak, CPACC

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.

How Blind People Navigate the World, On and Offline, with Screen Readers and White Canes

Laura Wissiak, CPACC — Thu, 25 Sep 2025 15:28:13 +0000

Online Navigation

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

Screen Reader Output

NVDA vs JAWS

This table is from our workshop at We Are Developers 2024. The code for it is available on CodePen. You can download the NVDA screen reader for free and follow along.

NVDA will say

and JAWS will say

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.

Screen Reader Testing Summary:

Source: WebAIM Screen Reader Survey

Offline Navigation

The white cane

Guide Dogs

Braille

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

Refreshable Braille Displays

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?

How does the device translate to Braille?

Accessibility Cheat Sheet 2025: Free Courses, Certification Paths, and Testing Tools

Laura Wissiak, CPACC — Tue, 23 Sep 2025 09:31:19 +0000

Some resources I appreciated along my own a11y way and can recommend not only for developers, nor designers, but for everyone.

Also available as a podcast version

So you wanna be the very best at web accessibility, but don’t know where to start? Print this page out and throw a dart at it because there’s no wrong point to start at. Only varying difficulty settings.

Universal Design

Center of Universal Design
Universal Design for Learning (UDL): The Why, What, and How of Learning. Especially relevant if you are developing courses or instruction materials for teaching, onboarding, or professional development.

WCAG

Duh, this is the first thing you need when talking web accessibility! The Web Content Accessibility Guidelines — or WCAG in short — are divided into 4 Principles (Perceivable, Operable, Understandable, and Robust, together, they assemble the Power Rangers’ team called POUR-Principles) and 86 Success Criteria (definitely not listing all here, go to W3C.org for that).

WCAG, but in a language I can understand
WCAG in plain English
WCAG 2.2 Subway Map by Theme
WCAG Figma Plugin
WCAG 2.2 Figma card deck
Honorable Mention: The WCAG 3.0 Working Draft
And my favorite one: WCAG Pokécards

But the W3C offers us even more than that! Translations of Current W3C standards and drafts in various languages (although not everything in all languages) are also available and ever extending.

Yes, I know this one is not as fun as comparing the WCAG to Pokémon. But it helps to know the baseline laws that rule the digital accessibility world. You never have to know them by heart, as long as you know where to look them up.

Note : Most modern web accessibility laws and directives are based on the WCAG and Universal Design principles, but don’t use them directly as passing criteria.

The tools of the trade! And to be honest, it can also be more fun to learn through trial and error, instead of theory alone.

WAVE Tool by WebAIM: An automatic testing tool that provides WCAG references for each error, alert, and feature it finds. As with every automatic testing tool, none of them is perfect, but getting acquainted with this one in particular is particularly helpful because the WebAIM Million Report uses it. Learning the limitations of automated testing will help you interpret the findings better.
Speaking of WebAIM: The one and only Contrast Checker, and arguably even better: the Link Contrast Checker to compare 3 colors against each other at once!
Wondering what screen readers people use? Consult the latest WebAIM screen reader survey

We love WebAIM in this virtual house because they give out knowledge for free. The WebAIM Introduction to Web Accessibility Course is free. The only thing you have to pay for is if you want to get a certification.

AccessibleEU does a lot of things, just like the incredible hustler it is; one of them is the AccessibleEU Online Training on Accessible Technology Design. It also comes with a Community of Practice, and both are free, no membership, no European passport required, nothing.

The International Association of Accessibility Professionals (IAAP) offers a number of certifications, which are, well, internationally recognized. Notably, the following:

Certified Professional in Accessibility Core Competencies sounds intimidating but is actually only the baseline of accessibility certifications. The CPACC Body of Knowledge is available in English and German.
Web Accessibility Specialist, more self-explanatory, but also way more technical. The Body of Knowledge is available for WAS in English, WAS in German, and WAS in Spanish.
Accessible Document Specialist does exactly that: document accessibility. The ADS Body of Knowledge is only available in English.

If you enjoyed this article, you might also like A11y News, my monthly newsletter covering accessibility, practical insights, curated resources, and real-world takeaways.

Let’s connect on LinkedIn if you’d like to chat about accessibility, UX research, or making tech more equitable.

Understanding Deaf-Blindness

Laura Wissiak, CPACC — Sat, 20 Sep 2025 06:51:47 +0000

When you hear the word deaf-blind, you might think “How do you communicate then?” And if you have ever studied anything related to communication, I’m sure your old professor is haunting you right now with Paul Watzlawick’s “One cannot not communicate” with that uuh spooky echo uuuh.

But it’s still puzzling, right? Blind people usually rely on their hearing, and deaf people use sign language to communicate. So, how are deaf-blind people making it work?

“Deafblindness is an invisible disability because there is no way we can know how a person perceives the world unless we ask.” — Dr Leda Kamenopoulou, Associate Professor at UCL

How can deaf-blind people see and hear?

We have already established that blindness is a spectrum. Okay, let’s rather say vision is a spectrum, and legal blindness is further on the low vision side, but it still leaves a lot of leeway. Low vision can include things like tunnel vision, color blindness, night blindness (or nyctalopia if you feel fancy!), and stair blindness, which is more of a consequence of issues in contrast or depth perception.

Too long didn’t read: A lot of different things can make up blindness, and legal blindness isn’t total blindness.

Now I don’t work with people who are deaf or hard of hearing in particular, so I can’t make a blanket statement about it. But after a certain amount of desk research and by using some Detective-Conan-level deduction skills, I would make an educated guess and say that it’s also kind of like a spectrum. Or should I say, a volume slider? Actually, more like an elaborate surround-sound system where you can configure every detail.

One of my Hope Tech interviewees who happened to be deaf-blind described their hearing loss “_as if the high-pitch of a stereo had been turned off”_

I feel as if I’m starting to repeat myself in these posts, but disability is a spectrum. Not everyone is living in complete silence and complete darkness. Some use hearing aids and or glasses, as Blindish Latina does, some use a white cane and braille, and some use sign language interpreters. Some people might need less assistance, and some might need more.

Causes of deaf-blindness

If you go to Wikipedia (my previous professors are shaking in their tweed jackets right now), you will find a long list of potential causes. It’s also perfectly plausible that your eyesight and hearing independently of each other deteriorate over time.

But one to pick out is Usher Syndrome. If your mind immediately goes to the singer Usher Raymond, that’s okay. This article will wait here while you go jam out to Yeah Yeah. Back? Alright, let’s go!

The main symptoms of Usher Syndrome are deafness or hearing loss and retinitis pigmentosa. RP usually causes night blindness, tunnel vision and messes with your color perception. Again, what exactly this can look like is completely individual, and the same goes for how fast it progresses. The hearing loss is caused by the abnormal development of the sound receptor cells in your inner ear.

💌 Enjoyed this piece?

I write regularly about accessibility, inclusive UX, and the messy intersection of ethics and product design. Subscribe to my Substack for deep dives, assistive tech user insights, and no-bullshit takes on what really makes tech inclusive.

Connect with me on LinkedIn, Instagram or BlueSky

Resources on Deaf Blindness

The Impact of Invisible Stigma on User Interviews: Lessons from UX Research

Laura Wissiak, CPACC — Tue, 16 Sep 2025 12:46:55 +0000

Invisible stigma is a concept many UX researchers may not fully recognize, yet it deeply influences how people with disabilities engage in user research. I recently presented the German version of my talk on invisible stigma at Technica11y, originally from Inclusive Design 24. Revisiting my notes inspired me to share the extended thoughts and jokes that did not make it into the live event. This article explains what invisible stigma is, why it matters, and how it shapes UX research outcomes.

What Is Invisible Stigma?

To understand invisible stigma, we first need to look at stigma itself. The term stigma comes from the Latin stigmat- meaning “mark” or “brand” and originally referred to a physical scar made by a hot iron. Today, stigma refers to a set of negative and often unfair beliefs that society holds about certain groups or conditions.

According to Merriam-Webster, stigma means:

A set of negative and unfair beliefs that a society or group of people have about something
A mark of shame or discredit
An association of disgrace or public disapproval
A visible indicator of disease or condition

Most of these meanings relate to negative judgment or physical visibility, but stigma can also be invisible.

Visible Indicators vs Invisible Stigma

Some disabilities come with visible indicators, which can be helpful in certain situations. For example, people with low vision often use a white cane or wear a yellow arm badge with three dots. These signals are important for safety, especially in traffic, as they communicate to drivers not to assume the person sees them. In orientation mobility training, even small gestures from drivers, like a hand signal to cross the road, can make a big difference.

However, visible indicators can also bring unwanted attention. In social settings like coffee shops or parks, people may approach and offer help unsolicited. While well-intentioned, this can be uncomfortable or intrusive. Many people with disabilities choose to fold up their canes or hide visible markers to avoid such encounters because “not everybody needs to know that I’m blind.”

Invisible stigma is the experience of managing how others perceive you when no physical marker is present. For example, concerns about pickpocketing arise when someone needs to hold both a phone and a white cane in public. This constant awareness and navigation of social perception create a heavy mental load.

Understanding Invisible Stigma

Invisible stigma is more challenging to spot because, like the wrestler John Cena, it is often unseen. You experience it rather than observe it. Discrimination based on invisible stigma is arbitrary and does not require visible markers. For example, in hiring, people are often advised to remove photos, birthdates, and even gender from resumes to avoid bias.

The advantage of invisible stigma is that people can choose if and when to disclose it. However, choosing not to disclose it means accommodating oneself discreetly, which adds to mental fatigue. This is similar to masking among neurodivergent individuals, where natural behaviors are concealed to fit societal expectations.

Invisible Disabilities and Intersectionality

Invisible disabilities include any disabilities not obvious to others, such as certain chronic illnesses, mental health conditions, or neurodivergence. The Hidden Disability Sunflower initiative helps make invisible disabilities more visible, but visibility often depends on context.

For instance, a person using a white cane walking on the street is visibly low vision. However, the same person inside a café with the cane folded in their bag is not immediately recognized as disabled.

Invisible stigma goes beyond disabilities. It includes characteristics socially devalued but not readily apparent, like sexual orientation, gender identity, religious affiliation, or illness. Intersectionality reminds us that a person’s identity consists of multiple overlapping factors, each influencing their experience with stigma.

How Invisible Stigma Affects UX Research

Invisible stigma creates unique challenges for UX researchers. Participants may downplay or compensate for difficulties during interviews. Many disabilities require significant preparation to manage daily life. For example, a blind person planning public transport routes often memorizes stops and connections rather than relying on GPS, which may not be reliable or accessible.

Similarly, some autistic individuals rehearse conversations in advance as a compensation strategy. These behaviors may seem normal to the person but could mask the extra effort required, affecting how researchers interpret their experiences.

Masking is a common defensive behavior where people hide their natural personality or struggles to fit in or avoid negative judgment. This coping mechanism can be subconscious or intentional.

As a researcher, noticing masking in participants raises an ethical question. How far should you probe for honest feedback when participants may feel uncomfortable revealing their full experience? Respecting participants’ boundaries and comfort is essential. It is okay to acknowledge masking without pushing too hard for disclosure. User research is about understanding within limits, not forcing vulnerability.

Research Beyond Disability Focus

Invisible stigma also influences research when disability is not the explicit focus. For example, I noticed one participant downplayed accommodations in a second interview conducted in a different language and setting. The change in context and presence of another person affected their openness.

Approximately 15% of the world’s population lives with some form of disability. Many adapt their environments in subtle ways, like increasing text size instead of wearing prescription glasses. Some participants may not even realize they have a disability, especially with late diagnoses of neurodivergence or conditions like diabetic retinopathy.

Medical conditions such as diabetic retinopathy cause small but impactful vision loss, which the brain often compensates for without conscious awareness. Recognizing these nuances is important for inclusive UX research.

How to Address Invisible Stigma in UX Research

There is no simple solution to invisible stigma in research, but these strategies can help:

Listen to Understand: Avoid seeking confirmation of your assumptions. Instead, focus on truly understanding participant experiences.
Do Your Homework: Research medical and social contexts related to disabilities relevant to your study, using reliable sources.
Prioritize Individual Experience: Treat each participant as an expert on their own lived experience, rather than relying solely on clinical definitions.
Encourage Comfortable Disclosure: Foster a positive and respectful environment that shows genuine interest and enthusiasm without pressure.
Respect Statistics: Expect a significant portion of participants to have disabilities; inclusivity improves with larger, more diverse samples.

Final Thoughts: Invisible Stigma Is a Systemic Challenge

Invisible stigma remains a systemic issue rooted in societal perceptions and biases. Until disability and other stigmatized characteristics are normalized as neutral traits, these challenges will persist.

UX researchers can contribute by being aware of invisible stigma, respecting participant boundaries, and designing inclusive research processes. This awareness improves not only research quality but also the overall inclusivity of design solutions.

If you are a UX researcher, reflecting on invisible stigma is essential to truly understand and design for all users. By recognizing the hidden barriers that participants face, you can create more empathetic and accessible products.

DEV Community: Laura Wissiak, CPACC

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

4.A Keyboard Access: The Foundation

4.B Keystroke Timing: No Race Conditions

4.C Keyboard Traps: Escaping the Loop

4.D Focus Visibility: Seeing Where You Are

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

4.F Focus Order: The Logical Flow

Resources

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

Tools to follow along:

Study Group Session 2

2.A Audio Control: The Three-Second Threshold

2.B Blinking, Moving, and Scrolling

2.C Auto-Updating Content & 2.D Change Notificaiton: Live Regions and Dialogs

3.A Flashing Content: The Seizure Safety Net

Some Extra Notable Things

Knockout Criteria

Homework

Next Session: Thursday 12 March

Resources

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

What is Section 508?

Functional Performance Criteria

Electronic content beyond the web

Your Homework, should you choose to accept it

Materials

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

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

Step 1: Define What You’re Auditing

Step 2: Distinguish Between Objective and Subjective Criteria

Step 3: Anticipate Common Failures

Step 4: Address the Tech Debt

Step 5: Plan for Content Effort Too

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

Tools & Resources for Accessibility Audits

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

Online Navigation

Screen Reader Output

NVDA vs JAWS

Testing setup

NVDA will say:

and JAWS will say:

Then what Screen Reader Setup is best for Testing?

Screen Reader Testing Summary:

Offline Navigation

The white cane

Guide Dogs

Braille

Refreshable Braille Displays

And how do Braille displays work?

How does the device translate to Braille?

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

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

Blue Beanie Day Resources

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

Web accessibility best practices focus on assistive tech power users.

Dark Souls Level User Experience

Good Experience or Just… Experience?

No A11y No UX

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

User Experience like Fine Dining

Leaving You with Closing Words from Julia:

How Blind People Navigate the World, On and Offline, with Screen Readers and White Canes

Online Navigation

Screen Reader Output

NVDA vs JAWS

Then what Screen Reader Setup is best for Testing?

Screen Reader Testing Summary:

Offline Navigation

The white cane

Guide Dogs

Braille

Refreshable Braille Displays

And how do Braille displays work?

How does the device translate to Braille?

Accessibility Cheat Sheet 2025: Free Courses, Certification Paths, and Testing Tools

Some resources I appreciated along my own a11y way and can recommend not only for developers, nor designers, but for everyone.

Universal Design

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