Example 2 - Dodgy Dialogs

Summary

Some screen readers present webpage dialogs in interactive/forms mode, rather than in regular browse mode. This can cause confusion for novice users.

Explanation

A popular trend in webpage design is to use modal dialogs for displaying information and collecting input from end users. The W3C provides roles, properties and guidelines for coding accessible webpage dialogs, but leaves the implementation and presentation of dialogs up to individual assistive technology vendors.

Beginner to intermediate users of the NVDA screen reader frequently get into trouble with dialogs, because NVDA -- unlike other screen readers -- presents the contents of modal dialogs in application/interactive mode rather than in browse mode. This works well when the dialog looks and behaves like an operating system dialog, with a simple message and a couple of controls users can activate to respond to that message, but webpage dialogs frequently contain a lot of static text.

When a screen reader's application/forms mode is turned on, the keyboard actions are passed through to the webpage. The users are not able to navigate static content using arrow keys and other screen reader reading commands; something they can do in the screen readers browse mode. But users can use keyboard commands to force screen readers out of forms mode and into browse mode. In NVDA you do this by either pressing the NVDA key and space bar or the escape key. Unfortunately most dialogs are coded so that pressing the escape key dismisses the dialog, so users who try the escape key close the dialog before they can read it.

One can say that modal dialogs should not be used for presenting text content, that NVDA should not present modal dialogs in application mode (other screen readers present modal dialogs in browse mode), or that the end user should know how to operate their screen reader.

Imagine...

Your digital library website presents information about individual book titles using a modal dialog, Users of screen readers, NVDA in particular, have frequently called in and complained that the book descriptions are totally inaccessible, because they can't use the arrow keys to read the dialog contents.

You could implement a number of workarounds. You can add a tab stop and add the document role on static text in your dialog (which indicates to screen readers that browse mode is required), present the text as an expandable section rather than in a dialog, or put it on a separate webpage. But all of these solutions require development and testing and they affect other website users (e.g. people who use other screen readers and people with dyslexia who prefer modal dialogs). Or you could file an issue with NVDA or explain the keyboard shortcut for browse mode to your NVDA users.

So...

Whose Line Is It Anyway?