NoCoffee – Vision Simulator for Chrome

Vision problems are more pervasive than most of us realize. Upwards of 285 million people worldwide are visually impaired. Many more have low or moderate visual difficulties. The number in the U.S. is expected to double by 2020, due to the aging of the baby boomer generation.

NoCoffee is a free extension for Chrome (download link), which can be helpful for understanding the problems faced by people with slight to extreme vision problems, such as:

• Low Acuity:
  Some pages use very small text or click targets. While it’s true that users use built-in browser zoom or assistive technologies like ZoomText, many non-technical users do not know how.

• Low Contrast Sensitivity:
  Many designers use text with very low contrast, e.g. light gray text on white. Incidentally, here are some great tools for analyzing contrast on the web, and my favorite is the Snook Colour Contrast Check.

• Colorblindness:
  Although color use in design is definitely a good thing, it’s important to remember the maxim “do not rely on color alone”, as 7-10% of males have some form of colorblindness. Chris Campbell has a great article describing color-related design problems and solutions.

• Other: Visual snow, glare and ghosting:
• Obstructed visual field:
  Obstructed visual field: floaters, obstruction to one side (retinal detachment or hemanopia), obstructed central vision (glaucoma), spotty vision (diabetic retinopathy) or obstructed peripheral vision (retinitis pigmentosa or macular degeneration). Note: the simulations of partial visual fields cannot follow your eye gaze as they would in the real world.

To use NoCoffee, download and install it from the Chrome store, and then click on the extension icon in the Chrome toolbar.

Limitations:

• The simulations are not medically/scientifically accurate.
• The simulations of partial visual fields cannot follow your eyes.
• Settings are not linked to statistical probabilities, so it’s difficult to know how likely it is that NoCoffee is showing you something seen by many users. Still, the tool is helpful to get (or give) an idea of many types of vision problems.
• Currently only Google Chrome is supported (at least until more browsers fill in their CSS3 support, specifically CSS3 filters).

Inspired by the Chrometric browser, visionsimulations.com and new capabilities in CSS3.

I’d be happy to post the source code if anyone would like to port it or improve it.

As always, feedback appreciated!

Advertisement

Simulating low visual acuity

UPDATE: I’ve created a Chrome extension called NoCoffee that implements simulations for a number of vision problems.

I’ve been searching for something to simulate surfing with blurry vision. While blur is not a scientific representation of most visual disabilities, it does help us get an idea. Simulating vision loss while designing pages is highly useful — the number of people with visual disabilities is already high and expected to double by year 2020 (U.S. statistics).

We do have the Chrometric browser, which does a very good job simulating color perception issues. Unfortunately, Chrometric has some downsides. For one, the blur effect it provides is not enough to simulate anything except very minor difficulty seeing. Another problem is that it requires a lot of steps to download and get installed, and finally you are left with a separate browser app. It would be better to just use bookmarklets or a browser extension.

Today I found CSS filter. By setting the filter style to ‘blur([value]px)’ on document.body we can cause blurriness in a webpage. Counterintuitively, setting blur to 0px still causes some blur, so you have to remove the style in order to go back to pure clarity. Note: for now we have to use -webkit-filter, and this is only supported in WebKit-based browsers.

In any case, I’ve used CSS filter to create a bookmarklet that lets your blur a web page.

Or, just create a bookmark with the following text for the URL:

javascript:(function()%7Bwindow.checkBlurKey%3Dfunction(evt)%7Bwindow.blurLevel%3D(window.blurLevel%7C%7C0)%3Bwindow.blurLevel-%3D((evt.charCode%3D%3D91%26%26window.blurLevel%3E0)%3F1:0)%3Bwindow.blurLevel%2B%3D((evt.charCode%3D%3D93)%3F1:0)%3Bwindow.updateBlur()%3B%7D%3Bwindow.updateBlur%3Dfunction()%7Bvar%20currZoom%3Dwindow.outerWidth/window.innerWidth%3Bvar%20adjustedBlur%3Dwindow.blurLevel/currZoom%3Bdocument.body.style.webkitFilter%3DadjustedBlur%3F%27blur(%27%2BadjustedBlur/2%2B%27px)%27:%27%27%3B%7D%3Bif(window.blurLevel%3D%3D%3Dundefined)%7Bwindow.addEventListener(%27keypress%27,checkBlurKey)%3BsetInterval(updateBlur,500)%3B%7Dwindow.blurLevel%3DparseInt(prompt(%27Blur%20amount%20(0-20)%3F%20%5Cn%27%2B%27(Press%20%5B%20and%20%5D%20in%20page%20to%20change)%27,window.blurLevel))%3Bwindow.updateBlur()%3B%7D)()%3B

When you open it in a WebKit-based browser (Chrome, Safari, etc.), you can set the level of blur for the current page to 0-20. Pressing [ or ] changes the zoom level. The blur level is also divided by the current zoom level — this is so that zooming up makes the content clearer, just as it would for a person with blurry vision.

Improvements I’d like to see:

• More browser support: For now, this works only in WebKit-based browsers. I would welcome a version that fixes that.
• More simulations: It should be able to simulate a wide variety of vision issues, such as various kinds of colorblindness, floaters, blocked central vision or blocked peripheral vision. To learn more about different types of visual disabilities, see VisionSimulations.com. I suspect that all these can be simulated via CSS filter, but I haven’t investigated.

Here is the code I used to generate the bookmarklet. It divides the blur level by two — changes smaller than 0.5 don’t seem to do anything).

window.checkBlurKey = function(evt) {
 window.blurLevel = (window.blurLevel || 0);
 window.blurLevel -= ((evt.charCode == 91/*[*/ && window.blurLevel > 0) ? 1: 0);
 window.blurLevel += ((evt.charCode == 93/*]*/) ? 1: 0);
 window.updateBlur();
};
window.updateBlur = function() {
 var currZoom = window.outerWidth / window.innerWidth;
 var adjustedBlur = window.blurLevel / currZoom;
 document.body.style.webkitFilter=
  adjustedBlur? 'blur(' +adjustedBlur / 2 +'px)':'';
};
if (window.blurLevel === undefined) {
 window.addEventListener('keypress', checkBlurKey);
 setInterval(updateBlur, 500); // In case zoom changes
}
window.blurLevel = parseInt(prompt('Blur amount (0-20)? \n' +
 '(Press [ and ] in page to change)', window.blurLevel));
window.updateBlur();

P.S. I could imagine this property could be useful on April 1.

Enjoy!

Why a WAI-ARIA Developer Portal is Important

Making dynamic web content accessible is a huge challenge.

WAI-ARIA is the best available solution today. It’s supported in all major browsers and enables almost any dynamic content to be made accessible — that’s great. Accessibility is really important. But man oh man, understanding WAI-ARIA is not easy for developers, who aren’t always born as accessibility experts.

Here are some of the challenges developers face with WAI-ARIA:

• Implementations are different across browsers and screen readers.
• It’s hard to find up-to-date documentation and examples.
• It’s not clear if the markup is correct. Even if it validates with validator.nu, that doesn’t mean it will actually be accessible.
• Learning what actually works where is near impossible. It requires combing through out-of-date blogs and doing your own testing. There are too many tricky combinations to deal with.

Scary! If I were new to accessibility … let’s not go there. But, the answer is not to give up. The web is dynamic, and accessibility is important. The answer is definitely not  to create a plain version just for users with disabilities. That’s just bad.

Web developers need an ARIA developer portal. And, I’m asking for contributors. The web development community has to solve this information vacuum for itself.

Even requests are useful. Please use the Talk page on the site to provide feedback. Or, join the free-aria mailing list and discuss it there.

Or better yet, jump in and help us organize. We could really use a writer who understands JavaScript. If you don’t know WAI-ARIA then you’re perfect.

And if you have WAI-ARIA expertise, hear my over-the-top plea. Put some of your blog and Twitter energy into a living document! Everything else ages too fast.  Just update one  article or example.  It will pay back many times.

Take a look! And register for an account on MDN 🙂

A couple of noteworthy accessibility items

Frank Hecker has recently blogged about two new Mozilla accessibility projects. Great to hear!

Also, I really need one of the new Firefox 3.5 tag cloud t-shirts.  Imagine a cloud of colorful words describing Firefox 3.5, like “open”, “friendly” and “standards” arranged to fit together. Some words are vertical, some horizontal, it’s quite interesting looking. My favorite word on there is “Accessibility”, always a loud and clear priority for Mozilla, thank you. It’s a beautiful thing.

Frank Hecker, Catalyst for the Web

It’s time to take a moment to thank and congratulate Frank Hecker, winner of the 2009 Catalyst Award, for his work to improve the lives of people with disabilities.

The Catalyst award page describes Frank perfectly:

Catalysts are elements or chemicals that can cause or accelerate reactions but do not, themselves, get used up. They are, in this case, people who make things happen by their presence and by what they do. They don’t necessarily do everything themselves, but they bring out and enable the best in the rest of us. They connect the rest of us, and facilitate our interactions so that we all can do great things. They connect us, and facilitate us so that we all can do great things.

Not only has Frank done a lot for accessibility, he’s behind a lot of the work on the open web, which we all enjoy and appreciate. Frank has helped many individuals live up to their true potential. Please see the 2009 Catalyst Award announcement page for more details on what Frank enabled, and how he did it. This award was an easy choice.

Anything is possible if you don’t care who takes the credit. Thanks again Frank, not only for teaching us that, but for all you’ve done for this community. We could use a few more people like you.

IBM, Open Accessibility and Change

Richard Schwerdtfeger, my mentor and technical lead at IBM, explains why IBM let go of myself and Pete Brunet, and what it says about IBM strategy in open accessibility going forward. Although it was done suddenly, it makes a certain amount of business sense.

To summarize what I’m reading and thinking: IBM realized that our efforts in driving WAI-ARIA and IAccessible2 forward were a success.Things are now at a point where IBM can use these technologies in products without devoting full time employees to drive them. IBM believes browser manufacturers must carry forth any further efforts necessary to make web applications accessible.

What still remains to be done? There is more work in W3C to finalize the WAI-ARIA 1.0 standard, and Rich will still be chairing that effort. There is more work to support WAI-ARIA within various JavaScript toolkits and assistive technologies such as screen readers. However, the biggest missing piece in the infrastructure now are solid, consistent, support across all browsers. Firefox support for WAI-ARIA is strong, although some advanced uses such as complex grids with expandable parts will take time to sort out. In addition, consistent support across other browsers will be elusive for some time. Hint: IE 8 betas need work, but are easily beating WebKit and Opera.

But what’s really needed now is WAI-ARIA support in popular web applications. Killer WAI-ARIA applications will drive the need for better browser support, by putting meaning behind the efforts. One would think that a killer consumer application using Dojo’s Dijit or native WAI-ARIA support would emerge, but I haven’t seen one yet (please correct me if I’m wrong). You will still hear this note of resistance when discussing the need for WAI-ARIA with developers of some browser engines. WAI-ARIA bugs in ATs and browsers are simply more likely to get fixed if real users must switch browsers in order to access their web mail, calendar or web-based office application.

The solid Firefox and AT support, and upcoming IE support, are reason enough for developers to rally behind WAI-ARIA. Web application developers, please, implement WAI-ARIA and push browser manufacturers to fix their bugs. Finally, JavaScript front-end developers — please help contribute WAI-ARIA questions and documentation to the free-aria mailing list and codetalks.org wiki.

So in summary, IBM is right. They really did a lot for the community in developing WAI-ARIA and IAccessible2. A major aspect of this was their support for Pete Brunet and myself. We did a great job and IBM will continue to use the results for accessibility in their products. Now, the community will bring these technologies to the next level — mostly, by embracing them.

I want to end by lauding the work Pete did with IAccessible2. Without IAccessible2, advanced web application accessibility would not be available on Windows. IAccessible2 also allows any desktop application to support full accessibility. Like myself, Pete is obviously considering opportunities — he is brunet at us.ibm.com. And hey Pete … open some champagne. Both Rich’s post and our body of work show the facts. We were profoundly successful.

Goodbye IBM

This came as shock to me today, but I was just laid off from IBM. It was not a result of performance. They tell me it was because ARIA and working with external browser vendors is no longer a priority. There is still the chance to find work for another group in IBM, and I will probably be looking into that.

I have enjoyed working there, especially on Web 2.0 accessibility and Mozilla.

But, perhaps this will be the opening of new opportunities. I’m always optimistic.

Update: Some more thoughts … I’ve never been laid off before. In fact, everyone I ever worked for was more than pleased with my output. I know that people who understood my work in IBM really appreciated it. We certainly rocked the accessibility world!

I’m not too worried right now, and I’m very open to hearing about opportunities. Mostly, I just like doing things that benefit society. It doesn’t have to be accessibility, and probably doesn’t even have to be software. Realistically, it may be difficult to be given a great opportunity to move and shake outside of software, but you never know. I do like the kind of projects that Benetech gets going. I’m fascinated in potential in Obama’s plans for using technology to better utilize the public in decision-making. I’ve had some cool ideas around that in the past, which in fact can be more general and could be quite fun to work on.

And, don’t be too surprised if I stay in accessibility or even if I find some new opportunity to work on accessibility within Big Blue itself.

If you have a challenging opportunity to run by me, please send a note to aaron at moonset.net.

Podcast on ARIA, JAWS, Firefox and Chatzilla

JAWS screen reader manufacturer Freedom Scientific has published their January podcast. In it, Glen Gordon describes the design of WAI-ARIA and how it improves accessibility in Web 2.0 applications.

This is followed by a number of ARIA demonstrations by Jonathan Mosen. Jonathan first shows ARIA-enabled websites with JAWS 10 + Firefox 3.04. He then demonstrates JAWS with Chatzilla, an accessible IRC client. Chatzilla is based on Mozilla’s rendering engine, utilizing XUL for the user interface, HTML for the chat log, and ARIA to enhance accessibility.  To quote Jonathan, “and thanks to all the ARIA they have enabled now in that window, chat works seamlessly with JAWS — very impressive”.

Microsoft listens, and addresses WAI-ARIA concerns

A few months ago, I blogged that Internet Explorer 8 beta 2 was not using standard syntax for WAI-ARIA properties. The syntax actually varied depending on the mode chosen for the page, which was confusing. Sometimes the standard worked, and other times you had to use non-standard camelCase for WAI-ARIA.

Microsoft has listened and is correcting WAI-ARIA property support in IE 8 RC1. Here’s a big thank you. It’s important to have a healthy portion of WAI-ARIA work the same across both browsers. Many look forward to test-driving the WAI-ARIA support in IE 8 final.

Math accessibility continued

After collecting a lot of information about math translation libraries we found a lot of overlapping effort. There are at least 3 major open source math Braille translation projects, each supporting multiple Braille math codes (there are over a dozen types of Braille math worldwide).

This raises many questions. Which open source library should screen readers like NVDA and Orca use for Braille display support? Should they just use liblouisxml, since they already use liblouis for translating ordinary text into Grade 2 contracted Braille? Liblouisxml currently supports MathML but not TeX, so how would TeX be supported? Since that is used in WikiMedia equation images, it seems important. And, perhaps proprietary screen readers can take advantage of some of these libraries as well.

There is potential collaboration here. If you’re interested in working on these problems or in these projects, please join the new free-math mailing list.