Access Matters

These results refer back to a quiz and test case from several weeks ago. Our first test was in Quiz 4.1.4: JavaScript - part 1. Results from about 60 runs of the test case were compiled by James Edwards.

As you examine the results tables, be aware that most cells contain additional descriptive information within a title attribute. Clicking the cell will display the full text for that cell in a floating block. Here we go…

Explanation - Summary of Results for Part 1: Navigating links

Browser-based screenreaders are able to read and/or navigate through a page without moving the focus (the dotted-line around links that otherwise accompanies keyboard navigation). This is because they have their own, “virtual” cursor or highlight, which tracks where the user is in a document independently of the main cursor.

Many events are only reported on links if the action would set or transfer focus to an element, further varying by whether the action would: set focus onto an element when none other is currently focussed; or transfer focus to an element from a different focussed element (as opposed to a currently-focussed element receiving another event that retains it).

Actions that set or transfer focus vary between readers:

• In Windows Eyes a link takes the focus when actuated,
  and also when navigating (like a vanilla browser)
• In JAWS and Connect Outloud a link takes the focus when actuated,
  but not when navigating (unless the “Virtual PC Cursor” is OFF,
  an atypical setting which the manual disencourages for Internet Explorer)
• In Hal a link takes the focus when actuated,
  but not when navigating
• In Home Page Reader a link never takes the focus

The first table shows results for browser-based screenreaders.

The second table shows results for the speaking/voicing capabilities of Opera 8 with Voice, Safari with VoiceOver, and Firefox with the FoxyVoice extension. These devices are designed to provide supplementary speech output/control to users who are not (or not completely) blind, rather than the fully-fledged screenreading functionality needed by those who are. These devices mostly generate the same events as their vanilla browser, but with noted exceptions.

With all devices, there were no differences in the results when comparing static HTML links, with links that were generated in JavaScript. No differences in event-bubbling behavior were observed between readers and their vanilla browser. These results are for keyboard, voice and reader-specific browsing mechanisms only; data for using a device while navigating with the mouse are not included.

yes

The event is reported

yes*

The event is reported with additional data

yes^

The event may be reported without expected additional data

yes+

The event may be reported more than once, or generate or be generated by other events at the same time

<yes

The event is typically reported, but not in particular circumstances

>no

The event is not typically reported, but is in particular circumstances

no

The event is not reported

-

[this device/mode combination doesn’t exist]

…?

[wholly or partly inferred from other data]

yes

The event is reported

yes*

The event is reported with additional data

yes^

The event may be reported without expected additional data

yes+

The event may be reported more than once, or generate or be generated by other events at the same time

<yes

The event is typically reported, but not in particular circumstances

>no

The event is not typically reported, but is in particular circumstances

no

The event is not reported

-

[this device/mode combination doesn’t exist]

…?

[wholly or partly inferred from other data]

There you have it. Do you see any recommendations you can make from seeing these results?