Analytical Navigation Desktop & Mobile: Using Screen Readers for Auditing

Welcome to the Access Squad auditor training curriculum. In this comprehensive module, we will explore the critical discipline of Analytical Navigation using screen readers across both desktop and mobile platforms.

As accessibility auditors, our use of screen readers fundamentally differs from that of everyday users. While everyday users rely on screen readers to consume content and accomplish daily tasks efficiently, auditors use these same tools to interrogate, dissect, and evaluate the underlying structure of a digital interface. This guide will equip you with the technical skills to transition from simply "browsing as a user" to "interrogating as an auditor," utilizing the advanced features of NVDA, JAWS, iOS VoiceOver, and Android TalkBack.

The Paradigm Shift: Browsing vs. Interrogating

To effectively audit digital properties, you must first understand the distinction between browsing and interrogating.

Browsing as a User

When a person with a visual disability browses a website or app, their goal is to extract information or complete a transaction. They utilize shortcut keys (like pressing 'H' for headings or 'B' for buttons) to rapidly skip past irrelevant content. If they encounter a barrier, they might attempt a workaround or abandon the page entirely. Their navigation is primarily functional and goal-oriented.

Interrogating as an Auditor

An accessibility auditor's goal is entirely different. You are not just reading the page; you are dissecting its anatomy. Interrogating means purposefully navigating into complex, problematic, or hidden areas of the interface to evaluate compliance with the Web Content Accessibility Guidelines (WCAG). - You do not simply skip content; you analyze the sequence of the content (Focus Order). - You do not just listen to a button's label; you verify its Name, Role, and Value. - You actively test boundary conditions, such as interacting with modal dialogs, custom widgets, and dynamic updates (ARIA live regions).

To perform this interrogation, we leverage analytical features built into screen readers.

Desktop Screen Readers: The Auditor's Toolkit

Desktop screen readers like NVDA (NonVisual Desktop Access) and JAWS (Job Access With Speech) are the workhorses of accessibility testing. They offer specific analytical tools that are indispensable for a thorough audit.

1. The Speech Viewer / Text Viewer

The Tool: - NVDA: Speech Viewer (Found under NVDA Menu > Tools > Speech Viewer) - JAWS: Text Viewer / Speech History

Auditor Application: For sighted auditors or those who need to document exact verbiage for bug reports, the Speech Viewer is non-negotiable. It renders the exact text strings that the screen reader synthesizes into a visual text window.

Instead of re-listening to a complex ARIA widget announcement multiple times to transcribe it, an auditor can look at the Speech Viewer and copy the exact output. For example, if a button incorrectly announces as "Submit, unlabelled, button, graphic," the Speech Viewer provides the undeniable proof needed for an audit report. It is the ultimate tool for verifying accessible names and descriptions accurately.

2. The Elements List

The Tool: - NVDA: Elements List (Insert + F7) - JAWS: Window List / Various Lists (Insert + F3 brings up the virtual list menu)

Auditor Application: The Elements List is an auditor's x-ray vision for page structure. It compiles all headings, landmarks, links, buttons, and form fields into a single dialog box.

When interrogating a page, the Elements List allows you to:

Audit Heading Hierarchy: Quickly spot skipped heading levels (e.g., an H1 followed by an H3).
Evaluate Link Purpose: Scan the list of links to find ambiguous link text like "Click Here" or "Read More" that lack context.
Check Landmark Regions: Ensure the page is properly divided into meaningful regions (header, main, footer) without orphan content.

The Tool: - NVDA: Object Navigation (Numpad keys to move by object rather than virtual cursor) - JAWS: Touch Cursor (Shift + Numpad Plus)

Auditor Application: Sometimes, the standard virtual cursor (which reads the DOM linearly) hides the true structure of an application, especially in complex web apps or desktop software. Object Navigation allows auditors to break out of the linear reading mode and explore the hierarchical object tree of the application (Parent, Child, Next Sibling, Previous Sibling). This is crucial when auditing custom widgets where the visual layout does not match the DOM order, or when trying to determine exactly why a specific element is being ignored by the virtual cursor.

Mobile Screen Readers: Native App Dissection

Auditing mobile applications requires a different tactile approach. Mobile screen readers rely on gestures rather than keyboard commands, and understanding how to manipulate these gestures analytically is key to interrogating iOS and Android interfaces natively.

Swiping vs. Explore by Touch

When testing mobile apps natively, you have two primary methods of navigation: 1. Explore by Touch: Dragging a single finger across the screen. The screen reader announces whatever is under the finger. 2. Linear Swiping: Swiping left or right with one finger to move to the previous or next focusable element.

Auditor Application: A common auditor mistake is relying solely on "Explore by Touch." While useful for spatial orientation, you must use linear swiping (left/right) to test Focus Order. Linear swiping forces the screen reader to follow the programmatic focus order defined by the developers. If you swipe right and the focus jumps erratically around the screen, you have identified a critical WCAG 2.4.3 (Focus Order) violation.

iOS VoiceOver: Mastering the Rotor

The Tool: The Rotor is activated by twisting two fingers on the screen as if turning a dial.

Auditor Application: The Rotor is the most powerful analytical tool on iOS. It changes how VoiceOver interprets the standard up/down swipe gestures. For an auditor, the Rotor is used to:

Navigate by Headings/Landmarks: Isolate and test the structural skeleton of the app.
Navigate by Form Controls: Jump between text fields and switches to ensure they are properly labeled and grouped.
Navigate by Characters/Words: When a label is mispronounced or seems incorrect, change the Rotor to "Characters" and swipe down to spell out the accessibility label letter-by-letter. This exposes invisible unicode characters, inappropriate acronyms, or missing spaces in the underlying label.
Examine Audio Graphs: Analyze complex data charts presented to VoiceOver users.

The Tool: - Reading Controls: Swiping up/down with three fingers (or up/down with one finger depending on TalkBack version/settings) changes the reading granularity. - TalkBack Menu: A multi-part menu accessed by tapping the screen with three fingers (or a down-then-right swipe).

Auditor Application: Similar to the VoiceOver Rotor, TalkBack's Reading Controls allow auditors to dissect text strings by characters, words, or paragraphs.

The TalkBack Menu provides advanced analytical features:

Describe Image: Useful for checking if TalkBack's auto-generated descriptions are conflicting with missing alt text.
Screen Search: Allows the auditor to find specific elements on a cluttered screen and verify if they are programmatically exposed.
Custom Actions: When auditing custom interactive elements (like a swipeable list item), checking the TalkBack menu for "Actions" verifies whether developers have properly implemented AccessibilityNodeInfo actions, allowing screen reader users to perform gestures that would otherwise require complex visual dragging.

Practical Audit Techniques: Putting it Together

To finalize your analytical navigation training, let's look at how to combine these tools in practical audit scenarios.

Scenario 1: The Hidden Element Trap

The Problem: Visually hidden elements (like visually off-screen skip links or hidden modal dialogs) might still be readable by screen readers. The Interrogation: 1. Use standard linear navigation (Tab key on desktop, right-swipe on mobile). 2. If the screen reader focuses on an element that is visually hidden, but not programmatically hidden (`aria-hidden="true"` or `display: none`), you've found a violation. 3. Use the desktop Elements List to see if hidden background content is still populated in the accessibility tree while a modal dialog is open.

Scenario 2: Verifying Name, Role, Value

The Problem: A custom-built checkbox visually looks like a checkbox, but is coded as a standard `

`. The Interrogation: 1. Navigate to the element using the screen reader. 2. Listen to (or check the Speech Viewer for) the announcement. Does it say "Subscribe, Checkbox, Not Checked"? 3. If it merely says "Subscribe" (missing the Role) or doesn't indicate its state (missing the Value), it fails WCAG 4.1.2. 4. On iOS, check if the "Double tap to toggle" hint is present, which indicates proper trait assignment in Swift/Objective-C.

Conclusion

Analytical navigation is the hallmark of a professional accessibility auditor. By mastering the Elements List and Speech Viewer on desktops, and dissecting interfaces with the Rotor and TalkBack Menus on mobile devices, you transcend the boundaries of a standard user. You become an interrogator of code, ensuring that digital interfaces are not just technically usable, but robust, equitable, and fully compliant with accessibility standards. Practice these techniques relentlessly, and your audits will become sharper, more accurate, and undeniably authoritative.

Welcome to the Access Squad. Happy auditing.

What do you think?

Give your reaction to this article