Introduction 

For each example we test the "Expected" results with assistive technologies, for each browser that AT supports WAI-ARIA in. Where a failure occurs we will test the browser for API incorrectness, using tools such as MSAA Inspect. This must be done in order to determine where to file a bug (browser or AT).

There are several purposes for providing this information:

1. Help browser vendors provide correct implementations
2. Help AT vendors provide correct implementations
3. Inform authors as to what actually works reliably

In general we're testing with the latest public releases. However, where things don't work we may test with nightly builds if they are available, in order to show what is already fixed in upcoming releases.

We can add more screen readers if people are willing to step up and provide test results for them.

Tested UA/AT Combinations:

• Dragon 10 with Firefox 3 and IE 8 beta 2
• JAWS 9 & 10 with Firefox 3
• JAWS 9 & 10 with IE beta 2
• NVDA 0.6p2 with Firefox 3
• Orca with Firefox 3
• Window-Eyes 7 with IE 8 beta 2 and Firefox 3
• Voiceover (Leopard) with Safari 4.0.2
• Zoom (Leopard) with Safari 4.0.2, Firefox 3.x and Opera 9.x
• ZoomText 9.1 with Firefox 3 and IE 8 beta 2

Test Case Structure

Test cases are organized as follows:

• Test Case Links
• Test Details
  • Expected AT Behavior
  • Markup
  • Notes
• Results Table

AT	Firefox	IE	Opera	Safari
JAWS 9	-	-	-	-
JAWS 10	-	1. pass 2. fail	-	-
VoiceOver (Leopard)	n/a	n/a	-	fail
Window-Eyes	-	-	-	-
NVDA	-	-	-	-
Zoom (Leopard)	pass	n/a	pass	pass
ZoomText	-	-	-	-
Orca	-	-	-	-

Table Legend

-	no info/test yet
n/a	not applicable (not supported technically)
pass	expected behaviour met
fail	expected behaviour notmet
1. 2.	reference to link example

Note Regarding Dojo/Dijit Test Files

The main purpose of Dojo's Dijit test files are for Dojo developers to exercise and debug the code. As such, they are used to test a variety of features, such as styling, behavior, mouse, and keyboard interactions, to name few. These test files are not specifically for testing ARIA. Still, Dojo's widgets implement ARIA, and the noted test files could be used as an "ARIA test file".

New Tests for Internet Explorer 8 RC1

On this MSDN page the ARIA state/role mapping in IE8 to MSAA Roles can be directly checked. Also, as a clever feature for AT testing, the firing of events (like EVENT_OBJECT_STATECHANGE) can be invoked from the examples. Finally, a list of currently non-mapped ARIA roles is given.

Documenting and Filing Bugs

Review the information on how to file a bug on an ARIA implementation. When documenting an issue, please also list it in the relevant compatibility table below. When possible provide a link to the bug in the database so that its status can be reviewed.

Widget Test Cases

Alert

1. Simple alert
2. Complex Alert
3. Real alert example with aria-required and aria-invalid -- type in a email address without an at sign to test the alert

Expected AT Behavior:

• A screen reader or screen magnifier must speak an alert when it becomes visible.
• A screen magnifier should move the current view to the alert or open a new panel with the alert information
• Optional, but desired: if there are widgets within the alert, their role and any keyboard mnemonic (accesskey) should be spoken. For example, "Options, button, Alt+Shift+T" should be spoken if there is an options button in the alert with Alt+Shift+T as an accesskey.

Markup used:

• role="alert"

Notes:

Results:

• FFD - An interesting thing to note is that, when focus moves to an alert, JAWS loses its place on the page, so that, when the alert disappears, JAWS Virtual Cursor is at the bottom of the page.

Alertdialog

1. Alert Dialog
2. YUI alert dialog (3rd button in this page)

Expected AT Behavior:

• AT should speak the fact that this is an alert, the title and contents of the dialog, then place virtual focus or the real focus on the desired control (like a button).
• Screen magnifier should show the focused button or emulate any other standard behavior found in notification dialogs in Windows or respective operating systems.

Markup used:

• role="alert"
• aria-labeledby

Notes:

In the UIUC test example, the 'close' button cannot recieve focus.

Results:

Button

Basic Button

1. Button with description
2. dojo nightly build -- lots of other types of buttons there as well.

Expected AT Behavior:

• When focus falls on a button, a screen reader speaks the text of the button plus alternative text of any images within the button (the accessible name of the button). The word "button" is also spoken before or after the accessible name.

Markup used:

Notes:

Results:

Toggle Button

1. Buttons with Icons and without Text -- under construction. Only the bold/italic buttons should be toggle buttons, and they aren't currently toggleable.

Expected AT Behavior:

• Same as basic button above, plus if the state is pressed, AT should indicate that when focus lands on the button and when toggling.
• AT should indicate that it is a toggle button (not a regular button)

Markup used:

• role="button" aria-pressed="false" (or true)

Notes:

Results:

Menu Button

1. dojo nightly build

Expected AT Behavior:

• Screen readers should indicate that this button has an associated menu.
• Screen magnifiers should give indication (if this is not done visually anyway).
• When the button is pressed, the menu should be tracked like any other menu.
• When closing the menu, this should be indicated, and focus should be repeated for the menu button the menu was opened from, or the new focus location if the activated menu item results in that.

Markup used:

Notes:

Results:

Checkbox

Simple Checkbox

Testcases:

1. Set aria-checked="false" for unchecked
2. Both remove or set attribute for unchecked case -- also includes an invalid and required checkbox
3. Hierarchical (newly added test not in test results yet)
4. dojo nightly build

Expected AT Behavior:

• Screen reader should speak the accessible name followed by both the type being checkbox and the state (checked, unchecked). When pressing Space, new state should be announced automatically.

Markup used:

• role="checkbox"
• aria-checked="true" or "false"

Notes:

Need testcase where aria-checked attribute is removed instead of set to false

Results:

Tristate Checkbox

Testcases:

1. Both remove or unset for unchecked case

Expected AT Behavior:

• Screen reader should announce accessible name, role and state. When toggling, new state should be announced (not checked, partially checked, checked).

Markup used:

• role="checkbox"
• aria-checked="true" | "false" | "mixed"

Notes:

Results:

Combobox

Testcases:

1. editable combo 2
2. dojo nightly build (combobox)
3. dojo nightly build (combobox with auto complete)

Expected AT Behavior:

• On focus, screen reader announces the label, the role and the current content of the combobox.
• If the currently selected option is changed the new option should be spoken whether the list is open or closed.
• When the combo box is opened or closed, the new open/closed state should be spoken.

Markup used:

Notes:

Results:

Datepicker

Testcases:

1. Datepicker Example

Expected AT Behavior:

Markup used:

Notes:

Results:

Description

1. Description for groupbox and for button

(AL) Note: the description role is no longer necessary as long as aria-describedby is used; however, this test case is still useful for testing aria-describedby.

Expected AT Behavior:

• When any control is focused inside the groupbox, where focus was previously outside of the groupbox, the description for the entire groupbox should be read by a screen reader.
• When the button is focused, the description of the button should be read after the button's label and role are read by the screen reader.
• Regression testers should test both tabbing forward and back, to make sure that the groupbox description and button description are both read when the button is the first item focused in the groupbox.
• (AL) Alternatively, description are not read automatically but may be accessible from a hotkey. However, if the screen reader does not at least indicate that the description exists, users are likely to miss important information.

Markup used:

• role="description" and aria-describedby

Notes:

Results:

Dialog

1. dojo nightly build- Note that this may not always work
2. Dojo 1.2.3 Release
3. YUI dialogs -- use first two dialog buttons

Expected AT Behavior:

• (MZ) When the dialog opens, the dialog caption (or title), role, and if present, description should be read by screen readers, followed by the focused widget.

Markup used:

Notes:

Results:

Drag and Drop

1. Tic tac toe
2. Slide show

Expected AT Behavior:

• (MZ) Once focusing or arrowing onto the draggable item, screen reader should indicate that item can be an object that can be dragged.
• Once marked for drag and drop, screen reader should announce that this item has been picked up, to distinguish it from others that may be draggable, but are currently not selected for the operation. (AL) I'm not sure if there is a way for the screen reader to know when something has been marked for drag & drop.
• Target nodes where the item can be dropped should be indicated from now on when they receive focus or arrowing onto them with the virtual cursor.
• After drag and drop operation has completed, the new location of the item should be indicated in the virtual buffer representation. If the drag and drop operation caused a menu to open, focus should be tracked in that menu, and the user should be able to complete further interaction via the keyboard as usual.
• Optional but desired: AT should provide simple method to navigate only among the current drop targets.

Markup used:

• aria-grab
• aria-dropeffect

Notes:

• (MZ) There is no equivalent place in any of the known operating systems where draggable items are denoted and targets being indicated as such. All drag and drop operations screen readers traditionally perform within the operating system are hit and miss games that are performed on pixel locations. The above is a suggested series of behaviors I as an end user would want to experience when dealing with ARIA drag and drop, but it has no basis to go on, unlike common controls, for example.

Results:

Grid

See various grid and table examples on the example page for grid variants.

1. Basic Grid -- single select
2. Grid in an application -- single select
3. Illinois Grid Example -- multi select

Expected AT Behavior:

• Screen reader should read column and row headers as the grid is traversed with arrow keys (in forms mode). Screen readers should continue to respect any special table reading modes while the user traverses the grid. For example, while in the grid in forms mode, the user should be able to configure the screen reader to read row headers only.

• JAWS -
  • Virtual Cursor - JAWS treats a grid as if it were an HTML table. All table keys are active. Header behavior is not yet defined.
  • PC Cursor - TBD.

• Window-Eyes
  • Window-Eyes should allow the user to change row/col header reading modes with Ctrl+Shift+H, whether the user is in browse or forms mode.

Markup used:

• role="grid", "gridcell", "rowheader", "columnheader"
• aria-selected, aria-readonly

Notes:

Results:

Treegrid

Examples:

1. Grid with expandable rows

Expected AT Behavior:

• (MZ) Screen readers should announce the current cell or row depending on the default behavior of the AT in other similar situations (e. g. ListViews in Windows, Tree Tables in Linux). If the current row is expandable, screen reader should indicate current state (expanded or collapsed). When the user changes the state, the new state should be spoken immediately. When navigating cells horizontally, the column header should be spoken for each cell.

Markup used:

Notes:

Results:

Group

(no examples yet)

Expected AT Behavior:

• (MZ) When focus first lands on a control inside the group, the name should be spoken. Role may or may not be spoken, screen reader should use same handling as for regular group boxes. If describedby is present, the description should be spoken. Following all that, the focused control should be spoken.
• JAWS -
  • JAWS speaks the group name when focus is placed on a control within the group for the first time.
  • If described by is used on a fieldset (group box), JAWS speaks the description when focus is placed on a control within the group box for the first time.

Markup used:

Notes:

Results:

Img

1. Tiled image

Expected AT Behavior:

• Screen readers should announce the image is a single graphic element along with its associated label, even though it is built from numerous sub-images.

Markup used:

• role="img"

Notes:

If the screen reader does not provide the required behavior, then most likely it is a browser issue, for not respecting "Children Presentational: true" for that role. The accessible hierarchy should contain no children for the img.

Results:

List

Simple List

Expected AT Behavior:

• (MZ) Screen reader should indicate an ARIA list like any other static HTML list. Normally, the number of items contained within the list, and the nesting level (if this is not the outermost list) is announced upon entering. Upon leaving the list, screen reader should give an indication. List items should be read as they appear. As the user navigates, any level changes should be read.

Markup used:

Notes:

Results:

Link

• Basic Link Example
• Link Variants

Expected AT Behavior:

• Screen reader should announce the text or label for the link when it is focused, and the fact that it's a link. ARIA links should be included in the screen reader's List Links function just like ordinary links. Actions in this dialogor list such as "Activate Link" or "Move to Link" should perform the same as they do with regular links.

Markup used:

Notes:

Results:

Listbox and Option

1. dojo nightly build
2. Single select listbox using aria-activedescendant
3. Listbox in an iframe -- this is an important case as it's an example of how a mashup widget can be built (the widget source simply comes from another url, and is tied in using an iframe)
4. YUI "Carousel" listbox -- a more advanced test case

Expected AT Behavior:

• (MZ) Screen reader should announce the label and role of the listbox when it gains focus. If an item is focused within the list, this should be announced next, followed by an indication of this item's position within the list if the screen reader supports this in other lists as well. As focus moves within the list, the screen reader should announce the relevant list items.
• (AL) What about multiple selection? What should happen as the user selects or unselects the current item, does a select all, uses shift+arrow to select, etc.?

Markup used:

• role="listbox", "option" (listitem should only be used with list, which is for static document structures, could someone please make sure our examples follow this rule)
• aria-activedescendant

Notes:

Results:

Menubar and Menu

1. YUI menubar
2. Menubar 1
3. dojo nightly build - popup menu

Expected AT Behavior:

• (MZ) As focus is placed inside a menu or menubar, a screen reader should announce the name (if any) of the menu, the role of the menu, and then read the current menu item.
• (AL) As focus moves within the menu, the screen reader should read the current menuitem.
• (AL) To read a menu item, the screen reader should announce the name. If it is a radio or checkbox menu item, the screen reader should indicate that it's checkable. If it has a submenu (aria-haspopup), the screen reader should indicate that as well.
• (MZ) If a menu is dropped down, the activation of the new menu should be indicated and the focus tracked as it moves through the items.
• (MZ) When the menu is closed, screen reader should indicate this along with the newly focused item.
• (MZ) This may be the menu bar or higher level menu item, or a control that gains focus after the menu was closed after executing a command.
• (MZ) If the menu caused a dialog to open, the dialog context should be given, just as with regular desktop applications.

Markup used:

• role="menubar", role="menu", role="menuitem", role="menuitemcheckbox", role="menuitemradio"
• aria-haspopup="true"
• aria-disabled="true"

Notes:

Results:

Progressbar

1. dojo nightly build
2. Progress bar in "off" live region
3. Progressbar in "assertive" live region

Expected AT Behavior:

• The progress updates should be treated as the screen reader treats any progress updates. The live region markup should not affect how the progress updates are presented.
• (AL) If the screen reader provides a keystroke to announce the current progress, this should work with an ARIA progressbar as well.
• JAWS - JAWS announces the level of progress at each time interval the user selects in JAWS configuration.

Markup used:

• role="progressbar", aria-valuemin, aria-valuenow, aria-valuemax

Notes:

Results:

Radiogroup and Radiobutton

1. Radio Example using CSS Background Images
2. Radio Example using IMG Element
3. Radio Example using aria-activedescendent Property
4. dojo nightly build

Expected AT Behavior:

• On initial focus, the screen reader should announce the label of the radio group and the focused radio button, whether it is selected or not, and its position. As focus moves among the radio buttons, the newly focused radio button's label, state and position should be indicated.

Markup used:

Notes:

Results:

Separator

(no examples yet)

Expected AT Behavior:

• (MZ) The inclusion of this element should be controlled by the screen reader. If it does not indicate separators by default in the operating system, it should honor this for web applications, too. If it does support separators, the same symbolism should be used as for other separators in speech and braille.
• JAWS - TBD.

Markup used:

Notes:

Results:

Slider

Single Slider

1. Slider using in-line images for thumb
2. dojo nightly build
3. Simple slider
4. Pretty slider
5. MINDTROVE Rating Widget
6. Paciello Group slider

Expected AT Behavior:

• The user can navigate to the slider control in all modes. When the user navigates to the slider, the screen reader should announce the label, role and position of the slider.
• When not in a virtual buffer mode, the user can control the slider using keys such as the arrow keys, home and end.
• In virtual buffer mode, the slider exists in the virtual buffer as a single entity, and any images or text that create the sliders appearance are not presented to the user separately. Note: if this does not work, it means the browser is exposing the children instead of respecting the "Children Presentational: true" rule for sliders
• As the user moves the slider, the new value is spoken

Markup used:

• role="slider"
• aria-valuemin, aria-valuenow, aria-valuemax

Notes:

Results:

Multi-Thumb Slider

1. Multi-Thumb Slider Example using inline images for thumbs
2. TPG double slider

Expected AT Behavior:

• JAWS - On focus JAWS announces the role and focus slider position. As the user moves the slider, JAWS announces the new position. The same is true for the second thumb (slider).

Markup used:

Notes:

Results:

Spinner

Spin Button

1. dojo nightly build

Expected AT Behavior:

• (MZ) As focus first lands on the spinner, the screen reader should announce the label, role and current value. As the value is changed, the new value should be announced without repeating label or role.

Markup used:

Notes:

Results:

Tabpanel

1. Simple Tabpanel Example
2. dojo nightly build
3. Another tab panel example
4. Just annother tab panel example
5. YUI Tab Panel example with live regions (using YUI ARIA plug-in).
6. MS IE8 Tab Control example

Expected AT Behavior:

• As focus first lands on the tabs, screen reader announces the label and role of the focused tab item, and whether it is selected.
• As the user presses left and right arrows to change the tabs, the newly focused tab should be announced. When navigating over the currently selected tab, the fact that this is the tab currently being active should be indicated. Note that for tabs with AJAX content, for performance reasons it is optional that they only load the panel only once the user presses Space on the new tab. However, if there is no perf issues they can show the new content simply when the tab gets focus.
• If a new tab is selected via Space, the now selected state should be indicated.
• As the user tabs into the panel, its name, role, and if present, description should be read, followed by the newly focused item.
• Subsequent navigation within the same tab panel should not repeat name, role, or description of the tab panel.

Markup used:

Notes:

Results:

Textbox

1. dojo nightly build

Expected AT Behavior:

• (MZ) When focus first lands on the textbox, its label and role should be indicated. If it also contains content, an indication should be given as for regular textboxes. If the text is automatically selected on focus, this should be indicated.
• Arrow keys should read by character or line as usual.
• (AL) I think we need more here. For example, what about reading the line number if the user requests that info?

Markup used:

Notes:

Results:

Toolbar

1. Example to test ARIA live region and toolbar
2. dojo nightly build

Expected AT Behavior:

• (MZ) Upon initial focus, if the toolbar has a label, screen reader should speak it, followed by the role and the label and role of the current toolbar item.
• As the controls within the toolbar are navigated, the newly focused item should be announced, but the label or role of the toolbar itself should not be repeated.

Markup used:

Notes:

Results:

Tooltip

1. dojo nightly build (tooltip)
2. Simple tooltip -- the tooltip for the link contains the text "Some tooltip"

Expected AT Behavior:

• The tooltip text should be spoken as the user navigates to the widget with the tooltip.
• JAWS - JAWS announces tooltips as they appear. This is dependent on the user's JAWS configuration setting.
• ZoomText - (AL) should ensure that tooltip is visible (not scrolled off) when it appears, and should read it aloud

Markup used:

• role="tooltip"
• aria-describedby
• aria-hidden

Notes:

Results:

Tree

1. dojo nightly build
2. Simple tree -- uses document structure to create hierarchy
3. Tree - Subtrees are encapsulated in treeitems
4. MS IE8 Tree example
5. We need an example that uses aria-level, aria-setsize and aria-posinset to create the hierarchy
6. We also need one that uses aria-owns to create the hierarchy / structure
7. We need one that uses the document to create structure, but uses nested ULs with links inside, and role="presentation"

Expected AT Behavior:

• If navigated to in a screen reader's virtual buffer, the label, role and previously active item of the tree should be read.
• Upon initial focus, the label (if present), and role of the tree itself should be spoken, followed by the current tree item's information.
• When a tree item is read, the screen reader should announce its label, role, state and "Item n of m" positional information. The state includes whether it is expandable and expanded/open.
• As focus is moved, output should be identical to desktop tree widgets like in e.g. Windows Explorer: the tree item should be read as described above, and the level should be announced if it changes.
• As expandable items are opened and closed, the state change should be announced immediately. Optionally, when opening an item, announce the number of sub items that just became available.

Markup used:

• role="tree", "treeitem", "group", "presentation"
• aria-level, aria-setsize, aria-posinset
• aria-expanded

Notes:

Results:

Other Test Cases

Application

1. Simple application with inner document
2. With grid and menubar

Expected AT Behavior:

• If AT supports virtual buffers (probably all Windows screen readers), this should be automatically turned off and the user should interact via the keyboard commands built into the web app.
• It should still be possible to the document/browse/virtual mode back on

Markup used:

• role="application"

Notes:

Results:

Document

• Application with inner document

Expected AT Behavior:

• If a document/browser/virtual reading mode exists, switch to that mode when the document or descendant of the document receives focus
• Document is also treated as a landmark

Markup used:

Notes:

Results:

Landmarks

1. Real world Yahoo! news page with landmarks
2. Illinois Navigation Example
3. Test all landmarks -- very minimal test, not a real world case. The page includes some nested landmarks as well.
4. Juicy Studio -- real world example
5. This site -- another real world example
6. Application with inner document -- the only landmark here is the document, since role="application" as at the root

Expected AT Behavior:

• Screen readers should not include the root accessible object in a page in the list of landmarks
• Screen readers should provide keys to allow users to traverse a list of landmarks or next/prev landmark keys
• Screen readers should support nested landmarks, and multiple landmarks of the same time
• Screen readers should announce the number of landmarks at page load, if they exist on the page
• Screen readers should announce landmarks as users navigate into them (test in all screen reader modes)
• 8 (JG) Are their any landmark role equivalents with HTML headers like role=main~h1??

• JAWS -
  • JAWS announces landmarks as they are encountered in the virtual page.
  • JAWSKey+Ctrl+SemiColon keystroke displays a list of landmarks in the current page.
  • SemiColon and SHift+SemiColon move to Next Landmark and Move to Previous Landmark respectively.

Markup used:

• role = (one of the following): "application", "article", "banner", "complementary", "contentinfo", "directory", "document", "log", "main", "note", "navigation", "region", "search", "status"

Notes:

• Screen readers may wish to provide some landmark-specific conveniences such as automatically starting at "main" when reading the page after page load, or providing a special key to get to the search bar, etc.

Results:

Live Regions

Thank you to Charles Chen for developing the live region examples.

aria-live

1. aria-live="off"
2. aria-live="polite"
3. aria-live="assertive"
4. aria-live="rude"
5. aria-live attribute is missing
6. nested live regions: "assertive" inside "off"
7. MS IE8 Chat Example

Expected AT Behavior:

• JAWS - Announces updates to live regions.

Markup used:

• aria-live

Notes:

Results:

Labelled or Described Live Region

1. aria-labelledby="(id)" aria-live="polite"
2. aria-describedby="(id)" aria-live="polite"

Expected AT Behavior:

• JAWS - Announces updates to live regions.

Markup used:

• aria-live, aria-labelledby, aria-describedby

Notes:

Results:

aria-atomic="true"

1. aria-atomic="true" aria-live="polite"

Expected AT Behavior:

• (AL) For any changed text within an atomic live region, the screen reader should read the entire atomic region.
• (AL) If two or more changes occur before the screen reader gets a chance to read the region, the screen reader should still only read the entire region once.
• (AL) The screen reader should try to concatenate several sequential changes to the same region. If two changes occur almost at the same time (say within .05 seconds for example), the screen reader should make sure to read the entire region only once.

Markup used:

• aria-atomic="true" aria-live="polite"

Notes:

Results:

aria-controls

1. aria-controls -- activating button makes live region change
2. aria-controls and live="polite" changes -- live region with a combination of polite real world changes and button-controlled changes

Expected AT Behavior:

• (AL) Minimal: the screen reader should utilize the politeness level to read changes that occur.
• (AL) Optional but desired: the screen reader should announce updates to a live region where the region changes are the result of a user action. This should even if the user does not set aria-live, and for any value other than aria-live="off". It turns out that using aria-controls is actually not the best way to determine this in all browsers. There is often a way to determine if a change was caused by user input.

Markup used:

• aria-controls, aria-live="polite"

Notes:

Results:

aria-relevant tests

1. aria-relevant="additions" aria-live="polite"
2. aria-relevant="removals" aria-live="polite"
3. aria-relevant="text" aria-live="polite"
4. aria-relevant="all" aria-live="polite"
5. aria-relevant="additions removals text"" aria-live="polite -- should have same behavior as "all"
6. aria-relevant="additions text" aria-live="polite"
7. aria-live="polite" -- aria-relevant is not set, so should act the same as "additions text"

Expected AT Behavior:

• (AL) If aria-relevant is not specified, the screen reader should read only live node additions and text changes
• (AL) If aria-relevant is specified, the screen reader should read all the changes specified by aria-relevant and no more.

Markup used:

• aria-relevant, aria-live="polite"

Notes:

Results:

Live roles: Log + Timer

1. Illinois Log and Timer example
2. CLC Chat -- see the accompanying notes
3. Chatzilla (this is a real app but uses ARIA in an HTML area for chat)

Expected AT Behavior:

• (AL) A screen reader should announce changes inside a log as if they are marked with aria-live="polite", unless the author overrides that with a specific aria-live property on an ancestor of the node that changes.
• (AL) A screen reader should not announce any changes within a timer unless the author overrides that with a specific aria-live property on an ancestor of the change.

Markup used:

• role="log", "timer"
• aria-relevant="additions removals text" (for Chatzilla buddy list)

Notes:

Results:

Live role: Marquee

(no examples yet)

Expected AT Behavior:

• (AL) A screen reader should not announce any changes within a marquee unless the author overrides that with a specific aria-live property on an ancestor of the change.

Markup used:

• role="marquee"

Notes:

Results:

Live role: Status

(no examples yet)

Expected AT Behavior:

• Screen readers often provide a special key to announce the current status. This key should present the contents of any "status" region.
• (AL) A screen reader should announce changes inside a status as if they are marked with aria-live="polite", unless the author overrides that with a specific aria-live property on an ancestor of the node that changes.
• (AL) Strongly preferred, but not currently required: screen readers should read the status when any hotkey associated with status reading is pressed. The known keys are as follows:
  • JAWS: Insert+PageDown
  • Window-Eyes: Ctrl+Shift+Insert
  • System Access To Go: Modifier+PageDown

Markup used:

• role="status"

Notes:

Results:

Live HTML table

1. Live game scores

Expected AT Behavior:

• A screen reader should read changes within the table as well as provide sufficient contextual clues (row and column header info) so that the user can determine what the changes actually mean.

Markup used:

• <table>
• aria-live="polite"

Notes:

Scoreboard notes

Results:

Property-Only Test Cases

These testcases involve ARIA properties used to enhance HTML controls (as opposed to JavaScript-built widgets).

autocomplete

1. Dojo autocomplete

Expected AT Behavior:

• Screen reader should announce the fact that this is a control supporting autocomplete. When suggestions appear, if the AT supports it elsewhere in the operating system (e. g. the Run dialog), suggestions should be supported inside the web app as well.
• Screen magnifiers should indicate AutoCompletes as they do elsewhere in the operating system.
• Optional: for each character typed, screen readers may choose to indicate how many options are remaining in the autocomplete list (if that number has changed). Alternatively, screen readers could make a sound when there is only 1 autocomplete option remaining.

Markup used:

• aria-autocomplete

Notes:

Results:

describedby

1. aria-describedby
2. aria-describedby with display: none
3. aria-describedby with visibility: hidden
4. aria-describedby on img's with role="button"

Expected AT Behavior:

• When the textfield is focused, this description should be spoken after the label "Minutes": "Allows you to specify the number of minutes of inactivity after which your computer should shut down." (AL) The describedby text should be spoken whether it is hidden or not.
• (AL) Alternatively, the description could be accessible from a hotkey. However, if the screen reader does not at least indicate that the description exists, users are likely to miss important information.
• JAWS -
  • If described by is used on a fieldset (group box), JAWS speaks the description when focus is placed on a control within the group box for the first time.
  • If described by is used on a control, JAWS displays the description when the user presses JAWSKey+F1.

Markup used:

• aria-describedby

Notes:

Results:

label

1. aria-label

Expected AT Behavior:

• Screen reader should prefer aria-label information above anything else, including screen text or aria-labelledby.

Markup used:

• aria-label="My something-or-other"

Notes:

• If the screen reader simply uses the accessible name property it should get the correct text to speak, even if several methods (aria-label, aria-labelledby, alt, label for, descendant text, title, etc.) are used.

Results:

labelledby

1. aria-labelledby

Expected AT Behavior:

• Screen reader should prefer this information over screen text or other attributes, excluding aria-label, which supercedes even this one.

Markup used:

• aria-labelledby

Notes:

• If the screen reader simply uses the accessible name property it should get the correct text to speak, even if several methods (aria-label, aria-labelledby, alt, label for, descendant text, title, etc.) are used.

Results:

required

1. aria-required="true"

Expected AT Behavior:

• Screen reader should give an indication (speech, sound, Braille, etc.) that this field is required to be filled.

Markup used:

• aria-required="true"

Notes:

Results: