screen readers Archives /Tag

How to Test Mobile Accessibility using TalkBack

It is easy to rely on your eyes when reviewing a mobile site. A quick glance, a few taps, and the page seems fine. But that view is incomplete. Many users experience mobile content through audio, and their path through a page can sound very different from what you expect.

Android’s screen reader, TalkBack, helps bridge that gap by letting you hear how your site behaves without visual cues. If you want to test mobile accessibility with TalkBack in a way that fits real development work, this article shares a practical approach to weaving screen reader testing into your ongoing process so issues surface earlier and mobile interactions stay dependable. It is written for teams who already know the basics of accessibility and WCAG and want more structured, repeatable mobile web accessibility testing.

What TalkBack Is and Why It Matters for Mobile Accessibility Testing

TalkBack is the screen reader that ships with Android devices. When it is enabled, it announces elements on the screen, their roles, and their states. It also replaces direct visual targeting with swipes, taps, and other gestures so people can move through pages without relying on sight.

Testing with this tool shows how your site appears to the Android accessibility layer. You hear whether headings follow a sensible order, whether regions are exposed as landmarks, and whether labels give enough context when they are spoken on their own. You also get a clear sense of how focus moves as people swipe through the page, open menus, and submit forms.

Small problems stand out more when they are spoken. A vague link, a control with no name, or a jumpy focus path can feel minor when you are looking at the page. Through audio, those same issues can turn into confusion and fatigue.

Screen readers on other platforms use different gestures and sometimes expose content in slightly different ways. VoiceOver on iOS and desktop tools such as NVDA or JAWS have their own rules and patterns. That is why this approach treats Android’s screen reader as one important view into accessibility, not a substitute for cross-screen-reader testing.

Web Content Accessibility Guidelines (WCAG) requirements still apply in the same way across devices. On mobile, the impact of focus order, input behavior, and gesture alternatives becomes more obvious because users are often holding the device with one hand, on smaller screens, and in busy environments.

Preparing Your Device for Effective Screen Reader Testing

A stable device setup makes your testing more dependable over time. You do not need anything complex. An Android phone or tablet, the browser your users rely on, and a space where you can hear the speech clearly are enough. Headphones can help if your office or home is noisy.

Before you run your first pass, spend a few minutes in the screen reader’s settings. Adjust the speech rate until you can follow long sessions without strain. Set pitch and voice in a way that feels natural to you, and confirm that language and voice match the primary language of your site. These details matter during longer test sessions.

Different Android versions and manufacturers sometimes change labels or menu layouts. A Samsung phone may not match a Pixel device exactly. You do not need to chase the perfect configuration. What helps most is using one setup consistently so that your results are comparable from sprint to sprint. That consistency also makes your Android screen reader testing easier to repeat.

Enabling and Disabling TalkBack Without Breaking Your Flow

You can turn the screen reader on through the Accessibility section in system settings. For regular work, it is worth taking the extra step to set up a shortcut. Many teams use the volume-key shortcut or the on-screen accessibility button so they can toggle the feature in a couple of seconds.

That quick toggle becomes important during development. You might review a component visually, enable the screen reader, test it again, turn the reader off, adjust the code, and then repeat. If enabling and disabling feels slow or clumsy, it becomes harder to keep this step in your routine.

There is a small learning curve. With the screen reader active, most standard gestures use two fingers. You also need to know how to pause speech and how to suspend the service if it becomes stuck. Practicing these motions for a few minutes pays off. Once they are familiar, switching the screen reader on and off feels like a normal part of testing, not an interruption.

Core TalkBack Gestures You Actually Need for Testing

You do not need every gesture to run useful tests. A small set covers most of what matters for web content. Swiping right moves forward through focusable items. Swiping left moves backward. Double-tapping activates the element that currently has focus. Touching and sliding your finger on the screen lets you explore what sits under your finger.

Begin with simple linear navigation. Start at the top of the page and move through each item in order. Ask yourself whether the reading order matches the visual layout. Listen for buttons, links, and controls that do not make sense when heard out of context, such as “Button” with no name or several “Learn more” links with no extra detail. Pay attention to roles and states, like “checked,” “expanded,” or “menu,” and whether they appear where they should.

This pace will feel slower than visual scanning. That slowness helps you notice gaps in labeling, structure, and focus behavior that you might skip over with your eyes.

Using Menus to Navigate by Structure

After you are comfortable moving element by element, the screen reader’s menus help you explore structure more directly. There are two menus that matter most. One controls general reading options and system actions. The other lets you move by headings, links, landmarks, and controls.

Turn on navigation by headings and walk the hierarchy. You should hear a clear outline of the page as you move. Missing levels, unclear section names, or long stretches with no headings at all are signals that your structure may not be helping nonvisual users.

Next, move by landmarks. This reveals whether your regions, such as header, main, navigation, and footer, are present and used in a way that matches the layout. Finally, scan links and controls in sequence. Duplicate or vague link text stands out when you hear it in a list. Controls with incomplete labeling do as well.

These structural passes do more than make navigation easier for screen reader users. They also reflect how well your content model and component library support accessible use across the site.

A Repeatable First-Pass Screen Reader Workflow

You do not need to run a full audit on every page. A light but steady workflow is easier to sustain and still catches a large share of issues.

When you review a new page or a major change, enable the screen reader and let it read from the top so you can hear how the page begins. Then move through the page in order and note any confusing labels, skipped content, or unexpected jumps. Once you have that baseline, use heading navigation to check hierarchy, and landmark navigation to check regions. Finally, move through links and controls to spot unclear text and missing names.

Along the way, keep track of patterns. Maybe icon buttons from one component set are often missing labels, or error messages on forms rarely announce. These patterns make it easier to fix groups of issues at the design system level instead of one page at a time. This kind of manual accessibility testing becomes more efficient once you know which components tend to fail.

High-Impact Scenarios to Test More Deeply

Some parts of a mobile site deserve more focused time because they carry more weight for users and for the business.

Forms and inputs should always have clear labels, including fields that are required or have special formats. Error messages need to be announced at the right time, and focus should move to a helpful place when validation fails.

Navigation elements such as menus and drawers should announce when they open or close. Focus should shift into them when they appear and return to a sensible point when they are dismissed. Modals and other dynamic content should trap focus while active and hand it back cleanly when they close. Status updates like loading indicators and confirmation messages should be announced without forcing users to hunt for them.

Mobile-specific patterns also matter. Features that rely on swiping, such as carousels or card stacks, should include alternative controls that work with focus and activation gestures. Optional Bluetooth keyboard testing on tablets and phones can provide extra confidence for users who pair a keyboard with their device.

Capturing Findings and Making TalkBack Testing Sustainable

Bringing TalkBack into your workflow is one of those small shifts that pays off quickly. It helps you catch problems earlier, tighten the way your components behave, and build mobile experiences that hold up under real use. A few minutes of listening during each release can surface issues no visual check or automated scan will ever flag.

If you want support building a screen reader testing process that fits the way your team ships work, we can help. At 216digital, we work with teams to fold WCAG 2.1 and practical mobile testing into a development roadmap that respects time, resources, and existing workflows. To explore how our experts can help you maintain a more accessible and dependable mobile experience, schedule a complementary ADA Strategy Briefing today.

Greg McNeil

January 9, 2026

How-to Guides, Testing & Remediation

Accessibility, Accessibility testing, screen readers, TalkBack, user testing, Website Accessibility
YouTube Accessibility: Captions, Audio, and Design
Most teams watch views, watch time, and subscribers like hawks. But there is another number that matters, even if you never see it in analytics. How many people tried to watch your video and left because it was hard to follow?

That question sits at the heart of YouTube accessibility.

YouTube is one of the biggest marketing channels most brands rely on. It powers product explainers, support content, training, webinars, and the videos embedded on your website. When the video is hard to use, that friction follows your brand.

Now, YouTube does a few things well out of the box. The player is responsive, the controls are built in, and keyboard shortcuts are already there. Screen reader support is strong, too. Still, the creator side matters most. Captions, transcripts, audio description, visual design, structure, and testing are all handled by your team. None of this needs to be complicated, and it scales well once it’s part of your workflow.

Start With a Plan for YouTube Accessibility

If accessibility starts after the upload, it usually turns into cleanup work. Cleanup is slower. It costs more. It also leads to compromises, like leaving a confusing visual in place because the edit timeline is already locked.

Planning earlier changes the whole experience. When you build accessibility into the script and storyboard, you can:
- Read on-screen text out loud as you write it.
- Explain charts and visuals in the same moment they appear.
- Avoid abrupt effects that some viewers may not handle.
- Save time by choosing caption and transcript steps up front.
Set a Baseline and Assign Ownership

A simple shift helps. Treat accessibility checkpoints like production milestones. Put them beside script approval, rough cut, and final cut. When a team does this, rework drops fast, especially for repeat formats like weekly updates or a recurring demo series.

It also helps define a baseline for each video type. A solid default for prerecorded content often includes accurate captions, a transcript viewers can access outside the player, and narration that explains important visuals. Then you layer in needs by format. Tutorials often need stronger descriptive narration. Short marketing clips need careful contrast and motion choices. Webinars and livestreams need reliable audio and a caption plan.

This is also about roles. Every script needs a clear owner. Captions deserve someone who reviews them thoughtfully. Contrast and motion checks should fall to a named reviewer. And the final accessibility pass needs an accountable person before anything goes live. Without that clarity, tasks slip—not from a lack of care, but from uncertainty about who handles the final step.

Tip: build a short “definition of done” for a video. If the checklist lives in the same place as your content calendar or project tickets, it gets used.

Captions That Hold Up Under Review for YouTube Accessibility

Captions are often treated like a marketing feature. They increase overall watch time. Search performance benefits. And viewers stay engaged, even in public settings. All true. But captions also carry a basic promise to Deaf and hard-of-hearing viewers. The promise is simple. The words matter, and you should be able to access them.

Standards matter here, too. Web Content Accessibility Guidelines (WCAG) includes caption requirements for prerecorded and live video. Auto-captions are rarely enough on their own. Names get dropped. Product terms get mangled. Key phrases come back as nonsense. If your content includes instructions, legal details, or health and safety steps, “close enough” captions can become a serious problem.

Choose a Workflow You Can Repeat

Your workflow can still be practical. In YouTube Studio, most teams choose one approach and stick with it:
- Upload a caption file, like SRT or VTT, created in an editor or third-party tool.
- Start with auto-captions, then edit and correct them.
- Type captions in YouTube’s editor for shorter videos.
What matters is consistency. Pick a standard and apply it. Many teams upload edited caption files for major videos and review auto-captions for low-risk clips. That can work, as long as “reviewed” means a real check.

A quick quality checklist helps:
- Accuracy: capture what is said, plus key sound cues when they change meaning
- Timing: captions should appear with the speech, not late or early
- Readability: short chunks, correct punctuation, and speaker labels when needed
- Placement: do not cover critical visuals if you can avoid it
Two caption details teams often miss:
- Numbers and units: “15” vs “50” is not a small error in a demo or training video.
- Proper nouns: product names, locations, and people’s names are where auto-captions tend to drift.
Livestreams Need a Follow-Up Step

Livestreams add pressure because content is happening in real time. Live captioning can still be useful, but it depends heavily on audio quality. Use a strong mic. Reduce background noise. Speak clearly. Then, when the livestream becomes an archived video, upload corrected captions. That keeps the recording usable long after the event ends.

Transcripts and Chapters for YouTube Accessibility

Captions are not the same as transcripts. Captions are synced to the video. Transcripts live outside the player. They let people scan, search, and jump to what they need.

It helps to separate three things:
- Captions: synced text that follows audio
- Transcripts: full text of spoken content, not tied to exact timing
- Descriptive transcripts: transcripts that also include important visual info
Transcripts support more than disability access. They also help people who learn better by reading. For anyone who wants to revisit a specific tutorial step, a transcript makes it easy to review without rewatching the entire video. And when a user needs to search for a key phrase, the text lets them jump directly to the right section.

Chapters Make Long Videos Easier to Navigate

Chapters matter for the same reason. Long videos are easier to use when viewers can jump straight to what they need. For tutorials, webinars, and explainers, add timestamps and clear chapter titles. Skip vague labels like “Step 3.” Use names that match what a person is trying to do, like “Turn on captions in YouTube Studio” or “Fix timing and speaker labels.”

A simple way to level up chapters is to write them like help-center headings. If the title sounds useful on a support page, it will likely be useful in a video, too.

Bring Transcripts Onto Your Website

If you embed videos on your website, do not hide the transcript behind extra clicks. Put the transcript on the page, or link to it right next to the player. This helps users decide if the video is worth watching. It also helps your site’s content, as the page now includes the same information in an easy-to-scan format.

Audio Description for YouTube Accessibility

Many teams assume audio description means a big budget and a separate production track. Sometimes it does. Often, it does not.

The real question is whether the video includes meaningful visual details that are not shared in the audio. When a chart appears without explanation, that creates a gap. On-screen instructions that happen without being spoken create the same problem. And when important text is shown visually but never read aloud, that is another gap.

Descriptive Narration Works Well for Demos

In a talking-head video where the speaker explains everything, extra description may not be needed. But tutorials and demos are different. They rely on what the viewer sees. That is where descriptive narration becomes a strong option. The presenter can name what they are clicking, what changed on screen, and what the viewer should look for next.

A helpful habit in demos is to replace vague phrases with concrete ones. Instead of “click this,” say “select Settings,” or “open the Captions tab,” or “choose English from the language menu.” That supports more viewers than you might expect, including people watching on small screens.

Some teams also publish a second version, clearly labeled, like “with audio description,” when visuals are dense and constant. That approach can work well for training content, data-heavy explainers, or detailed product walkthroughs.

Whether you use narration or a described version, keep descriptions concise and focused. Describe what changes the meaning. Place it in natural pauses. Keep the tone neutral and consistent with the video’s style.

Visual Design Choices for YouTube Accessibility

Video design can either support understanding or fight against it. Many accessibility issues show up in the same places, again and again. Thumbnails. On-screen text. Contrast. Motion.

Contrast is a clear example. WCAG guidance uses targets like 4.5:1 for normal text and 3:1 for large text. Apply that mindset to thumbnails, titles, lower thirds, and callouts. If you need to place text over video footage, add a background block to keep it readable. Small text, thin fonts, and low contrast do not just look “clean.” They disappear for many viewers.

Tip: if it is important enough to show, it is important enough to leave up long enough to read. Fast overlays are a common source of missed information.

Reduce Flashing and Overly Fast Motion

Motion is another common trap. Fast flashing edits and strobe-like overlays can create real harm for some people. Avoid rapid flashing effects. Keep motion smooth. If an edit feels intense, it probably is. Review the sequence before publishing.

Do Not Rely on Color Alone

Also, do not rely solely on color to convey meaning. If a chart uses red and green, add labels. If an overlay uses color to mark “good” and “bad,” add shapes or text. And if something important appears visually, say it out loud too. That single habit supports many people at once.

Embedding and Ongoing Checks for YouTube Accessibility

The standard YouTube embed gives you a lot. Player controls are built in. Keyboard operation is supported. The player adapts across screen sizes. Those are strong foundations.

But your website still needs to do its part. An embedded video should not sit alone. Give it context:
- A descriptive heading before the player
- A short summary of what the video covers
- A transcript on the page, or a clear link to it nearby
Avoid auto-play when possible, especially with sound. Auto-play can overwhelm users and can make it harder for screen reader users to orient themselves on the page.

Quick Checks to Add to QA

Testing does not need to be complex. Build a few checks into QA:
- Can you reach and operate the player with only a keyboard?
- Does focus move in and out of the player in a predictable way?
- Are captions available and working in the embedded view?
- If you provide a described version, is it easy to find and understand?
Hit Play on YouTube Accessibility

Creating accessible YouTube content is not about chasing perfection or rebuilding your process from scratch. It is about making intentional choices that let more people engage with your videos, whether they are watching, listening, reading, or browsing. When captions are accurate, visuals are clear, and narration carries meaning, your content works harder and reaches further.

At 216digital, we help teams turn accessibility from a checklist into a sustainable strategy. We work with you to integrate WCAG 2.1 accessibility requirements into your video and web development roadmap, tailored to your tools, timelines, and business goals. From reviewing existing video content to building repeatable workflows for captions, transcripts, and embedded media, our focus is on progress you can maintain.

If you want guidance on strengthening your YouTube accessibility practices and aligning them with your digital accessibility goals, schedule a complimentary ADA Strategy Briefing with our team. We’ll help you make a plan that fits your team and your release cycles—on your terms.
Greg McNeil

December 12, 2025

How-to Guides

Accessibility, captions, Closed caption, How-to, screen readers, videos and audio content, Website Accessibility, Youtube
Web Accessibility: More Than Screen Readers

Most teams begin their accessibility work with screen readers. It’s a sensible place to start, and it teaches good habits—clear headings, useful labels, predictable focus. But if you watch how people actually move through the web, the story quickly widens. Someone turns on captions in a quiet office. Another tabs through every link because the mouse hurts their wrist. A shopper zooms text to 200% on a small screen. Others flip on “reduce motion” or prefer calmer layouts that don’t flicker or jump.

Accessibility is shaped by all of those moments. Screen readers matter, but they’re only one piece of a much larger puzzle. When you consider the full range of human needs—and how different kinds of assistive technology come into play—you end up with digital spaces that feel open, intuitive, and usable for far more people.

Screen Readers Matter—Just Not Alone

JAWS, NVDA, and VoiceOver transform what’s on the screen into speech or braille. If your site ignores them, people with vision disabilities get pushed out. Many developers learn a lot by testing with a screen reader: headings need to make sense, labels need to be clear, and focus has to move in a logical path.

Still, a site can sound fine and feel wrong. Someone who magnifies text might meet a broken layout. A keyboard user might fall into a modal they can’t escape. That gap is the real problem to solve.

A Wider View of Assistive Technology

Disability is common, not rare. The World Health Organization estimates that about 1.3 billion people—roughly 16% of the world—live with a significant disability. Only a small slice are blind (about 0.5%), and around 3.7% have moderate-to-severe vision loss. Vision matters, absolutely. But the web serves far more needs than vision alone.

Auditory Access

Deaf and hard-of-hearing people need accurate captions and transcripts for video and audio. As more sites publish reels, demos, and webinars, captions move from “nice to have” to “basic courtesy.”

Motor Access

Precise mouse movement is tough for many users, and sometimes impossible. Keyboard support is the baseline. Some people navigate by voice or eye-tracking. Real buttons and links—rather than clickable <div>s—make those tools work as expected.

Cognitive and neurological access. Dense walls of text, busy layouts, surprise pop-ups, and flashing animation raise the mental load. Clear headings, steady patterns, and plain language help people focus and finish tasks.

Speech Access

Some users rely on text-based or symbol-based communication. Well-labeled forms, predictable flows, and forgiving error messages make participation possible.

And here’s a useful twist: not everyone who uses a screen reader identifies as disabled. WebAIM’s 2024 survey found about one in ten regular users said they didn’t use it due to a disability. Preference and context matter, too.

When a “Pass” Still Leaves People Out

You can pass a quick check and still miss real-world barriers. Text that won’t resize to 200% without breaking the layout shuts out people with low vision. A menu that can’t be reached—or dismissed—by keyboard blocks shoppers who never touch a mouse. Color-only cues hide errors from users with color-vision differences. Dense, academic language can drain energy from anyone with memory or attention challenges.

A familiar story: a developer confirms that a form “reads fine,” then a teammate tries it with only Tab and Shift+Tab and can’t reach the submit button. The fix isn’t complicated. The habit is. Test with and without assistive technology, and try the settings your customers actually use.

Build For Real Use, Not Just Audits

Automated tools catch a lot, but they cannot tell you if the interaction makes sense. People need to know where they are, what just changed, and what to do next. If something looks like a button, it should behave like one. If an error appears, it should be specific, announced to the right place, and easy to fix. That’s usability and accessibility working together, not two separate tracks.

Practical Steps That Respect Assistive Technology

Start with semantic HTML. Headings in order. Real lists. Labels tied to inputs. Landmarks that map the page.

Make the keyboard a first-class path. Every interactive element should accept focus, show a visible focus style, and respond to expected keys like Enter, Space, and Escape.

Keep visuals readable. Meet contrast guidelines. Let text scale to at least 200% without hiding content or controls. Never rely on color alone to convey meaning; pair it with text or an icon.

Use everyday language. Short sentences help. Active voice helps. Concrete verbs help. Jargon is fine when you must use it—just define it once and move on.

Invite real users into the loop. Include people who rely on assistive technology for sign-in, search, checkout, and support flows. A one-hour session with three users can reveal more truth than a week of back-and-forth about edge cases.

Baking these habits into design reviews, code reviews, and QA lowers risk and stress. Teams ship calmer products when inclusion isn’t a last-minute scramble.

Good Usability Helps Everybody

Design choices aimed at one group often lift all boats. Captions help Deaf users and anyone watching a video on mute. High contrast helps people with low vision and anyone standing in bright sun. Keyboard access helps users with motor disabilities and power users who never take their hands off the keys. The same is true for people using assistive technology on small screens, old laptops, or slow connections—clear structure and predictable behavior make sites feel fast even when networks aren’t.

Tools That Talk, Design That Listens

Screen readers changed the web for millions, but they are one part of a broader story. If your site also supports magnification, keyboard navigation, clear language, steady layouts, and strong contrast—while playing well with a variety of assistive technology—you open the door to far more people and far fewer surprises.

If you’re ready to go beyond the basics, 216digital offers ADA briefings tailored to web teams. These sessions give you space to ask questions, identify gaps, and build an action plan with experts who understand accessibility from both a human and business perspective.

Greg McNeil

August 8, 2025

Testing & Remediation, The Benefits of Web Accessibility

assistive technology, keyboard accessibility, screen readers
How to Use JAWS for Screen Reader Testing
For millions of people with visual impairments, screen readers like Job Access With Speech (JAWS) are essential for navigating the digital world. According to a 2024 WebAIM survey, JAWS continues to lead the way as one of the most widely used screen readers, with 41% of respondents relying on it—outpacing other tools like NonVisual Desktop Access (NVDA) and Apple VoiceOver.

If you’re focused on building an accessible digital experience, incorporating screen reader testing into your workflow is a must. Not only does it help you create a more inclusive website, but it also supports compliance with accessibility laws like the Americans with Disabilities Act (ADA), WCAG standards, and more.

In this guide, we’ll break down how to use JAWS for accessibility testing, explore essential commands, and share tips for improving your website’s usability. But first, a quick look at what makes it such a powerful tool.

What is JAWS?

JAWS, developed by Freedom Scientific, is a screen reader that converts on-screen text into speech or braille for users who are blind or visually impaired. It allows users to navigate websites, applications, and documents without needing to see the screen.

JAWS is one of the most popular screen readers globally, making it an essential tool for web accessibility testing. By simulating how users rely on assistive technologies, JAWS helps you identify barriers that may prevent someone from fully engaging with your website.

Why is JAWS Essential for Accessibility Testing?

Accessibility testing is about ensuring everyone, regardless of ability, can interact with your website. JAWS plays a vital role in this process because:
- Real-World Simulation: JAWS mimics how many visually impaired users experience the web, allowing you to uncover issues that automated tools might miss.
- WCAG Compliance: Testing with JAWS helps ensure your website complies with the Web Content Accessibility Guidelines (WCAG), a global standard for digital accessibility.
- Improved User Experience: By identifying and fixing accessibility barriers, you create a more inclusive, user-friendly experience for all visitors.
How to Set Up JAWS
1. Download and Install JAWS: Visit the Freedom Scientific website to download JAWS. While it’s a paid tool, a 40-minute free demo mode is available for testing purposes.
2. System Requirements: Ensure your computer meets the system requirements. JAWS works on Windows but does not support macOS directly.
3. Set Up Your Environment: Use headphones to listen while testing so the screen reader’s output doesn’t interfere with other tasks.
4. Familiarize Yourself with the Settings: Spend time exploring the settings menu to adjust speech rate, verbosity, and other preferences.
Key JAWS Commands You Need to Know

Learning a few essential JAWS commands will make testing faster and more effective. Here are some basics to get you started:
- Navigating Headings: Press H to jump to the next heading and Shift + H to go to the previous heading.
- Lists: Press L to move to the next list and I to navigate to individual list items.
- Links: Use Tab to navigate through links or Insert + F7 to bring up a list of all links on the page.
- Forms: Press F to jump to the next form field and Shift + F to go to the previous one.
- Read the Page: Use Insert + Down Arrow to read the page continuously or Arrow Keys for manual reading.
Step-by-Step Guide to Testing Web Accessibility with JAWS

Start with the Homepage

Open your website’s homepage and let JAWS read through it. Check if the content flows logically and whether important elements, like headings and links, are announced correctly.

Test Navigation

Use the Tab key to navigate through links and interactive elements. Ensure focus indicators are visible and links are descriptive (e.g., “Learn More” should specify the action or page it leads to).

Evaluate Headings

Press Insert + F6 to bring up a list of headings. Verify that they are hierarchical and descriptive, making it easier for users to navigate.

Check Forms

Navigate through form fields using the F key. Test for proper labeling, keyboard navigation, and error message announcements.

Test Images and Alt Text

JAWS will read the alt text of images. Ensure images have descriptive alt text and that decorative images are marked appropriately (e.g., as null or empty).

Assess ARIA Roles and Landmarks

Use JAWS to test ARIA roles, landmarks, and live regions. Verify that these elements provide meaningful context to screen reader users.

Document Issues

As you test, document any barriers you encounter, such as missing alt text, unclear link descriptions, or inaccessible forms. Include the steps to replicate the issue and suggest solutions.

Tips for Effective JAWS Testing
- Pair with a Keyboard-Only Test: Ensure your website is fully navigable using only a keyboard, as this is crucial for screen reader users.
- Listen Critically: Pay attention to how JAWS announces content. Confusing or incomplete announcements signal a need for improvement.
- Focus on User Experience: Think about how easy it would be for a JAWS user to accomplish key tasks on your website, such as making a purchase or finding contact information.
- Test Multiple Pages: Don’t stop at the homepage. Test a variety of pages, including forms, product pages, and blogs.
Limitations of JAWS

While JAWS is an invaluable tool for accessibility testing, it has limitations:
- Cost: It is expensive, which may be a barrier for smaller teams or independent developers.
- Learning Curve: The abundance of commands and settings can be overwhelming for beginners.
- Not a Catch-All Solution: JAWS testing alone cannot guarantee accessibility compliance. It’s essential to pair it with other tools and techniques.
Why JAWS Should Be Paired with Other Tools

JAWS provides critical insights, but no single tool can capture all accessibility issues. Consider pairing it with:
- Automated Testing Tools: Tools like WAVE and Lighthouse can quickly identify common issues, such as missing alt text or low contrast.
- Other Screen Readers: Testing with multiple screen readers, such as NVDA or VoiceOver, ensures compatibility across platforms.
- Manual Testing: Involve users with disabilities in your testing process to gain authentic feedback.
Building a More Inclusive Web

Testing your website with JAWS is a powerful step toward creating an inclusive digital environment. By understanding how screen reader users interact with your content, you can uncover barriers and make meaningful improvements. Remember, accessibility is not just about compliance—it’s about creating a web that works for everyone.

While JAWS is a fantastic tool, it should be part of a broader accessibility strategy that includes other tools, user testing, and a commitment to following WCAG guidelines. With the actionable insights from this guide, you’re well on your way to improving your website’s accessibility and making a positive impact on all your users.

Let’s work together to make the web a more inclusive place!

Need help with accessibility testing? If you’re ready to take your accessibility efforts to the next level, 216digital can help. Our team specializes in comprehensive accessibility solutions that go beyond surface fixes. Schedule an ADA briefing with us today by using the contact form below. Let’s work together to make your website accessible to everyone.
Greg McNeil

January 16, 2025

How-to Guides, Testing & Remediation

Accessibility testing, assistive technology, How-to, JAWS, screen readers, user testing
Insights from WebAIM’s Screen Reader Survey #10
In today’s digital age, ensuring that your website is accessible to everyone is more important than ever. WebAIM’s Screen Reader Survey #10 offers valuable insights into how people with disabilities use screen readers, which can help you make your website more accessible. If you’re an IT director, company owner, or anyone involved in managing a website, understanding these takeaways can help you improve your site’s digital accessibility and ensure it meets standards like Web Content Accessibility Guidelines (WCAG).

Targeted Demographic: Who Uses Screen Readers?

The WebAIM Screen Reader Survey #10 highlights a diverse group of people who use screen readers. These users come from various backgrounds and have different needs, but they all rely on screen readers to access content online. Knowing your audience is vital to making your website accessible. Here is a breakdown of who these users are:
1. People with Visual Impairments: This is the largest group of screen reader users, with 76.6% of respondents being visually impaired. They might have complete blindness or low vision that prevents them from reading text on a screen. Screen readers convert text into spoken words for these individuals, allowing them to navigate and understand web content.
2. People with Learning Disabilities: Some users with learning disabilities find screen readers helpful. They might have difficulty processing written text or need assistance with comprehension. Screen readers can help by reading text aloud and breaking it down into more manageable parts.
3. Older Adults: As people age, they may experience vision loss or other difficulties that make screen reading challenging. Older adults may use screen readers to compensate for reduced vision or cognitive changes that affect their ability to interact with digital content.
4. People with Physical Disabilities: Some users with physical disabilities that affect their ability to use a mouse or keyboard may rely on screen readers to navigate websites. They might use adaptive technology to interact with their devices, making screen readers an essential tool for accessing web content.
Targeted Age: Understanding the Age Range

The survey also reveals insights into the age range of screen reader users. While screen readers are crucial for users of all ages, certain age groups use them more frequently:
1. Younger Users: Younger users with disabilities are increasingly tech-savvy and may use screen readers alongside other assistive technologies. They often expect modern websites to be accessible and are quick to notice when accessibility features are lacking.
2. Middle-Aged Users: This group may include people who have acquired disabilities later in life or who are managing long-term conditions. They often need screen readers to access work-related or personal online content.
3. Older Adults: As mentioned earlier, older adults may use screen readers due to age-related vision loss or other issues. This demographic is growing, making it essential for websites to cater to their needs.
Understanding the age range of screen reader users can help you design your website in a way that accommodates different life stages and technological preferences.

Disabilities and Disability Types: Types of Disabilities Addressed

Screen readers are used by individuals with a range of disabilities. Let’s take a closer look at the types of disabilities that screen readers help address:
1. Visual Impairments: This includes both complete blindness and low vision. Screen readers convert on-screen text into speech, making content accessible to users who cannot see it. For users with low vision, screen readers can be combined with other assistive technologies, such as screen magnifiers.
2. Cognitive Disabilities: Users with cognitive disabilities might struggle with memory, attention, or processing information. Screen readers can assist by reading text aloud, which can make it easier for these users to understand and retain information.
3. Motor Disabilities: Individuals with motor disabilities might have difficulty using a keyboard or mouse. Screen readers can help by allowing users to navigate websites using voice commands or other adaptive technologies.
4. Hearing Impairments: While screen readers are primarily used by people with visual impairments, some individuals with hearing impairments might also use them. For example, screen readers can be used in conjunction with other assistive technologies to provide a complete experience for users with multiple disabilities.
The Importance of Digital Accessibility

Understanding these demographics and disability types underscores the importance of digital accessibility. Web accessibility ensures that your website can be used by everyone, regardless of their abilities. This is not just about compliance with standards like WCAG; it is about creating an inclusive digital environment.

This is why digital accessibility should be a priority for your business:
1. Legal Compliance: Many countries, including the United States, have laws that require websites to be accessible. Failing to meet these requirements can result in legal action, which can be costly and damaging to your reputation.
2. Broader Audience: By making your website accessible, you open it up to a wider audience. This includes not only people with disabilities but also those who use assistive technologies or have temporary impairments.
3. Better User Experience: Accessible websites often provide a better overall user experience. Features that help screen reader users can also benefit other users, such as more straightforward navigation and more readable content.
4. Enhanced Brand Image: Companies that prioritize accessibility are seen as more inclusive and socially responsible. This can improve your brand’s image and help build a positive reputation.
Making Your Website Accessible

To ensure your website meets digital accessibility standards, follow these best practices:
1. Adhere to WCAG Guidelines: WCAG is the gold standard for web accessibility. They provide specific recommendations for making web content more accessible. Familiarize yourself with these guidelines and implement them on your site.
2. Test with Screen Readers: Regularly test your website with screen readers to identify any accessibility issues. This can help you ensure that your content is being read correctly and that users can navigate your site effectively.
3. Seek Feedback: Get feedback from actual screen reader users. Their insights can be invaluable in identifying and addressing accessibility issues that you might not have considered.
4. Stay Updated: Digital accessibility is an evolving field. Keep up with the latest trends and updates to ensure your website remains compliant and accessible.
Wrapping Up

WebAIM’s Screen Reader Survey #10 provides crucial insights into who uses screen readers and how they interact with web content. By understanding the demographics, age ranges, and disability types of screen reader users, you can make informed decisions about improving your website’s digital accessibility. Adhering to WCAG guidelines and incorporating accessibility best practices will not only help you comply with legal requirements but also enhance the user experience for everyone.

For IT directors and company owners, prioritizing web accessibility is a smart move that benefits both your users and your business. By taking these insights to heart, you can create a more inclusive and effective online presence.

If you’d like to talk further about your web accessibility initiative, Schedule a Complimentary ADA Strategy Briefing with the experts at 216digital. We will help you take the steps towards web accessibility on your terms by developing a strategy to integrate WCAG 2.1 compliance into your development roadmap.
Greg McNeil

August 6, 2024

WCAG Compliance

digital accessibility, screen readers, Web Accessibility, WebAIM’s Screen Reader Survey, WebAIM’s Screen Reader Survey #10, Website Accessibility
Screen Readers 101: Making Your Site Accessible
In today’s digital age, making your website accessible to everyone is more important than ever. One critical aspect of digital accessibility is ensuring that your site is compatible with screen readers. But what exactly are screen readers, and why is it so important to make sure your website works well with them? In this blog post, we’ll dive into what screen readers are, who uses them, how they browse the Internet, and how you can test your website to ensure it’s screen reader-friendly.

What are Screen Readers and Who Uses Them?

Let’s start with the basics. A screen reader is a piece of software that reads aloud the text displayed on a computer or mobile device screen. It’s a vital tool for people who are blind or have severe visual impairments. However, screen readers are also used by individuals with other disabilities, such as those with learning disabilities or certain cognitive impairments, who may find it easier to listen to content rather than read it.

So, who exactly uses screen readers? The answer is billions of people around the world. In the United States alone, there are an estimated 12 million people over 40 with a visual disability. For these individuals, screen readers are essential for accessing the Internet, working, and communicating. Without screen readers, many websites would be entirely inaccessible to them.

How Do Screen Reader Users Browse the Internet?

Browsing the Internet with a screen reader is a completely different experience than browsing with sight. For starters, screen reader users don’t navigate web pages visually—they rely on audio cues and keyboard commands to get around.

Here’s a simplified version of how it works:
1. Screen Reader Starts Reading: When a screen reader user opens a webpage, the screen reader begins reading the content from top to bottom. It reads out the text, describes images (if alt text is provided), and announces the presence of links, buttons, and other interactive elements.
2. Keyboard Navigation: Instead of using a mouse, screen reader users navigate through the website using keyboard commands. They might use the Tab key to move between links, headings, and form fields, or shortcuts to jump to specific sections of the page, such as the main content or a list of links.
3. Listening for Context: Screen reader users often listen to the content at a much faster speed than normal. They also rely heavily on headings, landmarks, and other structural elements to understand the layout and flow of the page. For example, a user might jump from heading to heading to quickly scan the page and find the information they need.
4. Interacting with Elements: When a user encounters a form field, button, or link, the screen reader announces what it is and sometimes gives instructions on how to interact with it. For example, if there’s a “Submit” button, the screen reader might say, “Button: Submit. Press Enter to activate.”
For screen reader users, a well-structured, accessible website is key to having a smooth and efficient browsing experience. But if a website is not properly optimized for screen readers, it can become frustrating, confusing, or even impossible to use.

Why is Screen Reader Testing Important?

Now that you have a basic understanding of what screen readers are and how they’re used, let’s talk about why testing your website for screen reader compatibility is so important.

Ensuring Digital Accessibility

First and foremost, screen reader testing is crucial for ensuring digital accessibility. As a website owner, developer, or content creator, it’s your responsibility to make sure that your website is accessible to everyone, including people with disabilities. Screen reader testing helps you identify and fix issues that could prevent people who rely on these tools from accessing your content.

Complying with Legal Requirements

In the United States, websites are required by law to be accessible to people with disabilities. The Americans with Disabilities Act (ADA) Title II and Section 508 of the Rehabilitation Act are two key laws that apply to web accessibility. If your website is not accessible, you could be at risk of legal action, which could result in costly fines and damage to your reputation. By performing screen reader testing, you can ensure that your website complies with these laws.

Improving User Experience

Accessibility isn’t just about legal compliance—it’s also about providing a better user experience for everyone. When your website is accessible to screen reader users, it’s also likely to be more user-friendly for other visitors. For example, clear headings, logical page structure, and well-labeled buttons benefit all users, not just those with disabilities.

Reaching a Wider Audience

By making your website accessible to screen reader users, you’re opening it up to a wider audience. This can lead to more traffic, better SEO, and ultimately, more success for your business. Accessibility should be seen as an investment in your website’s future, not just a legal obligation.

What Are the Different Approaches to Accessibility Testing?

There are several different approaches to accessibility testing, each with its own advantages and disadvantages. To ensure that your website is fully accessible, it’s important to use a combination of these methods.

Automated Testing

Automated testing tools can scan your website for common accessibility issues, such as missing alt text, insufficient color contrast, and incorrect HTML structure. These tools are fast and can cover a lot of ground in a short amount of time. However, they can’t catch every issue—especially those related to screen reader compatibility.

Some popular automated accessibility testing tools include:
- WAVE: A web accessibility evaluation tool that highlights accessibility issues directly on your webpage.
- Lighthouse: A tool built into Chrome that can audit your website for performance, SEO, and accessibility issues.
While automated testing is a great starting point, it should never be the only method you use. Automated testing covers only 30-40% of accessibility guidelines and can miss more subtle or complex problems that require human judgment.

Manual Testing

Manual testing involves a human tester navigating your website and checking for accessibility issues. This approach is essential for catching issues that automated tools might miss, such as how well your website works with a screen reader. Manual testing can be more time-consuming and requires a deeper understanding of web accessibility, but it provides a more accurate picture of your website’s accessibility.

During manual testing, you should:
- Check Keyboard Navigation: Ensure that all interactive elements, such as links, buttons, and form fields, can be accessed and activated using only the keyboard.
- Test with a Screen Reader: Use a screen reader to navigate your website and listen to how the content is announced. Pay attention to whether the screen reader correctly identifies headings, lists, buttons, and other elements.
User Testing

User testing involves real users with disabilities testing your website and providing feedback on their experience. This is the most effective way to identify and fix accessibility issues, as it provides insight into how your website works in the real world.

To conduct user testing:
- Recruit Testers: Find users who rely on screen readers and other assistive technologies to test your website. You can reach out to local organizations, online communities, or professional networks to find willing participants.
- Observe and Take Notes: Watch how the testers interact with your website and take note of any issues they encounter. Pay attention to their feedback and use it to make improvements.
- Iterate and Improve: After making changes based on user feedback, test again to ensure that the issues have been resolved.
User testing can be more expensive and time-consuming than other methods, but it provides the most valuable insights.

Not sure what form of accessibility testing is right for you? Check out our article, Choosing the Right Accessibility Audit for Your Goals, for more information.

How to Perform Screen Reader Testing

Screen reader testing is a crucial part of manual and user testing. Here’s a step-by-step guide to performing screen reader testing on your website.

Choose Your Screen Readers

There are several different screen readers available, each with its own unique features and quirks. The most commonly used screen readers in the United States are:
- NVDA (NonVisual Desktop Access): A free and open-source screen reader for Windows.
- JAWS (Job Access With Speech): A popular screen reader for Windows, often used in workplaces.
- VoiceOver: The built-in screen reader for MacOS and iOS devices.
- TalkBack: The built-in screen reader for Android devices.
To ensure that your website is accessible to the widest audience possible, it’s important to test with more than one screen reader.

Familiarize Yourself with Screen Reader Commands

Screen readers are controlled through a series of keyboard commands. Before you start testing, take some time to familiarize yourself with the basic commands for the screen reader you’re using. Most screen readers have a “practice mode” where you can learn and try out different commands.

For example, in NVDA, you can press Ctrl + Alt + N to start the screen reader, use the Tab key to move through links and buttons, and press H to jump between headings.

Navigate Your Website

Start by opening your website with the screen reader turned on. Listen to how the screen reader announces the content, and use keyboard commands to navigate through the site. Pay attention to the following:
- Headings: Are they announced correctly? Do they provide a clear structure for the page?
- Links and Buttons: Are they labeled correctly? Do they make sense out of context?
- Forms: Are the form fields and labels announced clearly? Is it easy to fill out the form using only the keyboard?
Identify and Fix Issues

As you navigate your website, take note of any issues you encounter. For example, if the screen reader doesn’t announce a button’s label, it may be missing an aria-label attribute. If a heading is skipped, it might be due to incorrect HTML markup.

Once you’ve identified the issues, go back and fix them in your website’s code. Then, test again to ensure that the problem has been resolved.

Test on Different Devices

Screen reader behavior can vary depending on the device and browser being used. After testing on your primary device, try testing on different devices and browsers to ensure a consistent experience for all users.

Conclusion

In today’s world, making your website accessible to everyone isn’t just a nice-to-have—it’s a must-do. Ensuring your site works smoothly with screen readers is a big part of that. By taking the time to test and optimize your website for screen readers, you’re not only complying with legal requirements but also creating a better experience for all users. Plus, you’re opening the doors to a wider audience, which is always good for business.

If you’re ready to take the next step in making your website truly accessible, why not schedule a complimentary ADA Strategy Briefing with 216digital? We’re here to help you navigate the ins and outs of digital accessibility and ensure your site is welcoming to everyone. Let’s make the web a better place, one website at a time.
Greg McNeil

July 31, 2024

WCAG Compliance

assistive technology, digital accessibility, screen readers, Web Accessibility, web development, Website Accessibility

How to Test Mobile Accessibility using TalkBack

What TalkBack Is and Why It Matters for Mobile Accessibility Testing

Preparing Your Device for Effective Screen Reader Testing

Enabling and Disabling TalkBack Without Breaking Your Flow

Core TalkBack Gestures You Actually Need for Testing

Using Menus to Navigate by Structure

A Repeatable First-Pass Screen Reader Workflow

High-Impact Scenarios to Test More Deeply

Capturing Findings and Making TalkBack Testing Sustainable

YouTube Accessibility: Captions, Audio, and Design

Start With a Plan for YouTube Accessibility

Set a Baseline and Assign Ownership

Captions That Hold Up Under Review for YouTube Accessibility

Choose a Workflow You Can Repeat

Livestreams Need a Follow-Up Step

Transcripts and Chapters for YouTube Accessibility

Chapters Make Long Videos Easier to Navigate

Bring Transcripts Onto Your Website

Audio Description for YouTube Accessibility

Descriptive Narration Works Well for Demos

Visual Design Choices for YouTube Accessibility

Reduce Flashing and Overly Fast Motion

Do Not Rely on Color Alone

Embedding and Ongoing Checks for YouTube Accessibility

Quick Checks to Add to QA

Hit Play on YouTube Accessibility

Web Accessibility: More Than Screen Readers

Screen Readers Matter—Just Not Alone

A Wider View of Assistive Technology

Auditory Access

Motor Access

Speech Access

When a “Pass” Still Leaves People Out

Build For Real Use, Not Just Audits

Practical Steps That Respect Assistive Technology

Good Usability Helps Everybody

Tools That Talk, Design That Listens

How to Use JAWS for Screen Reader Testing

What is JAWS?

Why is JAWS Essential for Accessibility Testing?

How to Set Up JAWS

Key JAWS Commands You Need to Know

Step-by-Step Guide to Testing Web Accessibility with JAWS

Start with the Homepage

Test Navigation

Evaluate Headings

Check Forms

Test Images and Alt Text

Assess ARIA Roles and Landmarks

Document Issues

Tips for Effective JAWS Testing

Limitations of JAWS

Why JAWS Should Be Paired with Other Tools

Building a More Inclusive Web

Insights from WebAIM’s Screen Reader Survey #10

Targeted Demographic: Who Uses Screen Readers?

Targeted Age: Understanding the Age Range

Disabilities and Disability Types: Types of Disabilities Addressed

The Importance of Digital Accessibility

Making Your Website Accessible

Wrapping Up

Screen Readers 101: Making Your Site Accessible

What are Screen Readers and Who Uses Them?

How Do Screen Reader Users Browse the Internet?

Here’s a simplified version of how it works:

Why is Screen Reader Testing Important?

Ensuring Digital Accessibility

Complying with Legal Requirements

Improving User Experience

Reaching a Wider Audience

What Are the Different Approaches to Accessibility Testing?

Automated Testing

Manual Testing

User Testing

How to Perform Screen Reader Testing

Choose Your Screen Readers

Familiarize Yourself with Screen Reader Commands

Navigate Your Website

Identify and Fix Issues

Test on Different Devices