Re: Question\Request: Save output as text for review

James deBoer - Google

unread,

Jul 9, 2012, 11:55:48 AM7/9/12

to axs-chrom...@googlegroups.com, lacmc...@deloitte.com.au

Hello Lachlan,

Text output is possible today but we would love to hear more about your use case to make this method of testing easier.

In the current version of ChromeVox, there is a 'cvox.ConsoleTts' which echos all utterances to Chrome's dev tools console using window.console.log(). It is disabled by default; to enable it use the "Write debugging TTS output to window.console" command Cvox+B>C.

If you inspect ChromeVox's background page, the console logging is on by default and captures everything sent to the TTS engine.

The code for cvox.ConsoleTts is at http://code.google.com/p/google-axs-chrome/source/browse/trunk/chromevox/chromevox/injected/console_tts.js

Hope this helps,

James.

On Tuesday, July 3, 2012 6:22:15 PM UTC-7, Lachlan wrote:

Hi,

I was wondering whether it was currently possible for ChromeVox to produce a text output of an entire page for review. We're using it to test a number of pages, and to have an outputted script that we can refer to would let us quickly browse for inconsistencies and inaccessible parts.

If this isn't a presently possible, I'd love for it to be a feature. Particularly if the distinction is made in the output (perhaps in terms of colouring or font weight) that shows what is information read directly from the page, what is information added by ChromeVox, and perhaps when an earcon sounds.

Cheers!

Lachlan

Lachlan

unread,

Jul 9, 2012, 9:33:31 PM7/9/12

to axs-chrom...@googlegroups.com, lacmc...@deloitte.com.au

Hi James,

Thanks for the response. I've tested the consoleTTS as you have described, but my question\suggestion takes the idea a little further.

Part of my activities is to test the sites that we produce for compliance against the WCAG 2.0 specification. We want to ensure our sites are usable for those users who are visually impaired. This usually involves turning off my monitor and running over some static pages with just a screen-reader and a pair of headphones.

This works well for me, but it becomes difficult to quickly review changes and share the screen-reader results with others. Since we can consume information faster when reading, a printed document would help us to prepare and ultimately deliver a far higher accessible experience for users with assistive technology.

By 'printed document,' I imagine that the follwing HTML might produce the following formatted text:

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Sample</title>
</head>
<body>
<h1>The Curious Case of Benjamin Button</h1>
<p><em>The Curious Case of Benjamin Button</em> is a 2008 American fantasy drama film directed by David Fincher. The screenplay by Eric Roth and Robin Swicord is loosely based on the 1922 short story of the same name by F. Scott Fitzgerald. The film stars <a href="http://en.wikipedia.org/wiki/Brad_Pitt" title="Wikipedia article on Brad Pitt">Brad Pitt</a> as a man who ages in reverse.</p>
</body>
</html>

Sample, page title.
The Curious Case of Benjamin Button, heading one.
The Curious Case of Benjamin Button is a two thousand and eight American fantasy drama film directed by David Fincher.

The screenplay by Eric Roth and Robin Swicord is loosely based on the nineteen twenty two short story of the same name by F Scott Fitzgerald.

The film stars (hyperlink earcon) Brad Pitt, Wikipedia article on Brad Pitt, link, as a man who ages in reverse.

The intent is for page text, element attributes (like alt or title), or screen-reader specific cues to all be formatted differently to help the reader understand what the user is hearing. This output could be HTML, or even some interchangeable file, like XML, for use in preparing diff reports or to allow for re-formatting. The file may include the original HTML with the outputted text to help convey what is causing what to be said.

This kind of report could then be distributed to other stakeholders to improve the content, correct HTML issues, or passed on to the client to communicate how the site performs for screen-readers.

I realise that screen-readers aren't just reading a book; they allow for a good deal of interaction, and this interaction makes the top-down format of a printed document somewhat impractical for rich-web applications; but for content heavy sites, there is still a lot of value.

Cheers,

Lach

James deBoer - Google

unread,

Jul 16, 2012, 3:21:32 PM7/16/12

to axs-chrom...@googlegroups.com, lacmc...@deloitte.com.au

Lachlan,

This is an excellent idea but isn't something ChromeVox can do today. The best approach may be to use a second extension which interacts with ChromeVox.