blog

Call me a Luddite or a libertarian nut, I only share my cell number with those deep in the “inner circle.” Until recently, I had never shared it with a Web property. Until Epicurious.com convinced me the value of sharing was greater than my privacy concerns.

The quick backstory: Our home Internet connection went down. 10 guests coming for dinner in 3 hours. Printed recipe for seared scallops had gone missing. Panic.

A quick search on my Treo yielded dozens of recipes. And every one of the first 7 taps took me to Web sites that were a usability nightmare on my Treo. Even my favorite - Cooks Illustrated - failed my “this is too much of a hassle on my Treo test.” (Ok you iPhone users, no need to comment on that one, I know your gadget is superior!)

Then enter Epicurious. I tap their link on Google, they detect I’m on my mobile, reroute to a WAP version of their site and serve up a simple login screen that fits my window:

Please enter your mobile to unlock your recipes, create a shopping list, search and more.

Hmm. Why do I need to enter my phone number? (more…)

Whenever someone wants to build an accessible Web site, I always try to conceive the design from the simplest elements on up, rather than most complicated pieces on down. That usually means some more intricate components, like a Flash application, are usually out. Yes, I know it’s a generalization. Yes, I know you can make Flash accessible. But it’s not always easy, especially if you’re making more advanced applications. Even the Adobe site gives us caution:”Creating this kind of content may require guidance for novice developers.”

But if you’re not ready to give up your Flash application or your site’s accessibility, you still have some options. But you need to plan for it. You can’t make the Flash application now, and then decide to make it accessible later. And for your more advanced applications, you need a competent Flash developer who will work with you and understand your accessibility needs.

Flash actually offers some elements that make it more accessible than standard HTML web content. Two that are of note:

• Vector images. With vector images, someone with low-vision can zoom in on their screen and the Flash content will remain crisp.
• Key-stroke enabling. You can create interactive Flash applications that do not require mouse interactions.

Using these features, the following tips, and some common sense, you can have your Flash and accessibility too.

(more…)

With accessibility being more and more important these days, particularly for organizations that are required to be Section 508 compliant, there’s been a lot of discussion of “How accessible is too accessible?” This generally involves questions of how much instruction to include, whether to use accesskeys, and to what extent it’s important that a site look good when text size is increased, at the cost of how it looks when the text size is normal.

But one area that’s rarely discussed is when and when not to use Alt tags, particularly in email. Alt tags, the captions that appears when the image does not, or when hovering over an image, are particularly handy for describing to screen readers what the included images are. They can also improve site search engine optimization and act as a place to put copyright info.

But they can wreck havoc on emails, when messages like this arrive in your inbox:

More below the fold on why Alt tags like this are unnecessary and why it’s important to consider your teaser when writing an email.

(more…)

There was an AP piece out recently, discussing the problems and challenges of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart - yeah, it’s a stretch, but most of the good acronyms were taken), and proposing, as a possible solution, a webcam that continually takes pictures of a variety of subjects and asks users to identify them. It’s rooted in the problem that unless you have a truly gigantic database, spammers will eventually just add your pics to their library and be able to break through. By using a webcam of, as the article suggested, a kitten bouncing around a room, there would be a continual stream of new photos for users to identify - presumably, you could have multiple kittens and ask how many were in a shot or what color the one currently on screen is or something that would change but be easily identifiable by people.

While this is an innovative, not to mention fun, approach to CAPTCHA, it brings up a chance to discuss the merits of using it at all. Let’s take a look at three areas where CAPTCHA is causing debate online: blogs, webforms and email.
(more…)

In an interesting post, Web Designer Mike Cherim wonders what damage we can do to the accessibility of Web sites by overdoing it with accessibility features. I’ve been thinking about this myself and find that I agree with Mike when he says that some accessibility features are either so misunderstood, poorly implemented, or unknown that they are probably best steered clear of (Access keys) or used in moderation.

In related news, Web Content Accessibility Guidelines version 2.0 is open for comment. You have until June 29 to submit your comments on the working draft and make your voice heard. There is also a summary of changes since the last draft avialable for you to review.

Recently, we had two different clients ask us for assistance in finding mass email tools that have built-in support for multiple languages. They were specifically interested in sending out Arabic and Chinese emails to their supporter list.

If you dabble in the area of internationalization (i18n) in tech tools, then you would agree with me when I say that it is particularly difficult to find a technology solution that can fully support languages like Arabic and Chinese. Generally, tech tools are really good in supporting languages that have a Latin-base (ex. Spanish). They are not that great with a non Latin-based language like Chinese. They are downright poor when it comes to a non Latin-based language that also reads from right-to-left (RTL) like Arabic. And, don’t even get me started on RTL languages that share most characters but not all (Arabic & Farsi/Persian).

Before we delve into the multi-lingual mass email support issues, here is an over-simplified version of the technically complex process of creating emails:

Email written up or “encoded” in a language (i.e. Arabic, Chinese, etc.) –> Sent out by bulk mailer –> Received by email server –> “Decoded” for view or display in your email client.

Side note - Problems in the decoding end of things require a separate post, so I will ignore it for now.

Most email solutions including < insert most eCRM and email marketing tool names here > do not go beyond Spanish for their multi-language support line item in the features list. So, no multi-lingual support, no encoding, no sending out, no nothing.

A small number of vendors and solutions support multi-lingual emails, but it ends up being an interim solution. In the encoding process, they create HTML emails where letters are represented by their numeric character references. This is somewhat akin to using & in HTML code to indicate &. All HTML-enabled email clients display this fine for the recipient to read. Most email clients, including the browser-based ones like Google and desktop-based ones like Outlook, are HTML-enabled these days. So, most recipients would have no problems with this solution.

The issue with this approach however is what happens in the back-end. This approach means that you can send out only HTML emails and not plain-text ones. If you viewed the source in these emails, you will see a string of these numeric character references. This means that many of the functions that depend on actual letters instead of numeric references (ex. search) will not work. Sort of reminds one of those Hollywood studio sets that look grand from the outside.

This approach runs out of its usefulness if your organization wants to (or is mandated by its mission to) provide the full-spectrum experience to your supporters, donors, and advocates who speak other languages. This is becoming an important need. As I mentioned at the beginning of this post, we recently had TWO clients ask for bulk email tools supporting multiple languages. So, hopefully things would change soon. But, much of this innovation will probably originate from regions where multiple languages are the norm rather than the exception.

A note in the “somewhat related” category - European Union has 23 official languages and India has 22. Conflict of interest or disclaimer or something of that sort - My native language is one of those non-Latin-based languages, so I may have “vested” interests.

A note in the related category - If you are developer, here is a slightly dated, but still relevant article on email, MIME, Content-Transfer-Encoding header, etc: http://www.eveandersson.com/arsdigita/asj/mime/

There is an interesting discussion following an AlistApart.com article entitled Where Our Standards Went Wrong, in which the author, Ethan Marcotte discusses two sides of the web standards debate. In the article, Ethan tries to refine the message we as standards advocates are delivering.

Yet while the benefits of valid code may not be glamorous, we can—and should—talk about them. Validation isn’t an end result or a final deliverable; it’s an ongoing process that continues long after a site launches. If we don’t put the proper tools and commitment in place, our work will start looking like a late ‘90s throwback, and if we don’t provide guidance and education on validation, the polished, perfect pages we produced will be snapped into software that’ll produce tag soup in seconds flat.

Ethan also discusses some of the problems with Content Management Systems (and their often third-party) text editors, which are often central to the standards issues we face when deploying web sites for clients. In the discussion following the article, several people touch on this aspect, and even (gasp) offer some solutions.

It’s a question that comes at some point in nearly every design project we do: “Should we stick with 800 pixels as our maximum width when designing the site, or push it up to 1024 pixels?” Unfortunately, there really isn’t a cut-and-dried answer that fits all situations. As a result, the question will generate debate and discussion as if it were the first time it was asked.

It would be great if it were really so simple as to just pick a width and go with it. That’s often what is done, but there are issues that make the question worth taking a deeper look at. Issues that can vary from client to client.

Simply having more space to work with is often a designer’s purpose for suggesting a wider layout, while clients are often motivated by a desire to fit more on each page. Not surprisingly, these two goals can often end up colliding into each other after the design goes into a production environment.

Unfortunately, regardless of your reasons for wanting more space to work with, it’s not simply a design question. There are accessibility and usability questions as well.

Although the percentage of users browsing the web with a screen resolution of 800×600 is decreasing (between 10% and 30% depending on whose stats you’re looking at), those that do so may be using the lower resolution (and even increasing the font size further from there) because they have trouble reading the smaller text-sizes at today’s higher screen resolutions. To not take this group into consideration violates accessibility standards. That’s not to say that we have to stay with 800×600 layouts, it just means that we have to make sure we consider the impact of any layout.

Why choose? Why not use a liquid, or expandable, layout? Liquid layouts have been around forever but continue to make up the minority of sites that we build. Why? There are a few reasons, but with the increased importance of accessibility as well as the growing number of alternative devices (Cell phones, PDAs, smaller laptops, tablet PCs and other devices) used in the U.S. and, even more so, in the developing world, our need for more flexible layouts is increasing.

Liquid layouts are a bit trickier to code, but the issue that usually trips us up is one of control. By this, I mean the perception of control that we often feel we have, or need to have, over the layout of a page.

In the design phase of a project we work with static images depicting how the page should look. Sometimes we pass these static images (or ‘comps’) back and forth for weeks, tweaking and adjusting spacing, color, layout and imagery. Since we are unable to make “fluid” design mock-ups we start to develop a sort of tunnel vision with regard to the design at hand. We start to internalize the structure of the designed page as well as the design elements, and when confronted with the prospect of how the page may stretch and resize when coded with a fluid HTML template, we back quickly away from the lack of control over the design that, to date, we’ve had pixel-perfect control over.

Perhaps the problem stems from the static representations we work with during the design phase. Are there any options?  Do we need to start presenting design comps that show the same layout as it will appear at several different resoltions (including handhelds)?

We need to let go a little bit of our need for absolute control over our page layouts. It’s been said before and should be said often: The web is not print. While this is overstated quite often, it is certainly true.  If people could easily modify layout, font sizes, column counts, etc. in print, then they probably would. Browsing applications and devices give average users exactly that level of control over what they view; And they use it.

Whatever the solution, we will continue to be confronted with the question every time we design a site. And to reduce the question to one of design alone may be causing more problems in the long run than we foresee.

As I code pages for Web sites, I’m always working on ways to improve accessibility. The online tools for evaluating a site really just don’t cut it alone. It’s fairly easy to code a site that passes tests like the one found at The HiSoftware Company CynthiaSays portal (a very popular and accurate accessibility test) but that is still utterly unusable by someone using a screenreader, unable to use a mouse, suffering color blindness or any other disability that means they are using your site in any number of different ways. That’s not to say that online tests are not incredibly valuable, just that running your pages through a single test and thinking the job is done may not cut it.

Accessify.com has provided some incredibly useful tools and wizards to help build and test accessible Web sites. There are wizards for creating accessible HTML code (forms and tables), browser plugins for testing pages, even a set of Dreamweaver objects that increases the accessibility of your code by adding additional options to dialogs for creating tables, images, acronyms, etc.

For testing usability for people with different vision needs, I love GrayBit which renders your page in grayscale so that you can visually evaluate the color contrast of your site. Another really cool color tool is Color Schemes which not only helps you develop a color palette, but also lets you preview your palette approximating eight different types of color blindness.

When you get right down to it, though, there really is no substitute for having differently abled users test your site. They’ll let you know better than any test out there what needs to be improved. Just testing with average users who are unfamiliar with the site will go a long way toward exposing usability shortcomings, which often translate to accessibility issues.

Remember: an accessible site is also a more search engine friendly site! As if you needed a selfish reason to strive for accessibility.

There is another interesting article on A List Apart about accessibility. This one focuses on user testing and how assumptions that many of us have made, regarding how differently-abled people use sites, often do not play out in real-life tests. There is some specific comment on how, since there seems to be no actual data to support many of their guidelines, simply following the WGAC recommendations does not guarantee an accessible site.

We often make something a law just because it’s been repeated over and over again. User testing is really the only way that we can prove, or disprove, our ideas about how websites shouold be built.

Some excerpts:

But more than that it turns out that while size matters, boldness also matters. In fact, a bigger text that is not bold, is less readable than a text of the same size that is bold.

and:

In short, we need less discussion and more user research. Especially when our guidelines form the basis of national laws, we need to ensure that they’re founded on real user experience.

and finally:

I asked a reputable member of WCAG-WG what kind of user research WCAG 1.0 was based upon. He answered that “WCAG are based on many things,” which sounded good, but didn’t really answer the question. Exactly what were those “many things”?

It’s a short article, and certainly worth the read.