Don't require expectations file for DumpAccessibility tests.

content/test/data/accessibility/readme.txt

Index: content/test/data/accessibility/readme.txt
diff --git a/content/test/data/accessibility/readme.txt b/content/test/data/accessibility/readme.txt
index f8c14331e4b53364329ea54f01507323d5f4e709..6f90c28ef1ed3cd09b7fd173cb9f49b813c773c6 100644
--- a/content/test/data/accessibility/readme.txt
+++ b/content/test/data/accessibility/readme.txt
@@ -1,24 +1,132 @@
-DumpAccessibilityTreeTest Notes
+DumpAccessibilityTreeTest and DumpAccessibilityEventsTest Notes:
+
+Both sets of tests use a similar format for files.
+
+DumpAccessibilityTree tests load an HTML file, wait for it to load, then
+dump the accessibility tree in the "blink" format (the internal data),
+and again in a platform-specific format.
+
+The test output is a compact text representation of the accessibility tree
+for that format, and it should be familiar if you're familiar with the
+accessibility protocol on that platform, but it's not in a standardized
+format - it's just a text dump, meant to be compared to expected output.
+
+The exact output can be filtered so it only dumps the specific attributes
+you care about for a specific test.
+
+One the output has been generated, it compares the output to an expectation
+file in the same directory. If an expectation file for that test for that
+platform is present, it must match exactly or the test fails. If no
+expectation file is present, the test passes. Most tests don't have
+expectations on all platforms.
+
+DumpAccessibilityEvent tests use a similar format but dump events fired after
+the document finishes loading. See more on this below.
+
+Compiling and running the tests:
+ninja -C out/Debug content_browsertests
+out/Debug/content_browsertests --gtest_filter="DumpAccessibility*"
 
 Files used:
 * foo.html -- a file to be tested
-* foo-expected-win.txt -- expected MSAA output
-* foo-expected-mac.txt -- expected Mac accessibility output
+* foo-expected-android.txt -- expected Android AccessibilityNodeInfo output
+* foo-expected-auralinux.txt -- expected Linux ATK output
+* foo-expected-blink.txt -- representation of internal accessibility tree
+* foo-expected-mac.txt -- expected Mac NSAccessibility output
+* foo-expected-win.txt -- expected Win IAccessible/IAccessible2 output
 
 Format for expected files:
 * Blank lines and lines beginning with # are ignored
-* Skipped files: if first line of file begins with #<skip then the entire file is ignored,
-  but listed in the output as skipped
-* Use 4 spaces for indent to show hierarchy
-* MSAA states do not have a prefix, e.g. FOCUSED, not STATE_SYSTEM_FOCUSED
-* All other constants are used exactly as normally named
-* See specific examples (e.g. ul-expected-win.txt) for more details
+* Skipped files: if first line of file begins with #<skip then the
+  test passes. This can be used to indicate desired output with a link
+  to a bug, or as a way to temporarily disable a test during refactoring.
+* Use 2 plus signs for indent to show hierarchy
 
-Compiling and running the tests:
-ninja -C out/Debug content_browsertests
-out/Debug/content_browsertests --gtest_filter="DumpAccessibilityTreeTest*"
+Filters:
+* By default only some attributes of nodes in the accessibility tree, or
+  events fired (when running DumpAccessibilityEvents) are output.
+  This is to keep the tests robust and not prone to failure when unrelated
+  changes affect the accessibility tree in unimportant ways.
+* Filters contained in the HTML file can be used to control what is output.
+  They can appear anywhere but typically they're in an HTML comment block,
+  and must be one per line.
+* Filters are platform-specific:
+    @WIN-
+    @MAC-
+    @BLINK-
+    @ANDROID-
+    @AURALINUX-
+* To dump all attributes while writing or debugging a test, add this filter:
+    @WIN-ALLOW:*
+  (and similarly for other platforms).
+* Once you know what you want to output, you can use filters to match the
+  attributes and attribute values you want included in the output. An
+  ALLOW filter means to include the attribute, and a DENY filter means to
+  exclude it. Filters can contain simple wildcards ('*') only, they're not
+  regular expressions. Examples:
+  - @WIN-ALLOW:name* - this will output the name attribute on Windows
+  - @WIN-ALLOW:name='Foo' - this will only output the name attribute if it
+      exactly matches 'Foo'.
+  - @WIN-DENY:name='X* - this will skip outputting any name that begins with
+      the letter X.
+* By default empty attributes are skipped. To output the value an attribute
+  even if it's empty, use @WIN-ALLOW-EMPTY:name, for example, and similarly
+  for other platforms.
+
+Advanced:
+
+Normally the system waits for the document to finish loading before dumping
+the accessibility tree.
+
+Occasionally you may need to write a test that makes some changes to the
+document before it runs the test. In that case you can use a special
+@WAIT-FOR: directive. It should be in an HTML comment, just like
+@ALLOW-WIN: directives. The WAIT-FOR directive just specifies a text substring
+that should be present in the dump when the document is ready. The system
+will keep blocking until that text appears.
+
+To skip dumping a particular element, make its accessible name equal to
+@NO_DUMP, for example <div aria-label="@NO_DUMP"></div>.
+
+To skip dumping all children of a particular element, make its accessible
+name equal to @NO_CHILDREN_DUMP.
+
+Generating expectations and rebaselining:
+
+If you want to populate the expectation file directly rather than typing it
+or copying-and-pasting it, first make sure the file exists (it can be empty),
+then run the test with the --generate-accessibility-test-expectations
+argument, for example:
+
+  out/Debug/content_browsertests \
+    --generate-accessibility-test-expectations
+    --gtest_filter="DumpAccessibilityTreeTest.AccessibilityA"
+
+This will replace the -expected-*.txt file with the current output. It's
+a great way to rebaseline a bunch of tests after making a change. Please
+manually check the diff, of course!
+
+Adding a new test:
 
 If you are adding a new test file remember to add a corresponding test case in
 content/browser/accessibility/dump_accessibility_events_browsertest.cc
 or
 content/browser/accessibility/dump_accessibility_tree_browsertest.cc
+
+More details on DumpAccessibilityEvents tests:
+
+These tests are similar to DumpAccessibilityTree tests in that they first
+load an HTML document, then dump something, then compare the output to
+an expectation file. The difference is that what's dumped is accessibility
+events that are fired.
+
+To write a test for accessibility events, your document must contain a
+JavaScript function called go(). This function will be called when the document
+is loaded (or when the @WAIT_FOR directive passes), and any subsequent
+events will be dumped. Filters apply to events just like in tree dumps.
+
+After calling go(), the system asks the page to generate a sentinel
+accessibility event - one you're unlikely to generate in your test. It uses
+that event to know when to "stop" dumping events. There isn't currently a
+way to test events that occur after some delay, just ones that happen as
+a direct result of calling go().