Accessibility

Here‘s a quick overview of all of the locations in the codebase where you’ll find accessibility tests, and a brief overview of the purpose of all of them.

Layout Tests

This is the primary place where we test accessibility code in Blink. This code should have no platform-specific code. Use this to test anything where there's any interesting web platform logic, or where you need to be able to query things synchronously from the renderer thread to test them.

Don‘t add tests for trivial features like ARIA attributes that we just expose directly to the next layer up. In those cases the Blink tests are trivial and it’s more valuable to test these features at a higher level where we can ensure they actually work.

Note that many of these tests are inherited from WebKit and the coding style has evolved a lot since then. Look for more recent tests as a guide if writing a new one.

DumpAccessibilityTree tests

This is the best way to write both cross-platform and platform-specific tests using only an input HTML file, some magic strings to describe what attributes you're interested in, and one or more expectation files to enable checking whether the resulting accessibility tree is correct or not. In particular, almost no test code is required.

Other content_browsertests

There are many other tests in content/ that relate to accessibility. All of these tests work by launching a full multi-process browser shell, loading a web page in a renderer, then accessing the resulting accessibility tree from the browser process, and running some test from there.

Performance tests

Other locations of accessibility tests:

Even this isn't a complete list. The tests described above cover more than 90% of the accessibility tests, and the remainder are scattered throughout the codebase. Here are a few other locations to check: