Freedom scientific have provided documentation on how the JAWS screen reader supports 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 NUM PAD PLUS to exit Forms Mode.

For buttons and check boxes, use ENTER or SPACEBAR to activate the control at the location of the Virtual Cursor. Users interact with these controls simply by pressing ENTER or SPACEBAR; so forms mode is unnecessary. 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 and 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.

Finally, JAWS Auto Forms Mode behavior for radio buttons is a little different from its behavior with other types of controls. This is because unlike other controls, it is 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 it is already on, and it will not enter Forms Mode if it 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.

Forms Mode and Application Controls

A page author may mark up a Web page using the ARIA role of application.  This role indicates that the page author takes responsibility for handling of the ARROW and ESC keys while the cursor is inside the application region.  The goal is to have JAWS act as though it is inside a standard desktop application. This means that as the user tabs from control to control, JAWS will remain in Forms Mode and pass on all ARROW keys and the ESC key to the Web page.

When inside an application region, JAWS treats any interactive element as a form control. This means that links, checkboxes, radio buttons, and so on are all treated like form controls requiring forms mode. This is in contrast to the manual and auto Forms Mode behaviors described earlier in this document. However, as with Forms Mode in other circumstances, users are still able to exit Forms Mode on application controls by pressing NUM PAD PLUS and they can re-enter Forms Mode either by tabbing to a new control or by pressing ENTER on a control.

The user can identify controls inside an application region because they are all announced as “application controls” by jaws as the user moves through the Web page using TAB or the ARROW keys. For example, when a user encounters a link to google inside an application region, JAWS will announce, “application control link google.” An edit control will be announced as “edit application control.”

Note: there is no distinction between regions of the page marked as applications and the case where the entire Web page is marked as an application. Previous versions of JAWS treated role=”application” on the body of a page differently from role=”application in other parts of a Web page. Note also that if a region is marked as a document and this region is inside an application region, the controls inside the document are treated as ordinary form controls and the standard forms mode behavior applies.

Note for developers

Controls containing text and without a visible caret should not be given a role of application, nor should they be nested inside an element with role of application.

This is because when a user tabs to such an item they will automatically be in a mode in which they can’t use the ARROW keys to review the text with out explicitly leaving application mode, something that isn’t intuitive.

If you have a block of text meeting the above criteria nested within an application, you can give sucha block a role of document or nest it within an element with role of document.

If you expect the user to be able to tab to this area, be sure to give it an appropriate tabindex.

Keys	Application ControlIn Forms Mode	Virtual Cursor inside an application
ARROWS	Passes the key on to the application	Does not enter Forms Mode, simply announces the controls name and type
TAB	Does not exit Forms Mode unless tabbing out of an application	Always enters Forms Mode when landing on a control of any type including links, checkboxes, radio buttons, and buttons  inside an application
SPACEBAR	If on a radio button, checkbox, link or button, the control is activated	Enters Forms Mode on all application controls and activates the control
ENTER	On buttons, this activates the button	Enters Forms Mode and on buttons, activates the button
Navigation Quick Keys	Passes the key through to the Web page	Moves from control to control and does not enter Forms Mode
ESC key	Passes the key through to the Web page	Does nothing

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 the 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. 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 landmark regions, 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.
alertdialog
button	If this control has aria-haspopup=”true” then this is a button menu.  If this control has aria-pressed defined then this is a toggle 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	The aria-level gives the heading level
img
link
list
listbox
listitem
menu
log	Presently, this role is known to work with JAWS in Firefox only, and it functions as a type of live region.  JAWS inserts start and end strings into the virtual buffer to indicate the log.
menubar
menuitem
menuitemcheckbox
menuitemradio
Note	JAWS inserts start and end strings into the virtual buffer to indicate notes.
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.)
progressbar
radio
radiogroup
row
rowheader
separator
Scrollbar	Uses the aria-orientation to determine the type of scroll bar (vertical or horizontal)
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	In Firefox, an element marked as aria-busy is omitted from the accessibility tree for the page.
aria-checked
aria-describedby
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 any control except buttons and combo boxes which pops up a menu. .
aria-hidden
aria-invalid	JAWS announces this state for form controls.
aria-label
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

ARIA Relationships

Using ARIA, a page author can specify relationships among elements. JAWS supports the use of the following relationships:

Relationship	Comments
aria-describedby	JAWS announces this state for form controls. The user can read the describedby text using INSERT+ALT+R.
aria-labelledby	JAWS announces this state for form controls.
Aria-flowto & aria-flowfrom	When the author defines these relationships on elements in a Web page, JAWS will announce that the element has a “flows from” or “flows to” relationship. The user can move to “flows to” elements using the EQUALS Navigation Quick Key and to “flows from” using the SHIFT+EQUALS Navigation Quick Key.
Aria-controls	JAWS will announce that an element has the “controls” relationship to another element on the page. The user can move to the controlled element using INSERT+ALT+M.

Document Regions

JAWS announces the type and text of document regions, and provides navigation to the next and previous document region on the page using the SEMICOLON and SHIFT+SEMICOLON Navigation Quick Keys. In addition, pressing INSERT+CONTROL+SEMICOLON brings up a list of document regions. Note that JAWS treats a number of elements as regions. This includes all the ARIA landmark regions along with several other region types listed below. This table also provides the text JAWS uses in the virtual buffer to indicate the start of a region.

ARIA Role/HTML5 element	Virtual Buffer Text
Role=”application”	<region name> application
Role=”article” element=”article”	<region name> article
Role=”banner”	<region name> banner
Role=”complementary” element=”aside”	<region name> complementary information
Role=”contentinfo”	<region name> content information
Role=”document”	<region name> document
Role=”form”	<region name> form
Role=”main”	<region name> main region
Role=”navigation” element=”nav”	<region name> navigation region
Role=”region” element=”section”	<region name> region
Role=”search”	<region name> search region

Live Regions

JAWS supports use of the “aria-live” attribute and any of its acceptable values: “polite”, “assertive”, or “off”. JAWS will also treat regions with the ARIA role of “log” or “status” as a live region. In addition, JAWS supports use of the “aria-atomic” state on live regions. JAWS does  support use of the “aria-relevant” state in firefox.

Note: Since the “aria-live” value of “rude” is no longer supported by the standard, the use of it is deprecated in JAWS, but still supported.

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 grabbable, grabbed, or droppable.