robdodson/testing-screen-readers.txt

## testing-screen-readers.txt
Skimmed this thread, so perhaps much of this was mentioned in some form or another before.

I would say testing against screen reader output is subject to all of the same issues that interactive ui testing suffers from.
It doesn't mean we shouldn't do it, but I have not seen it ever work in at least four instances I've seen it tried previously. The tests were always flakey, suffered from constant need for re-baselining, and generally were a net negative.

AOM is still under active development, so seems, at least for now, a poor target.

Chrome does indeed have an accessibility tree. We don't make it especially easy to introspect this tree. The easiest way currently is by using the chrome.automation extension api (which is only available on dev channel). It does have eventing and is what ChromeVox is based on.

Testing against this tree and making strong assertions against it for your given page makes the most sense to me.
You can see how a screen reader uses such a tree in reaction to events by looking at either ChromeVox or NVDA source. ChromeVox is likely more approachable.
	Skimmed this thread, so perhaps much of this was mentioned in some form or another before.

	I would say testing against screen reader output is subject to all of the same issues that interactive ui testing suffers from.
	It doesn't mean we shouldn't do it, but I have not seen it ever work in at least four instances I've seen it tried previously. The tests were always flakey, suffered from constant need for re-baselining, and generally were a net negative.

	AOM is still under active development, so seems, at least for now, a poor target.

	Chrome does indeed have an accessibility tree. We don't make it especially easy to introspect this tree. The easiest way currently is by using the chrome.automation extension api (which is only available on dev channel). It does have eventing and is what ChromeVox is based on.

	Testing against this tree and making strong assertions against it for your given page makes the most sense to me.
	You can see how a screen reader uses such a tree in reaction to events by looking at either ChromeVox or NVDA source. ChromeVox is likely more approachable.