ARIA 1.2 Testable Statements

ARIA 1.2 Testing Wiki Pages

Introduction

Assumptions about Testing ARIA 1.2 Features

For new, non-global properties: We need a test for each role that supports that new property.
- Rationale: We cannot assume that user agents use our taxonomy programmatically in their implementations. Thus for non-global properties, there's an excellent chance t we won't get the implementation "for free"; instead, user agents will likely have to add new support on a per-role basis.
For new, global properties: We just need to test one representative role, plus any role for which there is special/custom behavior related to that property.
- Rationale: Global properties without role-specific special/custom behavior is something we can assume user agents will not be implementing on a per-role basis. Thus because the implementation itself is likely to be global, exhaustive testing is not needed.
For new roles: We just need to test non-global properties supported on those roles.
- Rationale: See rationales 1 and 2 above.

Overview

The following testable statements are the tests needed for exiting ARIA 1.2 Candidate Recommendation
These statements are based on ARIA 1.2 Change Log
The wiki format for test cases is based on Fred Esch's work on SVG test cases
That format has been extended to allow for improved readability and increased ability to ensure test automation works seamlessly across all platforms that support it. The format in use in this file is:

=== UNIQUE NAME FOR THE TEST ===
* List documenting purpose of test

; // name of thing(s) being tested (can be used as name of test case)
<pre>
if given
  <element>some HTML fragment
  </element>
then CONDITIONS FOR TEST
</pre>
{| class="wikitable"
#### OPTIONAL
|-
|colspan=5|element ELEMENT_ID
|-
|colspan=5|attribute ELEMENT_ID:ATTR_NAME set "value"
|-
|colspan=5|attribute ELEMENT_ID:ATTR_OTHER_NAME clear
####
|-
|rowspan=NUMBER OF CONDITIONS|NAME OF API
|TEST CLASS
|TEST TYPE
|ASSERTION TYPE
|VALUE
... etc...
|}

"NAME OF API" is one of (MSAA, AXAPI, UIA, IAccessible2, or ATK)
"TEST CLASS" is one of (property, result, event, or TBD (to be determined))
"TEST TYPE" is dependent upon "TEST CLASS"
- PROPERTY then one of (name, description, childCount, role, subrole, parentID, relations, states, controlPatterns, interfaces, or objectAttributes)
- RESULT then an expression or method call (e.g., atk_selection_clear_selection())
- EVENT @@@TODO@@@
ASSERTION TYPE is one of (is, isNot, contains, doesNotContain, isType, isAny)
VALUE is the value or values to evaluate using ASSERTION TYPE. If multiple values, enclose in brackets and separate with commas (e.g. [value1, value2, value3])

The TEST CLASS of event is special in that the each occurrence of the TEST TYPE type establishes a context for the next event rows in the table. Each subsequent event row is an assertion about an event of the type referenced in that first special row. That context continues until the end of the table, until a row that is NOT an event assertion, or until a row that is an event but with a TEST TYPE of type.

There can be more than one element being tested in an assertion table. When there is, each group of assertions should begin with a row specifying that ID.

NOTE: All of these things are extensible. The list of PROPERTY values, for example, will surely need to be expanded over time as additional platform ATTAs are implemented.

Example (Dont Generate)

When the selected item changes in a listbox, ATK/AT-SPI2 expects the following:

object:selection-changed emitted by the listbox
object:state-changed:selected, with detail1 = 0 emitted by the item(s) which became unselected
object:state-changed:selected, with detail1 = 1 emitted by the item(s) which became selected

To test this, we could use the following markup and table:

  <div id="test" role="listbox" tabindex="0" aria-activedescendant="item1" >
    <div id="item1" role="option" aria-selected="true">First</div>
    <div id="item2" role="option" aria-selected="false">Second</div>
  </div>

attribute item1:aria-selected "false"
attribute item2:aria-selected "true"
attribute item2:aria-hidden none
element test
ATK	event	type	is	object:selection-changed
element item1
ATK	property	states	doesNotContain	STATE_SELECTED
	event	type	is	object:state-changed:selected
	event	detail1	is	0
element item2
ATK	property	states	contains	STATE_SELECTED
	event	type	is	object:state-changed:selected
	event	detail1	is	1

The first two rows in the above table specify that both ARIA properties should be changed before proceeding with the test assertions, i.e. as a single step. The rows that follow identify the element being tested, any expected changes to accessible properties, and the expected accessibility events that element should emit.