-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathindex.html
1129 lines (1083 loc) · 57.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Accessible Technology Test Adapter API</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' async="async" class='remove'></script>
<!-- <script src='respec.js' async="async" class='remove'></script> -->
<script class="remove">
var respecConfig = {
// specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
processVersion: "2005",
includePermalinks: true,
permalinkEdge: true,
permalinkHide: false,
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "atta-api",
// if you wish the publication date to be other than today, set this
// publishDate: "2015-11-30",
// if the specification's copyright date is a range of years, specify
// the start date here:
copyrightStart: "2016",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "2014-08-14",
// previousMaturity: "WD",
// previousDiffURI: "http://www.w3.org/TR/2014/WD-media-accessibility-reqs-20140814/",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://spec-ops.github.io/atta-api/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{
name: "Joanmarie Diggs",
url: 'http://www.igalia.com',
mailto: "[email protected]",
company: "Igalia, S.L.",
companyURI: "http://www.igalia.com"
},
{ name: "Shane McCarron", url: 'https://www.spec-ops.io',
mailto: "[email protected]",
company: "Spec-Ops", companyURL: "https://www.spec-ops.io" }
],
// name of the WG
wg: "Accessibility Platorm Architecture",
// URI of the public WG page
wgURI: "https://www.w3.org/WAI/ARIA/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-apa",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/32212/status",
// Depth for the TOC
maxTocLevel: 3,
// include introduction sections in the ToC
tocIntroductory: true,
doRDFa: 1.1,
preProcess: [ setup ]
};
function setup() {
// add a handler to come in after all the definitions are resolved
//
// New logic: If the reference is within a 'dl' element of
// class 'termlist', and if the target of that reference is
// also within a 'dl' element of class 'termlist', then
// consider it an internal reference and ignore it.
require(["core/pubsubhub"], function(respecEvents) {
"use strict";
var termNames = [] ;
respecEvents.sub('end', function(message) {
if (message === 'core/link-to-dfn') {
$.each(document.querySelectorAll("dfn"), function(i, item) {
var $t = $(item) ;
var titles = $t.getDfnTitles();
var n = $t.makeID("dfn", titles[0]);
if (n) {
termNames[n] = $t.parent() ;
}
});
// all definitions are linked
$("a.internalDFN").each(function () {
var $item = $(this) ;
var t = $item.attr('href');
if ( $item.closest('dl.termlist').length ) {
if ( $(t).closest('dl.termlist').length ) {
// do nothing
return;
}
}
var r = t.replace(/^#/,"") ;
if (termNames[r]) {
delete termNames[r] ;
}
});
// delete any terms that were not referenced.
Object.keys(termNames).forEach(function(term) {
var $p = $("#"+term) ;
if ($p) {
var tList = $p.getDfnTitles();
$p.parent().next().remove();
$p.remove() ;
tList.forEach(function( item ) {
if (respecConfig.definitionMap[item]) {
delete respecConfig.definitionMap[item];
}
});
}
});
}
});
});
};
</script>
</head>
<body>
<section id="abstract">
<p>This document presents an architecture and attendant components that together enable
interaction between the [[Web-Protocol-Tests]] framework, the [[testharness.js]] library that is part of that
framework, and the Accessibility API on any platform. It is loosely based upon work done in the ARIA Working Group
and its ancestor Protocols and Formats Working Group, but takes its inspriation from the way that the various Accessibility
API Mapping specifications provide for a consistent way to expose and interrogate aspects of essentially any window
on any platform.</p>
</section>
<section id="sotd">
<p>This is a very drafty document intended to be a place to capture the definition of the
architecture as it is developed. In particular, the contents of <a
href="#terminology">Terminology</a> are in a state of flux, and the content of
the <a href="#teststatements">Testable Statements</a> is still being refined on
a per-platform basis.</p>
</section>
<section id="introduction">
<h2>Introduction</h2>
<p>Historically, testing of aspects of the web platform that are
outside of the user agent have been very challenging. Such
testing requires specialized test rigs, platform unique
instrumentation, etc. Often the use of such tooling is helpful,
but still does not enable fully automated testing of those aspects
in a way that is portable or scales well. In these situations,
manual testing has been required. Previous testing of the ARIA
Specification(s) and related <a>accessibility api mappings</a>
fell into this category.</p>
<p>This specification defines a mechanism whereby any platform
that supports Web Platform Accessibility and exposes that support
through a platform <a>Accessibility API</a> can be tested
automatically. In addition, it defines a simplified declarative
grammar that can be used to define the tests themselves &emdash;
thereby simplifying the overall task of writing the tests in the
first place.
</p>
<p>This document starts out describing the way testing at the W3C
operates for most of the web platform, then illustrates the way in
which it is extended through the facilities defined herein. After
that it provides specifications for each of the components of the
system and their interactions with one another. Finally, it
discusses some ways in which the system could be extended in the
future to further ease test development and make the testing more
thorough.</p>
</section>
<section>
<h2>Theory of Operation</h2>
<p>In <a>WPT</a> a <dfn>parent window</dfn> controls
the selection of tests, and then opens a
<dfn data-lt='test window'>child window</dfn> to execute the
selected tests. That child window uses a Javascript library to control test
sequencing, reporting, management if windows, etc. For most tests, that model looks
something like this:</p>
<img style="width: 95%; align: center" src="wpt-dialog.svg" alt="Simple WPT Dialog Example">
<p>Through this document and the tools that it defines,
ARIA testing extends this model by connecting the child window to an
<a>ATTA</a> <abbr title="Accessible Technology Test Adapter">ATTA</abbr> through another
Javascript library and a well defined protocol and set of messages. The
diagram below shows this expansion.</p>
<img style="width: 95%; align: center" src="dialog.svg" alt="WPT Dialog with ATTA">
</section>
<section id="teststatements">
<h2>Testable Statements</h2>
<p>A testable statement is a simple assertion about the behavior of a system
that, when examined, should evaluate to true. In the case of ARIA
specifications, the testable statements are maintained in various wikis.
They include this assertion, and also include
supporting information to inform the test system which aspects of the underlying
systems need to be examined to evaluate the assertion.</p>
<p class="note">It is possible that in some environments an ATTA will
not be be available. Consequently, additional properties of the
Testable Statement can help a manual tester understand how to
perform a similar test without ATTA assistance. Examples include
the <code>URL</code> and <code>description</code> properties
mentioned below.</p>
<p>Consider the following example:</p>
<pre class="example">
== Testable Statements for ARIA 1.1 features ==
SpecURL: https://www.w3.org/TR/wai-aria11
=== gridcell ===
==== Description ====
When an element has a role with a value of 'grid', its aria-rowcount
and aria-colcount attributes descibe the dimensions of the grid
represented by that element and its contents.
Reference: #some_id
<pre>
If given
<div role='grid' id='test' aria-rowcount='3' aria-colcount='2'>
<div role='row'>
<span role='gridcell'>
<button>hello</button>
</span>
</div>
</div>
then role: grid, celcount: 2, rowcount: 3
</pre>
</pre>
<p>This example presents a description of the test's purpose, a
reference to the section of the specification that defines the
behavior under test, and an HTML fragment and conditions that should be met.
Beyond this, the testable statement needs to show how these conditions are
evaluated through each defined <a>API mapping</a>. An example of one such would be:</p>
<pre class="example">
|colspan=5|event test:focus
|-
|colspan=5|element test
|-
|rowspan=4|ATK
|property
|role
|is
|ROLE_TABLE
|-
|property
|objectAttributes
|isType
|List
|-
|property
|objectAttributes
|contains
|xml-roles:grid
|-
|property
|interfaces
|contains
|Table
|-
|property
|interface
|contains
|Selection
|-
|colspan=5|attribute test2:aria-selected "true"
</pre>
<p>This is an example of a MediaWiki-style table fragment. In this case it is a
series of rows and columns that describe the various items that the ATK ATTA
will evaluate. The WPT ARIA test generator tool parse tables like this and
generates an HTML file containing a JSON representation of the data structured
in such a way that it can be processed by the <a>ATTA Communication Module</a>.
The JSON for the examples above looks like:</p>
<pre class="example">
{ "title": 'grid',
"reference": 'https://www.w3.org/TR/wai-aria11#some_id',
"description": "When an element has a role with a value of 'grid', its aria-rowcount and aria-colcount attributes descibe the dimensions of the grid represented by that element and its contents.",
"steps": [
{
"type": "event",
"title": "step 1",
"element": "test",
"event": "focus",
},
{
"type": "test",
"title": "step 2",
"element": "test",
"test" : {
"ATK" : [
[
"property"
"role",
"is",
"ROLE_TABLE"
],
[
"property"
"objectAttributes",
"isType",
"List"
],
[
"property"
"objectAttributes",
"contains",
"xml-roles:grid"
],
[
"property"
"objectAttributes",
"contains",
"rowcount:3",
],
[
"property"
"objectAttributes",
"contains",
"colcount:2",
],
[
"property"
"interfaces",
"contains",
"Table"
],
[
"property",
"interface",
"contains",
"Selection"
]
],
....
}
},
{
"type": "attribute",
"title": "step 3",
"element": "test2",
"attribute": "aria-selected",
"value": "true"
}
]
}
</pre>
<p>The system will automatically generate [[WPT]] compatible test
cases that are formatted as defined in this specification. Test
cases can also be written by hand. Examples and a template are
available in the <code>wai-aria/tools</code> directory of the WPT
github repository.</p>
<p class="note">
The architecture of this system allows for multiple "steps" per
test (see <a>Test Steps</a>). The current syntax structure for
Testable Statements does not allow for the expression of
multiple "steps". It is possible that this will be added in the
future.</p>
<p class="note">
In the future, it is possible that that the detailed per-platform
API assertions will be automatically created from a basic
assertion by applying the rules from the <a>Accessibility API Mapping</a>
document associated with each specification. See <a>Future
Plans</a> for more information.
</p>
<section id="S_assertions">
<h3>Assertions</h3>
<p>Each <a>platform accessibility API</a> has unique facilities. The per-platform
API assertion <i>structure</i> is identical, but the contents are necessarily different. The
general structure is:</p>
<dl>
<dt>Test Class</dt>
<dd>The class of thing being tested. Examples include a <i>relation</i>, <i>property</i>, <i>result</i> (of
a method call), or <i>event</i>. As a special case, a Test Class of <code>TBD</code> is a
placeholder that means
the assertions are "to be determined". An ATTA that sees a
Test Class of <code>TBD</code> SHOULD respond with a result of "FAIL" and a message that includes
sufficient detail about the accessibility tree associated with the <code>element</code> in
question that a test developer could review that information and use it to develop the correct
assertions for a given platform.</dd>
<dt>Test Type</dt>
<dd>The <i>type</i> within the <i>Test Class</i>. Examples include <i>role</i>, <i>name</i>,
<i>subrole</i>, etc.</dd>
<dt>Assertion Type</dt>
<dd>A <i>verb</i> that indicates how the assertion should be evaluated. These include
<code>exists</code>,
<code>is</code>,
<code>isNot</code>,
<code>contains</code>,
<code>doesNotContain</code>,
<code>isLT</code>,
<code>isLTE</code>,
<code>isGT</code>,
<code>isGTE</code>,
<code>isType</code>, and
<code>isAny</code>.</dd>
<dt>Value</dt>
<dd>A value (or value list) against which to evaluate using ASSERTION TYPE. If there are
multiple values, they are enclosed in brackets and separated with commas and optional whitespace (e.g., [value1, value2,
value3]). When an Assertion Type of <i>exists</i> is used, legal values are <i>true</i> and <i>false</i>.
<p class='note'>At this time commas embedded in values within a value list are NOT supported.</p>
<p>In most cases, the value is untyped. However, when asserting the "type"
of something via the isType Assertion Type, legal values include:</p>
<dl>
<dt>Undefined</dt>
<dd>The system has no value for the item.</dd>
<dt>Boolean</dt>
<dd>The item is either true or false.</dd>
<dt>Constant</dt>
<dd>The item is represented in the implementation as static reference to
a value (e.g., an element of an <code>enum</code> in C, a
<code>Symbol</code> in Javascript).</dd>
<dt>Number</dt>
<dd>The item is "numeric" in that it is something on which mathematical
operations can be performed. <span class='note'>There is no distinction between Integer and
non-Integer values at this time.</span></dd>
<dt>List</dt>
<dd>The item is an collection (e.g., dictionary, hash, list, array)
in which there are zero or more values represented as an index and a
value associated with that index.
<span class='note'>For these purposes,
whether something is a List or a reference to a List is an
implementation detail. Moreover, while Lists are typically iterable,
whether that iteration has predictable order is also an implementation
detail.</span>
</dd>
<dt>Object</dt>
<dd>The item is an "Accessible Object" - a representation of the
Accessibility properties associated with a component of system (e.g., a
DOM element).</dd>
<dt>String</dt>
<dd>The item is a series of characters in a system-defined encoding.</dd>
</dl>
</dl>
<p class="note" title="Event Tests">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.</p>
<p>The remainder of this section defines the specific contents.</p>
<section id="S_assertions_ATK">
<h4>ATK Assertion Contents</h4>
</section>
<section id="S_assertions_AXAPI">
<h4>AXAPI Assertion Contents</h4>
</section>
<section id="S_assertions_IA2">
<h4>IAccessible2 Assertion Contents</h4>
</section>
<section id="S_assertions_MSAA">
<h4>MSAA Assertion Contents</h4>
</section>
<section id="S_assertions_UIA">
<h4>UIA Assertion Contents</h4>
</section>
</section>
</section>
<section id="S_test_steps">
<h2><dfn>Test Steps</dfn></h2>
<p>A test case is a series of test steps. Each step has a type,
the default for which is "assertions". This section defines each
of the types and how those should be expressed in a test case
file.</p>
<section>
<h3>assertions</h3>
<p>A Simple Test is a test in which the ATTA only needs to interrogate
the state of various Accessible Technology roles, states, properties, methods, or
events on the platform. Each platform has its own collection of these
that are documented in the various <a>Accessibility API Mapping</a>
specifications and the specification of the platform
<a>Accessibility API</a>.</p>
<pre class="hilite">
{
"type": "test",
"title": "busy true",
"element": "test",
"test" : {
"ATK" : [
[
"property",
"interfaces",
"doesNotContain",
"Selection"
],
[
"property",
"states",
"contains",
"STATE_BUSY"
]
]
}
}
</pre>
</section>
<section>
<h3>attribute</h3>
<p>An "attribute" step sets or clears an attribute on an
element.</p>
<pre>
{
"type": "attribute",
"element": "test",
"title": "set attribute aria-selected on element test",
"attribute": "aria-selected",
"value": "true"
}
</pre>
<p>Values enclosed in quotation marks are included verbatim. A value of ""
is reserved to mean the attribute is present but empty. A value of none
(with no surrounding quotation marks) is reserved to mean the attribute is
not present on the element.</p>
</section>
<section>
<h3>event</h3>
<p>An "event" entry is a declarative way to fire an event at a
specific element.</p>
<pre>
{
"type": "event",
"element": "test",
"event": "focus",
"description": "Fire a focus event at ID attribute value of 'test'"
}
</pre>
</section>
<section>
<h3>script</h3>
<p>A "script" step includes javascript code that will be
executed in the context of the test child window.</p>
<pre>
{
"type": "script",
"title": "change busy",
"script": "{ var el = document.getElementById('test'); \
if (el) { el.setAttribute('aria-busy', true); } }"
}
</pre>
</section>
</section>
<section>
<h2><dfn data-lt="atta communication module">ATTAcomm.js - ATTA communication library</dfn></h2>
<p>ATTAcomm.js is a Javascript library that works in conjunction with the WPT
testrunner.js to setup and teardown tests, communicate with the ATTA, perform
local actions within a test window, and report the results of the testing to WPT.
The library has a constructor that returns the object and also performs the
testing if there is an ATTA available.</p>
<pre class="idl">
interface ATTAcomm {
attribute testDefinition theTest;
} ;
dictionary testDefinition {
required DOMString title;
required sequence<testStep> steps;
};
dictionary testStep {
DOMString type = "test";
required DOMString title;
required DOMString element;
FrozenArray<APImap> test;
};
dictionary APImap {
required APIList APIName;
required FrozenArray<Assertion> tests;
};
dictionary Assertion {
required assertionType type;
required assertionName name;
assertionValue value;
};
enum APIList { "MSAA", "ATK", "IAccessible2", "UIA", "AXAPI" } ;
</pre>
</section>
<section>
<h2>Accessible Technology Test Adapter</h2>
<section>
<h3>Protocol</h3>
<p>The ATTA protocol is a simple command/response protocol relying upon
HTTP. By default, an ATTA SHOULD listen on port 4119 (A11Y). It is NOT
RESTful. Instead, it uses JSON messages and wraps them in a simple
request where the path portion indicates that command. A typical
conversation between the ATTA and the Framework might look like this:</p>
<img style="width: 95%; align: center" src="atta-flow.svg" alt="Communication between Test, Library, and ATTA">
</section>
<section>
<h3>Message Structure</h3>
<p>Queries and responses are all in JSON.</p>
</section>
<section>
<h3>Commands</h3>
<section>
<h4>start</h4>
<p>The start message is designed to ensure that the ATTA is
ready, that it can find the window under test, and also to
help ATTAcomm understand which API and API version is
supported.</p>
<dl>
<dt>test</dt>
<dd>The name of the overall test case</dd>
<dt>url</dt>
<dd>The url the test case was loaded from</dd>
</dl>
<p>The reply for this message takes the form:</p>
<dl>
<dt>status</dt>
<dd>In indication of whether the ATTA could find the window in
which the test will take place given the test name and url. Values are
<code>READY</code> or <code>ERROR</code></dd>
<dt>statusText</dt>
<dd>A message about any error</dd>
<dt>ATTAname</dt>
<dd>The name of the ATTA</dd>
<dt>ATTAversion</dt>
<dd>A version string about the ATTA</dd>
<dt>API</dt>
<dd>The name of the <a>Accessibility API</a> supported by ATTA</dd>
<dt>APIversion</dt>
<dd>A version string about the Accessibility API</dd>
<dt>log</dt>
<dd>optional, ATTA-specific information about the
accessibility tree associated with the window being
evaluated. This SHOULD be preformatted information that
can be embedded by the <a>ATTA Communication Module</a>
in the test page to assist a test developer in developing or
debugging a test.</dd>
</dl>
<pre class="example" title="Example start request">
{
"test": "name of the overall test case",
"url": "url from which the content is loaded"
}
</pre>
<pre class="example" title="Example start response">
{
"status": "READY",
"statusText": "",
"ATTAname": "WPT Sample ATTA",
"ATTAversion": 1,
"API": myAPI,
"APIversion": myAPIversion,
"log": "formatted logging information"
}
</pre>
</section>
<!--
<section>
<h4>input</h4>
<p>The input message is optional. If it is sent, it defines an input activity that the ATTA needs to perform on behalf of the test in order to stimulate some action
required for the next step(s) of the test.</p>
<dl>
<dt>element</dt>
<dd>The id of the element at which the activities are targeted</dd>
<dt>activities</dt>
<dd>A list of activity objects that are to be performed in sequence:
<dl>
<dt>activity</dt>
<dd>An activity name (e.g., keypress, keydown, keyup, click, mousedown, mouseup)</dd>
<dt>key</dt>
<dd>The name of the key (for key activities). Abstract key names are defined in <a href="https://www.w3.org/TR/uievents-key/">UIEVENTS-KEY</a>.</dd>
</dl>
</dl>
<p>The reply for this message takes the form:</p>
<dl>
<dt>status</dt>
<dd>In indication of whether the ATTA could perform the activities requested.
Values are <code>READY</code> or <code>ERROR</code></dd>
<dt>statusText</dt>
<dd>A message about any error</dd>
<dt>log</dt>
<dd>optional, ATTA-specific information about the
activities performed.
This SHOULD be preformatted information that
can be embedded by the <a>ATTA Communication Module</a>
in the test page to assist a test developer in developing or
debugging a test.</dd>
</dl>
<pre class="example" title="Example input request">
{
"element": "test",
"activities": [
{ "activity": "keypress",
"key": "ArrowDown"
},
{ "activity": "click" }
]
}
</pre>
<pre class="example" title="Example input response">
{
"status": "READY",
"statusText": "",
"log": "formatted logging information"
}
</pre>
</section>
-->
<section>
<h4>startlisten</h4>
<p>The startlisten message is optional. If it is sent, it means one or more subtests are going to have assertions that need to be
evaluated against events, and the ATTA is expected to listen for those events.</p>
<dl>
<dt>events</dt>
<dd>A list of event names the ATTA should capture for the duration of this test.</dd>
</dl>
<p>The reply for this message takes the form:</p>
<dl>
<dt>status</dt>
<dd>In indication of whether the ATTA could set up listeners for
the requested events.
Values are <code>READY</code> or <code>ERROR</code></dd>
<dt>statusText</dt>
<dd>A message about any error</dd>
<dt>log</dt>
<dd>optional, ATTA-specific information about the
events being listened for.
This SHOULD be preformatted information that
can be embedded by the <a>ATTA Communication Module</a>
in the test page to assist a test developer in developing or
debugging a test.</dd>
</dl>
<pre class="example" title="Example startlisten request">
{
"events": [ "focused", "expanded", "selected" ]
}
</pre>
<pre class="example" title="Example startlisten response">
{
"status": "READY",
"statusText": "",
"log": "formatted logging information"
}
</pre>
</section>
<section>
<h4>stoplisten</h4>
<p>The stoplisten message is optional. If it is sent, it means the ATTA must stop listening for any events that it has been asked
to previously listen for.</p>
<p>The reply for this message takes the form:</p>
<dl>
<dt>status</dt>
<dd>In indication of whether the ATTA stopped listening.
Values are <code>READY</code> or <code>ERROR</code></dd>
<dt>statusText</dt>
<dd>A message about any error</dd>
<dt>log</dt>
<dd>optional, ATTA-specific information about the operation.
This SHOULD be preformatted information that
can be embedded by the <a>ATTA Communication Module</a>
in the test page to assist a test developer in developing or
debugging a test.</dd>
</dl>
<pre class="example" title="Example stoplisten response">
{
"status": "READY",
"statusText": "",
"log": "formatted logging information"
}
</pre>
</section>
<section>
<h4>test</h4>
<p>The test message contains one or more assertions that the
ATTA is to evaluate against the <a>Accessibility API</a>. For
each assertion in the request, the ATTA is to return
information on the result of checking the assertion.</p>
<dl>
<dt>name</dt>
<dd>The name of the test</dd>
<dt>element</dt>
<dd>The 'id' of an element that will be examined by the
ATTA</dd>
<dt>data</dt>
<dd>A JSON structure containing the a11y data to check. Note that this is an array where each member maps to a nested array of information from a 'row' in the testable statement. The exact structure and values of the information varies by Accessibility API, but in general have a structure like:
<dl>
<dt>class</dt>
<dd>The class of assertion to evaluate (e.g., state, property, relation, result)</dd>
<dt>type</dt>
<dd>The type of item in the class</dd>
<dt>assertion</dt>
<dd>What we are asserting about this class+type</dd>
<dt>values</dt>
<dd>The value or values to evaluate with the
assertion.</dd>
</dl>
</dd>
</dl>
<p>Note that in order to make the comparison of test
results across platforms "apples to apples" similar, the
'rows' in the testable statement will be evaluated and
their results collected into a single result for the
overall 'test statement'. Any failure or other messages
will be included in the result for that overall 'test
statement'.</p>
<p>The reply for this message takes the form:</p>
<dl>
<dt>status</dt>
<dd>In indication of whether the ATTA could evaluate the
assertions or not. Values are <code>OK</code> and
<code>ERROR</code></dd>
<dt>statusText</dt>
<dd>A message about any error</dd>
<dt>log</dt>
<dd>optional, ATTA-specific information about the
acceswsibility tree associated with the element being
evaluated. This SHOULD be preformatted information that
can be embedded by the <a>ATTA Communication Module</a>
in the test page to assist a test developer in developing or
debugging a test.</dd>
<dt>results</dt>
<dd>A list of result objects corresponding to each
array member in <code>data</code> above. The result
objects have the following members:
<dl>
<dt>result</dt>
<dd>one of PASS or FAIL</dd>
<dt>message</dt>
<dd>information that explains a failure (if any). This information is attached to the failure information along with the assertion
that was being evaluated so a tester can help to correct the problem.</dd>
<dt>log</dt>
<dd>optional ATTA-specific information showing
information about the acessibility tree that was
examined when evaluating the assertion. When there is log data returned
it is augmented with the information about the assertion being
examined. Used when debugging or developing tests.</dd>
</dl>
</dd>
</dl>
<pre class="example" title="Example test request">
{
"name": "subtest name",
"element": "id of element to check",
"data": [ [ "thingClass", "thingType", "thingAssertion", "thingValue" ],
[ "thingClass", "thingType", "thingAssertion", "thingValue" ]
]
}
</pre>
<pre class="example" title="Example test response">
{
"status": "OK",
"statusText": "",
"log": "",
"results": [
{ "result": "PASS",
"log": "Logging information about test run"
},
{ "result": "FAIL",
"message": "Some diagnostic about the failure",
"log": "detailed logging"
}
]
}
</pre>
</section>
<section>
<h4>end</h4>
<p>The end message just indicates the current test case is
complete. It has no payload and expects nothing in the
response. The <a>ATTA</a> SHOULD do a complete cleanup of
anything in its environment before it replies to the
message.</p>
</section>
</section>
</section>
<section id="terminology" class="appendix informative">
<h2>Terminology</h2>
<dl class="termlist">
<dt><dfn><abbr title="Accessible Technology Test Adapter">ATTA</abbr></dfn>
<dd>The ATTA is a tool that acts as the interface between the <a>WPT</a>
<a>child window</a> and the <a>platform accessibility API</a>. It
interprets requirements defined in <a>testable statements</a> and
evaluates them against the characteristics of the <a>child window</a> to
help evaluate the conformance of the <a>platform accessibility API</a> to
the requirements in related W3C Recommendations.</dd>
<dt><dfn><abbr title="Web Platform Tests">WPT</abbr></dfn></dt>
<dd>The collection of tests and tools that the W3C relies upon to exercise
the Web Platform (where that is the collection of technologies that
comprise the World Wide Web).</dd>
<dt><dfn data-lt="testable statement|testable statements">Testable
Statement</dfn></dt>
<dd>A simple (hopefully atomic) definition about the behavior of some
component. In the context of this system, a testable statement includes
information about what behaviors should or should not be attached to an
element with a unique ID within the <a>child window</a>.</dd>
<dt><dfn data-lt="platform accessibility api|accessibility api|accessibility apis">Accessibility <abbr title="Application Programming Interface">API</abbr></dfn></dt>
<dd>
<p>Operating systems and other platforms provide a set of interfaces that expose information about <a class="termref" data-lt="object">objects</a> and <a class="termref" data-lt="event">events</a> to <a>assistive technologies</a>. Assistive technologies use these interfaces to get information about and interact with those <a class="termref" data-lt="widget">widgets</a>. Examples of accessibility APIs are <a href="https://msdn.microsoft.com/en-us/library/ms697270(VS.85).aspx">Microsoft Active Accessibility</a> [[MSAA]], <a href="https://msdn.microsoft.com/en-us/library/ee684013%28VS.85%29.aspx">Microsoft User Interface Automation</a> [[UI-AUTOMATION]], <abbr title="Microsoft Active Accessibility">MSAA</abbr> with <cite><a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898(v=vs.85).aspx"><abbr title="User Interface Automation">UIA</abbr> Express</a></cite> [[UIA-EXPRESS]], the
<a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html">Mac <abbr title="OS Ten">OS X</abbr> Accessibility Protocol</a> [[AXAPI]], the <cite><a href="https://developer.gnome.org/atk/unstable/">Linux/Unix Accessibility Toolkit</a></cite> [[ATK]] and <cite><a href="https://developer.gnome.org/libatspi/stable/">Assistive Technology Service Provider Interface</a></cite> [[AT-SPI]], and <a href="http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2">IAccessible2</a> [[IAccessible2]].</p>
</dd>
<dt><dfn data-lt="api mappings|api mapping|accessibility api mappings">Accessibility <abbr>API</abbr> Mapping</dfn></dt>
<dd>A specification that defines the relationship between ARIA
roles, properties, states, and events to their corresponding
aspects of a specific platform's implementation.</dd>
<dt><dfn>Accessibility Subtree</dfn></dt>
<dd>
<p>An <a>accessible object</a> in the <a>accessibility tree</a> and its descendants in that tree. It does not include objects which have relationships other than parent-child in that tree. For example, it does not include objects linked via <pref>aria-flowto</pref> unless those objects are also descendants in the <a>accessibility tree</a>.</p>
</dd>
<dt><dfn>Accessibility Tree</dfn></dt>
<dd>
<p>Tree of <a class="termref" data-lt="accessible object">accessible objects</a> that represents the structure of the user interface (UI). Each node in the accessibility tree represents an element in the <abbr title="user interface">UI</abbr> as exposed through the <a>accessibility <abbr title="Application Programming Interface">API</abbr></a>; for example, a push button, a check box, or container.</p>
</dd>
<dt><dfn>Accessible Description</dfn></dt>
<dd>
<p>An accessible description provides additional information, related to an interface element, that complements the <a>accessible name</a>. The accessible description might or might not be visually perceivable. </p>
</dd>
<dt><dfn data-lt="accessible names">Accessible Name</dfn></dt>
<dd>
<p>The accessible name is the name of a user interface element. Each platform <a>accessibility <abbr title="application programming interface">API</abbr></a> provides the accessible name property. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element. See related <a>accessible description</a>.</p>
<p>A simple use for the accessible name property may be illustrated by an "OK" button. The text "OK" is the accessible name. When the button receives focus, assistive technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button". The order of concatenation and specifics of the role description (e.g., "button", "push-button", "clickable button") are determined by platform <a class="termref" data-lt="accessibility api">accessibility API</a>s or <a>assistive technologies</a>.</p>
</dd>
<dt><dfn data-lt="accessible objects">Accessible object</dfn></dt>
<dd>
<p>A <a>node</a> in the <a>accessibility tree</a> of a platform <a>accessibility <abbr title="application programming interface">API</abbr></a>. Accessible objects expose various <a class="termref" data-lt="state">states</a>, <a class="termref" data-lt="property">properties</a>, and <a class="termref" data-lt="event">events</a> for use by <a>assistive technologies</a>. In the context of markup languages (e.g., HTML and SVG) in general, and of WAI-ARIA in particular, markup <a class="termref" data-lt="element">elements</a> and their <a class="termref" data-lt="attribute">attributes</a> are represented as accessible objects. </p>
</dd>
<dt><dfn>Activation behavior</dfn></dt>
<dd>
<p>The action taken when an <a>event</a>, typically initiated by users through an input device, causes an element to fulfill a defined role. The role may be defined for that element by the host language, or by author-defined variables, or both. The role for any given element may be a generic action, or may be unique to that element. For example, the activation behavior of an <abbr title="Hypertext Markup Language">HTML</abbr> or <abbr title="Scalable Vector Graphics">SVG</abbr> <code><a></code> element shall be to cause the user agent to traverse the link specified in the <code>href</code> attribute, with the further optional parameter of specifying the browsing context for the traversal (such as the current window or tab, a named window, or a new window); the activation behavior of an <abbr title="Hypertext Markup Language">HTML</abbr> <code><input></code> element with the <code>type</code> attribute value <code>submit</code> shall be to send the values of the form elements to an author-defined <abbr title="Internationalized Resource Identifiers">IRI</abbr> by the author-defined <abbr title="Hypertext Transfer Protocol">HTTP</abbr> method.</p>
</dd>
<dt><dfn data-lt="assistive technology">Assistive Technologies</dfn></dt>
<dd><p>Hardware and/or software that:</p>
<ul>
<li>relies on services provided by a <a>user agent</a> to retrieve and render Web content </li>
<li>works with a user agent or web content itself through the use of APIs, and</li>
<li>provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities</li>
</ul>
<p>This definition may differ from that used in other documents.</p>
<p>Examples of assistive technologies that are important in the context
of this document include the following:</p>
<ul>
<li>screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;</li>
<li>screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;</li>
<li>text-to-speech software, which is used to convert text into synthetic speech;</li>
<li>speech recognition software, which is used to allow spoken control and dictation;</li>
<li>alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;</li>
<li>alternate pointing devices, which are used to simulate mouse pointing and clicking.</li>
</ul>
</dd>
<dt><dfn data-lt="attributes">Attribute</dfn></dt>
<dd>
<p>In this specification, attribute is used as it is in markup languages. Attributes are structural features added to <a class="termref" href="#dfn-element">elements</a> to provide information about the <a class="termref" href="#dfn-state">states</a> and <a class="termref" href="#dfn-property">properties</a> of the <a class="termref" href="#dfn-object">object</a> represented by the element.</p>
</dd>
<dt><dfn data-lt="classes">Class</dfn></dt>
<dd>
<p>A set of instance <a class="termref" href="#dfn-object">objects</a> that share similar characteristics.</p>
</dd>
<dt><dfn data-lt="deprecate|deprecation">Deprecated</dfn></dt>
<dd>
<p>A deprecated <a class="termref" href="#dfn-role">role</a>, <a class="termref" href="#dfn-state">state</a>, or <a class="termref" href="#dfn-property">property</a> is one which has been outdated by newer constructs or changed circumstances, and which may be removed in future versions of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> specification. <a class="termref" data-lt="user agent">User agents</a> are encouraged to continue to support items identified as deprecated for backward compatibility. For more information, see <a href="#deprecated">Deprecated Requirements</a> in the Conformance section.</p>
</dd>
<dt><dfn>Desktop focus event</dfn></dt>
<dd>
<p>Event from/to the host operating system via the accessibility <abbr title="application programming interface">API</abbr>, notifying of a change of input focus.</p>
</dd>
<dt><dfn data-lt="elements|element's">Element</dfn></dt>
<dd>
<p>In this specification, element is used as it is in markup languages. Elements are the structural elements in markup language that contains the data profile for <a class="termref" data-lt="object">objects</a>.</p>
</dd>
<dt><dfn data-lt="events">Event</dfn></dt>
<dd>
<p>A programmatic message used to communicate discrete changes in the <a>state</a> of an <a>object</a> to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.</p>
</dd>
<dt><dfn>Expose</dfn></dt>
<dd>
<p>Translated to platform-specific <a class="termref" data-lt="accessibility api">accessibility APIs</a> as defined in the <cite><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> User Agent Implementation Guide.</cite> [[WAI-ARIA-IMPLEMENTATION]]</p>
</dd>
<dt><dfn data-lt="graphical documents">Graphical Document</dfn></dt>
<dd>
<p>A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).</p>
</dd>
<dt><dfn>Hidden</dfn></dt>
<dd>
<p>Indicates that the <a>element</a> is not visible, <a>perceivable</a>, or interactive to <em>any</em> user. An element is considered <em>hidden</em> if it or any one of its ancestor elements is not rendered or is explicitly hidden.</p>