The Wall Street Journal has an article on a new bill just passed by US Congress that updates accessibility requirements.

The legislation, called the 21st Century Communications and Video Accessibility Act, covers things like captions on Internet video, Internet phone services that work with hearing aids, television menus that can be seen by people with vision loss and even touch screens that the blind can use. The bill, which passed by voice vote and will now go to President Obama for approval, updates existing regulations to bring them in line with the Internet age. I haven’t taken the time to decipher the details from the actual legislation text as yet, so it’s hard to say exactly what implications this will have. It is at least good to see improvements to US laws – to date it has really been civil threats, such as the suit against Target, which have been the main legal avenue to ensure accessibility. This is generally under the American’s with Disabilities Act which was written in terms of physical accessibility for public places, but has been deemed to also apply to the web. As I understand it, this new legislation will provide some more teeth on the criminal1{#footlink1:1285835355912.footnote} side.

Over the weekend I went to JSConf EU and every time I met someone and told them I was working on TinyMCE the conversation rapidly veered off into why contentEditable is too hard/buggy to work with and how it would be so much better if it was all built on top of canvas or just used the DOM with a custom selection API. This matched the thinking throughout the conference that it doesn’t really matter how messed up browsers are because JavaScript can be used to work around it.

Austin Seraphin’s posts on his experiences using the Voice Over technology in iPhone and Mac OS has been mentioned fairly widely and they are definitely worth reading. Many people understand that blind users, and people with other forms of disabilities, are dependent on screen readers to interact with computers, but what is likely to come as a shock is just how expensive high quality screen readers can be:

I joyfully look forward to the day when blind people finally catch on and realize that for $700, HALF the cost of JAWS for Windows, the most popular software used or rather pushed on the blind, they can get a fully functional computer that delivers a superior experience and comes with a superior screen reader with superior speech. JAWS standard edition turns out to be $895 on the online store, professional $1095 but that still doubles the cost of a computer for users who need a screen reader. There are open source screen readers and my understanding is that some of them are quite good, but the defacto-standard is very much JAWS. Most accessibility testing that is done is with JAWS and so it’s an up-hill battle to use anything else.

Windows uses a particularly ugly format for putting HTML on the clipboard, called CF_HTML. Basically, it adds a header to the content with pretty useless information essentially declaring how many bytes in the header (and yes you have to pad the byte counts since they themselves are included in the count).

The problem between Java and Firefox is that Java always sets the ‘StartHTML’ and ‘EndHTML’ fields to -1 to indicate there is no context and Firefox will refuse to paste HTML from the clipboard if StartHTML or EndHTML is set to -1. As such, if you copy HTML from Java it will be impossible to paste into Firefox. It works perfectly with Word and IE.

Lisa Hill from Blue Fish has published an excellent article covering how to customize the EditLive! rich text editor in Web Publisher. It includes many of my favorite ways to get the most out of EditLive! as well.

I quite enjoyed reading Joe Duffy’s piece: The ‘premature optimization is evil’ myth, highlighting just how misused that Knuth quote often is. There’s a lot of good stuff that should always be considered, especially around picking the right data structure – mostly to improve maintenance more so than performance.

The most important point I find in the piece is to understand the order of magnitude that matters:

First and foremost, you really ought to understand what order of magnitude matters for each line of code you write.

It’s already been mentioned on my travel/personal stuff blog but news this good should be shared as widely as possible. My wife and I are expecting a baby in April of next year. We’re very excited and pleased that Mum and baby are both doing well. If you’re interested in how things progress, we’ll be posting that over at “The Suttons”.

The issue of P tags vs BR tags comes up very often and since my response to it has become a series of 5 articles, this post is here to provide a convenient index to point to in future.

General Primer

• Why P Tags are Your Friends
• P Tags in Word

Solutions for Specific Situations

• P Tags and Single Line Fields
• P tags and Flash
• The Email and P Myth

What Is contentEditable?

JavaScript editors are all fundamentally based on a technology called contentEditable which makes a part of the web page become editable by the user. While there is a lot of functionality that’s usually bundled under the “contentEditable” title, there are a few core parts which are essential for a browser to support correctly1{#footlink1:1278939007857.footnote}:

• Selection – allowing the user to position a text caret in the content and select various parts of it.
• Content entry and deletion – allowing the user to type basic text and to delete selected content.

Without these two key components of contentEditable it’s impossible to create a high-quality, WYSIWYG editor with JavaScript. Despite some variations in how things work, this functionality is available on all common desktop browsers and has been for quite a few years.

There has been a fair bit of discussion on the WHATWG HTML 5 list around whether or not browsers should ‘sniff’ for video types instead of relying on the HTTP Content-Type header. There are some reasonable arguments on both sides, sniffing is unreliable and can introduce security problems, but a lot of servers default to incorrect Content-Type headers and it’s too hard to configure them.

Having watched that debate go on for a week or more, I found it quite interesting and timely to see a support case come in specifically complaining that we’d gotten one of our Content-Type headers wrong. It turns out that we’d been serving up a JavaScript file as text/html but since it was included via a script tag, browsers always treated it as text/javascript anyway and everything worked. The catch is, Tivoli Access Manager was then set up between the client and the server of this JavaScript and it actively filters all HTML pages. Naturally, filtering JavaScript as if it was HTML tends to break stuff.

One of the most difficult situations to work with is when your output needs to be rendered using Flash. The HTML support in Flash is absolutely horrendous – worse even than in most email clients. Contrary to popular belief, Flash does support P tags. You will however need to ensure the text field is set to multiline. The BR tag is also only supported in multiline fields. The problem most people hit is that Flash doesn’t support the margin-top and margin-bottom attributes so you can’t get rid of the blank line between paragraphs.

One of the common reasons people want to avoid P tags in content is because the field is designed to hold just a single paragraph, so having multiple P tags inside the content would break the template layout when it’s rendered. Usually the template renders the content as something like:

<p><%= fieldContent %></p>

In that case, where the output is the only thing within the paragraph, the best solution is to leave the paragraph tags in editor content and remove them from the rendering template. That gives the editor the context it needs to work well and avoids a lot of potential problems with rendering the content. If however, you’re including some extra content in the same paragraph then the situation is more difficult, e.g. your rendering template is more like: