ChromeShades Help

ChromeShades is a tool to help you make your site more accessible to blind users.

Simply install the Chrome extension and everything in your browser is reformatted in a way that simulates how a blind user would perceive the page with a screen reader. Interactive web apps remain functional, so you can test actual workflows for accessibility problems.

ChromeShades is not a substitute for testing with screen readers, but it can be a faster and easier way to identify many issues up-front before you ever open a screen reader or send it to a tester.

The best way to understand what ChromeShades does is to see just how ChromeShades transforms your HTML, with the examples below.

Table of Contents


Using ChromeShades

The current version of ChromeShades doesn't have any controls. When it's running, any new page you reload will be transformed. To turn it off, visit the Chrome extensions page (press the Wrench menu -> Tools -> Extensions, or visit chrome://extensions/) and click on the Disable link next to ChromeShades - then reload any pages that had ChromeShades applied.

A future version may make it much easier to toggle on and off for an individual page.

Example 1: Most styling is removed.

Blind users can't perceive any of the fonts, styles, colors, and positional layout in your page. ChromeShades removes all of this for you, so you can determine if the unstyled content is still logically organized and easy to understand. In this example, the ChromeShades representation makes it clear that the text at the top won't be perceived as a big, bright heading, and the "my favorite" annotation won't appear in the right place next to Chrome.

<div style="font-size: 150%; color: #090;"> Supported Web Browsers: </div> <ul style="height: 6em;"> <li>Chrome <li>Firefox <li>Internet Explorer <li>Safari <li>Opera </ul> <div style="position: relative; left: 8em; top: -7em; color: #f00;"> <-- My favorite! </div>

Example 2: Semantic markup is preserved.

While specific font, size, and color changes are not preserved, screen readers do announce headings and lists, and may announce semantic tags like <strong> and <em>. Use these whenever possible, and then just style them with CSS to get the look you desire.

In the example below, ChromeShades marks the heading in red to indicate it's a semantic element that screen readers will set apart, and it shows "My favorite" in bold.

<h3 style="color: #090;"> Supported Web Browsers: </h3> <ul> <li>Chrome <strong style="color: #f00;"> <-- My favorite! </strong> <li>Firefox <li>Internet Explorer <li>Safari <li>Opera </ul>

Example 3: Heading structure.

One way that screen reader users navigate a complex document is by its headings. Documents with lots of hierarchically-organized headings are much easier to navigate than documents without such structure.

To make your heading structure more apparent, ChromeShades indents everything in your document by the heading level to make the impact of the heading hierarchy on your document more apparent.

<h1>Search results for "Chromium"</h1> <section> <h2>Results</h2> <h3><a href="#">The Chromium Projects</a></h3> <div>The Chromium projects include Chromium and Chromium OS, the...</div> <h3><a href="#">Dietary Supplement Fact Sheet: Chromium</a></h3> <div>Chromium is a mineral that humans require in trace amounts, ...</div> <h3><a href="#">[ c h r o m i u m B.S.U. ]</a></h3> <div>A fast paced, arcade-style, top-scrolling space shooter for ...</div> </section> <section> <h2>Ads</h2> <h3><a href="#">Chromium Supplements</a></h3> <div>Get Answers You're Looking For.</div> </section>

Example 4: Interactive controls.

ChromeShades helps you make sure that anything that is supposed to be interactive (focusable, clickable) has a proper ARIA role set. In ChromeShades, both a <button> and a <div role="button"> will be formatted the same way, indistinguishably, but a clickable <div> without a role will end up looking like plaintext, so you can tell at a glance that they're not marked up properly.

Controls are always displayed on their own line - this matches the behavior of screen readers, where an interactive control (and usually a link, also) is always a distinct line or a distinct node when the user is browsing the elements on a page.

In addition, all interactive controls are formatted in green, so you can quickly tell them apart from any static content.

<p> <a href="" target="_blank">Real link</a> <span class="mylink" role="link" onclick="openaria()">ARIA link</span> <span class="mylink" onclick="openaria()">Clickable text</span> </p> <p> <button onclick="alert('Hi')">Real button</button> <span class="mybutton" role="button" onclick="alert('Hi')">ARIA button</span> <span class="mybutton" onclick="alert('Hi')">Clickable block</span> </p> <p> <input id="check1" type="checkbox"/> <label for="check1">Real checkbox</label> <span id="check2" class="mycheck" role="checkbox"></span> <label for="check2">ARIA checkbox</label> </p> <p> <input type="radio"/> Real radio <span class="myradio" role="radio"></span> ARIA radio </p>

Example 5: Visibility.

Screen readers do respect display: none and most screen readers respect visibility: hidden, so you should assume anything on your page that's hidden using one of these methods will also be hidden to screen reader users.

On the other hand, something that's hidden by absolute-positioning it offscreen and/or giving it no width or height will still be visible to a screen reader. You can use this to create text that won't appear visually but can be read by a screen reader user.

Finally, to hide something from screen readers, use the attribute aria-hidden="true".

<style> { display: none; } </style> <script> var toggled = false; function toggle() { toggled = !toggled; var regions = document.getElementsByClassName('toggle'); for (var i = 0; i < regions.length; i++) { regions[i].className = toggled? 'toggle on': 'toggle off'; } } </script> <h1>Top 10 movies</h1> <div>Casablanca</div> <div>Raiders of the Lost Ark</div> <div class="toggle off"> <div>The Godfather</div> <div>The Good, the Bad and the Ugly</div> <div>Pulp Fiction</div> <div>Schindler's List</div> <div>12 Angry Men</div> <div>The Godfather: Part II</div> <div>One Flew Over the Cuckoo's Nest</div> <div>The Dark Knight</div> </div> <button class="togglebutton" onclick="toggle()">Show / hide</button> <div aria-hidden="true"> This text will be shown visually but hidden to screen reader users. </div> <div style="position: absolute; left: -9999px; height: 0px;"> This text will only be shown to screen readers. </div>

Example 6: Alt tags and other labels.

Most images should have an alt tag as a description, and ChromeShades will display the contents of the alt tag instead of the image so that you can easily identify unlabeled images and make sure your image labels make sense.

Sometimes an image is for presentational purposes only, and no label is needed. In that case, mark up the image with alt="" and ChromeShades will hide the image entirely so it doesn't look like an unlabeled image. Most screen readers will skip an image explicitly labeled with alt="", but for an image with no alt tag, they may say something like "Image".

Other form controls can be labeled with a <label> tag, or if you want the label to be only for screen reader users, with the aria-label attribute. In addition, when a control has a title attribute, it's used as the tooltip in some browsers, but it's used as the replacement description for some screen readers, so make sure it's a good description of the control.

<p> No alt tag: <img src="chromeshades_48.png"> </p> <p> Alt tag: <img src="chromeshades_48.png" alt="ChromeShades Logo"> </p> <p> Empty alt tag: <img src="chromeshades_48.png" alt=""> </p> <p> <button>Button Text</button> <button title="Title Text (also tooltip)">Button Text</button> <button aria-label="Aria-label Text">Button Text</button> </p> <p> <input id="input1"><label for="input1">Label for Input 1</label> <input aria-label="Aria-label of input2" id="input2"> </p>

Example 7: IFrames.

Many web apps make heavy use of iframes. There's nothing inaccessible about iframes, but to a screen reader user, all of the frames on a page are integrated into a single virtual document. So, it's important that your site is equally easy to navigate across iframe boundaries.

<p> Before iframe </p> <iframe style='height: 6em;' src='colors.html'></iframe> <p> After iframe </p>

Example 8: Tables.

Tables used for layout, instead of to present actual tabular data, will be displayed linearly in ChromeShades. This is to reinforce the idea that the spatial position in the page should never be used to convey information.

<div> Log in to the system here: <table> <tr> <td>Username</td> <td>Password</td> </tr> <tr> <td><input name="username" size=12></td> <td><input name="password" type="password" size=12></td> <td><input type="submit" value="Log in"></td> </tr> </table> </div>

Comparison to other tools.

ChromeShades was inspired by Fangs, a clever, innovative and useful Firefox extension that creates a textual representation of a web page similar to how the page would be read by a modern screen reader.

The major difference between the two is that Fangs parses the current page and generates a separate representation of the screen reader text, while ChromeShades transforms the current page in-place. As a result, you can dynamically interact with a page while ChromeShades is on, but with Fangs you need to interact with the original page and then try to figure out how the screen reader version changes. So ChromeShades is designed to be more useful for modern web apps.

Fangs has been around for many years and it's a more mature product. It goes to great lengths to imitate many of the specific behaviors of JAWS, the most widely used screen reader. For static content, and even for simple dynamic content, Fangs is a fantastic testing tool.


ChromeShades is not a replacement for testing your web site with a real screen reader! It's a tool to help you quickly fix the majority of the easy problems so that when you do actual testing you can focus on workflow efficiency and overcoming any minor screen reader quirks, not basic accessibility problems.

Keep in mind that not all screen readers are the same, and they don't behave the same with different web browsers. Complete testing should include a variety of browsers and screen readers. There are third-party testing labs that will provide this service.

There are also many other aspects of accessibility that ChromeShades does not try to address: for example, websites should be accessible to users with color-blindness and low vision, but ChromeShades does not attempt to help address their needs. Luckily there are other tools and resources available to help with many of these.

Can I just turn turn off page style / disable CSS and get the same effect?

For simple pages, yes - but that probably won't work for most dynamic pages because anything hidden using display or visibility won't function anymore - note that modern screen readers only access what's actually visible on the page, just like any other user. Turning off CSS also won't help you test whether or not titles, labels, and ARIA attributes have been applied correctly.

Credit / License / Bugs / Feedback.

ChromeShades was developed by Dominic Mazzoni and other members of Google's accessibility team. It's part of the google-axs-chrome project on googlecode.

ChromeShades is open-source, released under the terms of the Apache License 2.0.

To report bugs or send feedback, join the axs-chrome-discuss group. Thanks for your interest!