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!

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 🙂

The Story of Firefox, for kids

Over the past few years, I’ve been working on and off on a children’s book about Firefox. The project started when my kids wanted to understand what I did at work every day.

The story is a sketch about the evolution of Netscape into Firefox and the power of being open. In terms of historical accuracy, a number of things were simplified in order to keep the messages simple.  For better or worse, it’s already 2500 words. That means it’s not for very young children (I’m thinking 2nd graders and older).

I used readily available imagery of a dragon, a phoenix, Firefox, and Mammon (the god of greed, as I’ve learned). In the story, coders are wizards who cast spells. Naturally, there is also a Chief Lizard Wrangler 🙂  Where possible, I used plot and dialogue, but at times it addresses the reader directly.

The only kid I’ve tested it on so far is my son Oliver (age 8). He loves it, but then he may just be happy that his father spent time to write about a dragon.

If anyone is seriously interested, I’d love to get some help polishing it until it’s good enough to become an actual book.

DotSpots, a cool use of Mozilla technology

DotSpots is launching today. A dot is a “distributed object of thought”, which is like a mini blog post containing rich media, which can be connected to any paragraph in the news. Dots can be authored on the dotspots.com website or via the Firefox extension. They can also developed and polished by teams of collaborators. The secret sauce is distribution: DotSpots will distribute dots to similar paragraphs in articles across the web. There is a video and sign up link on today’s TechCrunch article about DotSpots.

The Firefox extension is central to DotSpots — it really provides the best way to view and create dots in the context of other pages.  The web client is also important and shares a lot of the same features. Of course, the website cannot provide the same benefits as the extension on third party web pages.

The technology is something special. All the major pieces, including the Firefox extension, website and backend, were written in Java.  Google Web Toolkit (GWT) actually compiles our client Java code into compressed JavaScript. This is a great development model.  For one thing, strict type checking definitely helps on a project of this size. It’s also great to be able to stay in the same language on the server. The Eclipse debugger helps out quite a bit, stepping through Java in the server as well as both clients. To communicate with Mozilla components, DotSpots CTO Matt Mastracci developed GWT bindings for XPCOM, which we’ll be open sourcing at some point.

For those who know me as a long time Mozilla contributor, be assured I’m putting that knowledge to good use. And, given the transitional state of the news industry today, it’s an exciting time to be working at Web 2.0 news startup. It will be interesting to watch how the industry progresses.

Cross-browser <video>

My colleague Matt Mastracci from DotSpots has just released support for the HTML 5 <video>tag across browsers. Legacy browsers are also supported. Please see Matt’s post HTML 5 <video> support for older browsers.

Kudos both to Matt and to our employer DotSpots for supporting web standards.

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.

Cygnet in peril

This morning on the way to market in Esslingen, Germany, I discovered a new family of swans, living in a canal that leads through the center of town. The mother and father swans were there with their 3 cygnets, looking something about like this. The ones I saw looked a bit older and larger than those in the photo. My friends had seen the eggs earlier and we think they’re about 2-3 weeks old. I watched as the cygnets practiced diving for food. This was a very tight family, which is to be expected from swans. who are extremely loyal to each other and even mate for life.

Other waterfowl live there as well, including a graceful blue heron.

The little family really struck me and I came back after dinner to see how they were doing. Unfortunately, one of the cygnets was caught in the current of a small, man-made waterfall that drains the canal back to the Neckar river (where it originates from). The slope and current there are navigable for a larger bird, but this cygnet was having real trouble getting back up to the calm, safe part of the river. As the rest of the cygnet’s family watched helplessly, it was simultaneously crying and swimming, desperately trying to rejoin them. And it kept getting so close! The pattern was the same every time: the cygnet would swim hard enough get its feet onto some rough stone at the top of the tiny falls, and the rushing current would take it back where it was.

The cries for help were heart-wrenching but no one could help — the river was fenced off and far below all of us humans observing the drama. The parent swans were a little less helpless, but they had to simultaneously prevent the other two curious siblings from getting caught in the same current. They took turns watching the two siblings and trying to help. Sometimes one would get close enough to touch the cygnet with a beak, but they did not really find a way to push or pull. Neither tried to get behind and push. Sadly, the little swan ran out of energy after 15 minutes or so of trying and crying, and was finally swept away under a bridge into the darkness and eventually to the other side in a fast moving stream. The rest of the family was exhausted from the whole thing and went back to their nesting ground to quit the day.

The cygnet probably survived the swift journey to the Neckar, which will open up to be wide and calm. Despite how afraid it is, I can imagine that the cygnet would be impressed by the immense, still beauty relative to the little urban world it had known. But, I doubt there is any realistic chance for it to survive on its own out there. It may be able to find food, but there will be predators. I only hope Walt Disney is watching from somewhere and will make something wonderful happen. However, nature is probably a little harsher than my imagination of a happy ending. In any case, good luck out there little cygnet, you can make it if you can think like Huckleberry Finn.

How to hack your app to make contenteditable work

The mission? Build a rich text editor widget using contenteditable. Mark Pilgrim described this contenteditable use case as “alive and well on the web” with the warning that it is still “evolving”. Nevertheless, because of various problems we had using an <iframe> our group decided to switch from using designMode to contenteditable.

Note: this article has been updated several times to add up-to-date information as it becomes available. Please add your tips and tricks or any corrections as a comment.

Most of the issues are in the Mozilla editor implementation. IE and WebKit seem to work fine.

Mark’s document is an excellent resource, but now it’s time for a reality check. Here are some problems I had to work around in Firefox 3.5 beta 4:

1. Large caret,  tiny caret, no caret, or two carets on initial focus.
   Workaround: ensure the magic sequence of <p><br/></p> as end-of-document content. Watch everything that happens to make sure it’s never changed, removed or even selected. (Bonus: this is also the fix for several other items in this issues list). Don’t let the caret go after it. If selection ends up extending past it, then just use window.selection.extend to move just before the caret. If the selection had been “collapsed” (just a caret), then set the caret before it (for example set the start before andthen  use window.selection.collapseToEnd to make the selection match).
2. Many execCommand commands, such as bold, do not work after select all, or may have issues when the caret is at the end of content.
 Workaround: the fix for item #1 above also addresses this.
3. The “indent” and “outdent” execCommand will actually indent the entire contenteditable region! 
Workaround: the fix for item #1 above also addresses this.
4. Caret and selection are not restored when you tab or click out of the contenteditable area and later tab back in.
   Workaround: store selection onblur and onmouseout, and restore onfocus. Unfortunately onblur was not enough, because by the time the user has clicked outside of the editable area, the selection has already been forgotten.
5. Double clicking on any HTML Form input in the same document as a contenteditable no longer selects a word.
   Workaround: you have to cleverly set contenteditable=”false” on all area in the document onmousedown in the inputs, and then set them back to “true” as soon as possible.
6. You can paste the editor back into itself etc. This is arguably a feature, not a bug, since contenteditable could be used to develop web authoring tools. However, it’s something to be aware of.
   Workaround: create styles for all children in contenteditable for overflow: hidden !important. You’ll need to think about what styles to override. Remember that users can drag or paste in comment from anywhere.
7. Can’t select text and do operations such as delete if the text includes the beginning or end of the content.
   Workaround: make sure the root editor element is a <div>. Style it how you want (e.g. display: inline), but if it’s a <span> at least, this bug will occur.

My team is still discovering some issues, but they are harder to reproduce. Sometimes the editor becomes unfocusable and it becomes impossible to do further editing. I’m not sure what gets it into this state.

There are over 70 filed contenteditable bugs, and when I am done filing there will be more. The fact that most of these bugs were not yet filed by anyone else yet seems to indicate that contenteditable just isn’t being used much out there. I can see why, and unless the issues get cleaned up, it will stay that way.

The low quality of contenteditable support is unacceptable, especially for something that shipped in a previous version of Firefox. There was plenty of time between Firefox 3 and 3.5, to circle back, gather what was learned, and fix the most important bugs. Yet, I could only find 7 behavior-related contenteditable bugs fixed since June, 2008. That means it’s mostly being allowed to exist as it is.

I would like to make an observation, after 8 years working on the Mozilla code base, and now as a developer of web applications. Please don’t read on if you are allergic to sports analogies, or if you just want to hear how great Mozilla technology is. Quality would be higher if there were one or two fewer  initiatives for the Next Great Leap, and more concentration on just fixing the old boring bugs. There are obviously a lot of big world-changing initiatives going on at Mozilla, and there should be. However, as a community we should be realistic that three point shots are awesome when they go in, but they are easy to miss. Lots of simple plays, like rebounds and layups, are still necessary. Sometimes I think that fundamental bug fixing gets lost in the drive to make news headlines. Honestly, you don’t have to go that far out on the edge to find problems. I don’t believe this is an engineering issue. I think it’s actually Mozilla’s leadership not wanting to pour resources into what seems like an endless problem where great results don’t provide immediate mind-share benefits. However, as we all know, this stuff is super complicated, and in order for the web to move forward things have to “just work”. Either Mozilla has to fix the behavioral bugs or every web developer who uses the feature has to track down what the problems are and try to find a hack for it.

P.S.  FWIW, other than selection memory, WebKit has worked perfectly so far.  That said, Mobile WebKit for the iPhone has a major issue. It doesn’t actually support contenteditable at all. Worse, it reports that it does — node.contentEditable and node.isContentEditable are true for a node with the attribute contenteditable=”true”, yet . So if you want a fallback, you have to sniff for the user agent rather than use the technique of capability detection, which is better because you never know which future version will support contenteditable.

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.