Freedom scientific have provided documentation on how the JAWS screen reader support WAI-ARIA. It is available as a microsoft word document. Below is the same information in HTML format

JAWS ARIA Support

Preface

Before discussing JAWS support for ARIA, it’s important to understand the relationship between the ARIA markup itself, the browser in which the markup is rendered, and JAWS as it provides spoken or Braille information to users.

First, ARIA markup was designed to insert information useful to assistive technologies into existing HTML code. It exists as a way to label controls and to provide information about their states. But adding ARIA support to a Web page does not change the presentation or behavior of that Web page to sighted users. For example, adding the ARIA role of “checkbox” to a “div” tag within a Web page will produce no visible effect on the page. Instead, if there is a check box on the page which has been rendered without using the “input” tag, the ARIA role of “checkbox” can be added to the code to inform assistive technology users that a check box appears at that point on the page.

Second, the browser plays a big role in interpreting ARIA markup. Most browsers support some type of accessibility API (application programming interface), and assistive technologies use the API to get information about what is presented on the screen. So, ARIA markup is transformed by the browser into information that fits the accessibility API it supports. Then, the information provided by the API is consumed by the assistive technology. That means JAWS support of ARIA depends heavily on the browser being used.

Third, JAWS gathers information from the ARIA markup and the browser’s API and presents it in a meaningful way to screen reader users. Because of the above interactions, the quality of JAWS support for ARIA markup is inextricably tied to the careful, thorough application of ARIA markup on a Web page, and comprehensive support provided by the browser in which the markup is rendered.

For best results, Freedom Scientific recommends that Web page authors read the ARIA best practices guide carefully before adding ARIA markup to their pages. Also, concepts such as roles, states, landmarks, and so on are defined as part of the ARIA specification, and are therefore not defined in this document. If you are unfamiliar with these concepts please read through the ARIA documentation before continuing.

Note: For the reasons described above, there may be differences in JAWS ARIA support between IE and Firefox. Please test any examples in both browsers. And please specify which browser you’re using when reporting problems to Freedom Scientific.

Concepts

It’s a good idea to have a firm grasp of the following concepts. These items form the basis of many descriptions throughout the document.

Virtual Cursor

JAWS presents Web pages using the JAWS Virtual Cursor. This allows users to read and navigate a Web page as though it were a text document. Users press the arrow keys to read line by line, word by word, character by character, and so on. JAWS also provides quick navigation keys, which are alpha-numeric keys that move the Virtual Cursor to features of the page such as links, headings, and form controls. In addition, users can press the TAB key to move between focusable elements on the page.

Using the arrow keys or quick nav keys to change the position of the Virtual Cursor does not change the actual focus point in the application. This means that even if JAWS reads the text of a given link on a Web page for example, that link doesn’t necessarily have the keyboard focus. Note: The keyboard focus is typically represented visually as a highlighted area surrounding a control.

Conversely, pressing the TAB or SHIFT+TAB key to navigate moves the focus point and the Virtual Cursor follows the focus.

Forms mode

Because JAWS uses the arrow keys and alpha-numeric keys for Virtual Cursor navigation, these keyboard commands are not passed through to interactive controls (form fields) on the page. This approach has the added benefit of protecting users from inadvertently changing form field values or activating controls on the page while simply reviewing the content.

Forms mode is when JAWS turns over processing of the above keys to form controls so that users can interact with them. For example, when using the Virtual Cursor, pressing the letter F moves the Virtual Cursor to the next form field on the Web page; in forms mode, pressing the letter F types the character “f”.

Auto Forms Mode

Before JAWS 10, JAWS users had to enter and exit forms mode manually. Users navigated to a given control using the Virtual Cursor, and would then press the ENTER key to go into forms mode. The PC Cursor key (NUMPAD PLUS) caused JAWS to exit forms mode.

When forms mode is manually activated on a given form control, focus is set to that control.

Auto forms mode is a feature that tells JAWS to be smart about when to enter and exit forms mode. This is a setting which is on by default. This approach provides a seamless experience for JAWS users when both reading and interacting with a Web page.

The behavior of auto forms mode depends on the type of form field in question and the keyboard command used to navigate to it. The following is a description of the keyboard commands and how they affect Web page form fields:

ARROW Keys:

When the Virtual Cursor is active, JAWS enters forms mode upon encountering an edit field. Focus is moved to the edit control, and users can begin typing.

In forms mode, the ARROW keys move the caret within the edit field.

In forms mode, if an ARROW key is pressed and the caret has already reached the boundary of the edit field, JAWS exits forms mode and resumes using the Virtual Cursor.

In forms mode, pressing ESC or NUMPAD PLUS will cause JAWS to exit forms mode.

Edit fields are the only controls for which JAWS enters or exits forms mode automatically based on the arrow keys. For other controls, if JAWS is using the Virtual Cursor, it will continue to use the Virtual Cursor. This is so that users don’t accidentally change the value of a control while attempting simply to navigate past it. If JAWS is already in forms mode, ARROW keys will not cause JAWS to leave forms mode. This is so that users won’t unintentionally leave forms mode while interacting with a control. When ARROW keys are used to navigate to non-edit controls, users must activate forms mode manually by pressing ENTER.

TAB Keys:

Using the TAB key always causes the focus point to move. When focus changes to a given form control, JAWS auto forms mode activates forms mode based on the type of the control in question.

For edit fields, combo boxes, spin controls, list controls, tab controls, menu bars, tree views, and grid cells, JAWS enters forms mode automatically.

For buttons and check boxes, JAWS exits forms mode.

In forms mode, pressing ESC or NUMPAD PLUS will cause JAWS to exit forms mode.

Note: It is possible to move to a form field by using TAB keys and to move away from that form field using ARROW keys, and vice versa.

Different Control Types:

In terms of forms mode, there are two groups of controls: those that require forms mode to interact with them, and those controls that never require forms mode to interact with them.

Forms mode is required for edit fields, combo boxes, spin controls, list controls, tab controls, menu bars, tree views, and grid cells, For these controls, press ENTER or SPACEBAR to enter forms mode, and ESC or NUMPAD PLUS to exit forms mode.

For buttons and check boxes, use ENTER or SPACEBAR to activate the button at the Virtual Cursor. Users interact with these controls simply by pressing ENTER or SPACEBAR; so forms mode is unnecessary. JAWS auto forms mode causes JAWS to leave forms mode when it encounters these control types because they are just as usable without forms mode.

For combo boxes only, ALT+DOWN ARROW causes JAWS to enter forms mode an drop down the list of combo box items. ALT+UP ARROW closes the list of combo box items and causes JAWS to exit forms mode.

Lastly, JAWS auto forms mode behavior for radio buttons is a little different from its behavior with other types of controls. That’s because unlike other controls, it’s possible to interact with radio buttons in both forms mode and with the Virtual Cursor. When navigating with the TAB key, JAWS will stay in forms mode if forms mode is already on, and it will not enter forms mode if forms mode is off. Users can press SPACEBAR to choose a specific radio button when using the Virtual Cursor, and pressing the arrow keys will not change the value of the radio button group. Users can also press ENTER to activate forms mode, and subsequent presses of the UP and DOWN ARROW keys will change the value of the radio button group. The following table contains the expected behavior for radio buttons with auto forms mode.

Keys	In Forms Mode	In Virtual Cursor
ARROWS	Changes radio button in group. Does not exit forms mode.	Does not change radio button in group. Does not enter forms mode.
TABS	Does not exit forms mode.	Does not enter forms mode.
SPACEBAR	n/a	Selects the radio button at the cursor. Does not enter forms mode.
ENTER	n/a	Selects the radio button at the cursor. Enters forms mode.

ARIA Roles

The ARIA roles listed below are common control types that should be familiar to Windows users. These are controls that have been supported by JAWS in the Windows operating system for many years. Therefore, the expected behavior for each control type is not presented in detail. Sufficed to say, in forms mode, JAWS should behave comparably between controls presented on Web pages and their counterparts in standard desktop applications. Likewise, most of these control types have existed in HTML for a long time, and JAWS has supported those controls using its Virtual Cursor. In Virtual Cursor mode, JAWS behavior between a combo box created with standard HTML for example should be no different from JAWS behavior with a properly constructed JavaScript-based combo box and ARIA markup. In a few cases, ARIA markup allows for control types which were not available before in HTML. In these cases, notes may appear next to the roles in question.

An important thing to understand about ARIA roles is that several roles may be combined to form the framework of one control on a page. For example, an editable grid consists of an object with the role of “grid”, having children with the role of “row”, having children with the role of “rowheader”, “columnheader”, or “gridcell”. Such controls are composed of expected patterns of roles which are described in the ARIA best practices document. If the construction of these controls is done in a way other than that described by the best practices document, JAWS may not behave as the author intends.

Furthermore, states and roles also relate closely to one another. ARIA roles have a list of valid states provided in the ARIA documentation. And although the specific set of states supported by JAWS is not listed with each role, a reasonable standard of common usage applies to the acceptable states for each role. For example, the state of “aria-required” makes no sense when applied to a graphic. And the state of “aria-readonly” is superfluous when applied to a check box. JAWS attempts to filter out extraneous information for certain control types. So, page Authors should use the ARIA documentation as a guide, and report any discrepancies to Freedom Scientific.

Note: Some supported roles, such as those for landmarks, have been omitted from the below list, but will be discussed later in this document.

The following is a list of roles which JAWS recognizes:

Role	Comments
alert	This role does not appear in either the virtual buffer or forms mode, but its contents are spoken by JAWS when an alert is made visible.
button
checkbox
columnheader
combobox
dialog	This role will be announced only when a child of the dialog gets focus, and will not appear in the virtual buffer.
document	This role may not be explicitly announced by JAWS, but it indicates that the area it occupies is meant to be read as a Web page. This is the default role of the topmost object in a Web page (i.e., the “body” tag).
grid
gridcell
group	Like document, this role may not be explicitly announced by JAWS. However, when it surrounds a group of form controls, JAWS should announce its name and description when entering the group.
heading
img
link
list
listbox
listitem
log	Presently, this role is known to work with JAWS in Firefox only, and it functions as a type of live region.
menu
menubar
menuitem
menuitemradio
option
presentation	This role indicates that a feature of a Web page exists for visual formatting only. Therefore, JAWS ignores objects with this role. (Known to work in Firefox.)
radio
radiogroup
row
rowheader
separator
slider
spinbutton	JAWS announces this role as a “spin box”.
tab
tablist
tabpanel
textbox
toolbar	This role is indicated in the virtual buffer by start and end messages like those that exist for HTML lists.
tooltip	This role is not shown by JAWS in the virtual buffer or in forms mode, but its contents are spoken when it becomes visible.
tree	When in the virtual buffer, JAWS may show only one item of a tree control. This allows the user to navigate past the tree quickly.
treegrid
treeitem

ARIA States

The same principle of reasonable common usage applies to ARIA states as applied above to roles.

Note: Some states, such as those related to drag and drop, have been omitted from the below list, but will be discussed later in this document.

The following is a list of states which JAWS recognizes:

State	Comments
aria-activedescendant	JAWS uses this state to locate the focused items in tree views, list boxes, and other such controls that manage multiple, focusable children.
aria-busy	Although JAWS does not presently use this state, its use is encouraged so that future versions of JAWS can take advantage of it.
aria-checked
aria-describedby	JAWS announces this state for form controls.
aria-disabled	JAWS announces this state for form controls.
aria-expanded	JAWS announces this state when in forms mode in tree controls.
aria-haspopup	JAWS announces this state for menus and buttons that pop up a menu.
aria-hidden
aria-invalid	JAWS announces this state for form controls.
aria-label
aria-labelledby	JAWS announces this state for form controls.
aria-level	JAWS announces the level of tree items when in forms mode.
aria-multiline	JAWS uses this state to identify multiline edit controls.
aria-orientation	JAWS uses this state to determine if a slider is oriented horizontally or vertically.
aria-posinset	JAWS announces this information when in forms mode for trees and lists.
aria-pressed	JAWS announces the pressed state of a toggle button.
aria-readonly	JAWS uses this state to identify edit fields that are navigable with a caret, but whose content cannot be changed.
aria-required	JAWS announces this state for form controls.
aria-selected
aria-setsize	JAWS announces this information when in forms mode for trees and lists.
aria-valuetext

Landmarks

JAWS announces the type and text of ARIA landmarks, and provides navigation to the next and previous landmark on the page using the SEMICOLON and SHIFT+SEMICOLON quick navigation keys. In addition, pressing INSERT+CONTROL+SEMICOLON should bring up a list of landmarks.

JAWS supports the following landmark roles:

• APPLICATION
• ARTICLE
• BANNER
• COMPLEMENTARY
• CONTENTINFO
• DIRECTORY
• Form
• LOG
• MAIN
• NAVIGATION
• NOTE
• REGION
• SEARCH
• STATUS

Live Regions

JAWS supports use of the “aria-live” state and any of its acceptable values: “polite”, “assertive”, “rude”, or “none”. JAWS will also treat regions with the ARIA role of “log” as a live region. In addition, JAWS supports use of the “aria-atomic” state on live regions. JAWS does not support use of the “aria-relevant” state at this time.

Drag and Drop

JAWS supports the ARIA drag-and-drop properties “aria-grabbed” and “aria-dropeffect”. When a Web page author applies these properties to objects on a Web page, JAWS will identify such objects as grabbable, grabbed, or droppable.

The keystroke WINDOWS Key+CTRL+EQUALS opens the ARIA Drag and Drop dialog box, which shows a list of droppable objects on the page. When you select one of these objects, JAWS will move focus to it. If no droppable objects are available, JAWS will announce the message, “No droppable elements were found on the page” instead of opening the dialog box.

Note: JAWS does not implement the drag and drop functionality in the sense that JAWS doesn’t grab or drop objects itself. According to the ARIA specification, that functionality should be provided by the page author. JAWS simply announces to the user that a given element is .

Applications and Documents

Freedom Scientific has carefully considered JAWS behavior when dealing with ARIA applications. Where JAWS deviates from the ARIA specification, it is to provide the best experience for our users. There are two situations: the first is when the role=”application” attribute is placed on the body tag; and the second is when the role of application is placed on a tag within a Web page.

1. In HTML, when the ARIA role attribute on the BODY tag is set to “application”, JAWS will treat a Web page as though it were a traditional stand-alone application. This means that the virtual buffer JAWS typically uses to display Web pages will be turned off, and users will navigate using TAB and other such keystrokes which are normally provided in stand-alone apps to facilitate keyboard access. The Web page will not appear to users as a Web document – text interspersed with graphics, links, etc – but rather as an application consisting of form controls such as edit fields, buttons, lists, and so on. And unlike forms mode, users cannot use the ESC key or the PC Cursor key to leave application mode when the role of “application” is placed on the “body” tag.
2. Note that before reading how JAWS behaves when the ARIA role of “application” is set on an element within a Web page (i.e., as a descendent of the body tag), it is important to understand JAWS auto forms mode.

When JAWS encounters an aria application embedded within a Web page (i.e., the role of “application” is set on a descendent of the body element), JAWS slightly changes the behavior of auto forms mode. These changes only take effect for those form controls that are descendents of the container element with the role of “application”.

Note: JAWS actually only changes the logic which would normally cause it to exit forms mode. The process of entering forms mode remains the same.

Once forms mode is on, JAWS will pass the ARROW keys through to the application, and will not leave forms mode automatically based on an ARROW key. This means that navigation of the application area must be done using the TAB key, and ARROW keys always manipulate the focused control.

If forms mode is on, JAWS will pass the ESC key through to the application, and not exit forms mode.

JAWS will not exit forms mode for controls such as buttons and check boxes where focus events on such controls would normally cause it to do so.

ALT+UP ARROW will not cause JAWS to exit forms mode when positioned on a combo box.

Only pressing the PC Cursor key (NUMPAD PLUS) will cause JAWS to exit forms mode.

The result of this specialized behavior for applications is that the page author now has more control of the navigation and interaction of specified areas of a Web page, and users can still exit forms mode and take advantage of features offered by the Virtual Cursor.