I’m looking into reusing some of chromium’s content_browsertest code to write a new test harness/test suite for the Core-AAM standard. The Core-AAM standardizes the mapping between ARIA roles, attributes, states and events and the platform accessibility API generated by a browser.
The current Core-AAM tests in WPT are difficult to write, difficult to read and difficult to run -- so Joanie had the idea to re-use the chromium `ax_dump_tree` tool, especially after the recent work Alex has done on it, to create a new cross-platform test suite for the standard. Some of the content_browsertest functionality has already surfaced in `ax_dump_tree` and `ax_dump_events`.
I've taken up the task, and here are some technical details if you are curious or want to weigh in! The general plan is:
Write a NodeJs test harness that loads a test file sequentially in all browsers supported on the given platform and runs ax_dump_tree against each browser. The result is compared to an expectations file for the accessibility AP being testedI. I have a prototype of this.
Design tests very similar to chrome's Dump Accessibility Test (content_browsertests) (which test “internal nodes”, where as Core-AAM needs to test “external nodes”). Already, you can write "tree tests" with the ax_dump_tree tool and do some filtering of attributes.
Currently limitations and proposed additions to ax_dump_tree:
ax_dump_tree dumps the entire accessibility tree, and it would be better for us to be able to test a specified node in the tree. I'm currently looking into ways to do this. One idea is to go in the "dump node" chrome_browsertest direction, and filter based on DOM id, and another is to implement something similar to the @MAC-SCRIPT directive.
If you are interested and would like to follow along or advise, I'd appreciate it! Or if you have concerns/ideas on directions to take this test suite in, please share :)
There is Alex's concern, and I'm also don't think I can just use @N0_DUMP", "@NO_DUMP_CHILDREN" and "@...-DENY-NODE", because they all specify what not to dump, and I want to specify what TO dump.
If I don't go the `@...-SCRIPT` route (Alex's preference), I thought I would do something more like the dump node tests, and filter based on `id="test"`. I could maybe create "@...-ONLY-NODE" and specifying an ID, instead of a platform specific property/attribute pair.
Whoops I missed that suggestion, but here is an example of the different tests we would have to write for CORE-AAM using the script directive and using the "node test" method:
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-accessib...@chromium.org.