I’m looking for people to provide alternate language translations for my Color Contrast Tester. I’ve already got people offering to provide Italian and German language files, but once you’ve gone that far…why not keep going?
If anybody reading this can provide additional translations, let me know in the comments — I’ll respond privately to make arrangements. It’s an easy job; the language file is independent of the rest of the script, so there aren’t any serious challenges in sorting what needs to be done.
Thanks in advance!
Perfecting a web site is a long and involved process. There’s no getting around the fact that if you want every aspect of your site to be right — - accessibility, search optimization, and just all-around pizzazz, you’ve probably got some significant work to do. However, that’s not to say that there aren’t things you can check quickly and efficiently to make sure you’re not making some of the more egregious errors!
Here are 8 speedy checkups (in no particular order) which you can easily perform on your site to inspect it for problems. No methods suggested require special knowledge of HTML or web programming. Excluding acquiring and installing software, these tasks shouldn’t take more than a few minutes for most sites.
That doesn’t include fixing any problems found, of course…
Read more: Web site Tune-up: 8 Quick Checkups
There are a lot of services in the web marketplace offering code conversion. You give ‘em a design, they spew out some junk code for you. This isn’t the way it has to be, thankfully.
There are, believe it or not, PSD to HTML conversion services which are committed to creating standards compliant, semantic code.
Well, there’s at least one — http://w3-markup.com/. I’m not personally aware of others…
But the point is that if you’re a designer who needs a completed design transformed into semantic code, you don’t actually need to do it yourself. Or, alternatively, if you’re fully competent to do it yourself but short on time, you can speed things up using this service.
Advantages of the service:
- highly customized order process — the order form allows you to select numerous detailed customizations.
- their process allows you to work with their staff via live chat, conceptshare.com, and our client area intranet.
- guaranteed turnaround time.
Truthfully, the order form is pretty savvy in terms of providing you with ways to specify significant detail on exactly how your site is built. If you simply prefer that they use the Dojo Javascript library instead of Prototype — - that’s an option. The options are extensive.
Among the options, for example, are these options:
Web Content Accessibility Guidelines
A set of guidelines provided by the World Wide Web Consortium, these overlap with our own mobile and screen reader compatibility options however ours are more practical and up-to-date. If a specific version of the guidelines is to be followed please specify it in the comments section.
[…]
W3C Compliance
Currently 2.1 of the cascading style sheet standard is the most widely supported and capable version. Select 1 or 2 only if you have specific needs that require those versions. Select 3.0 if you wish us to use experimental or loosely supported techniques.
It seems to me that one of the key advantages to this service is the ability to work directly with their staff during the construction process. However, even without that, you can provide an incredible amount of detail concerning the development in the advance specifications.
If you have specific needs (such as accessibility beyond the guidelines), you’ll have the opportunity to discuss those issues with the developer while they work.
Oh…and I really like their tagline: “code is art….” I can appreciate that sentiment!
Disclosure: This is a paid review. But don’t worry — it’s honest.
Some time ago, while pondering whether web accessibility posed limitations on design, the thought occurred to me that there are presumably some colors which simply cannot be used for text or text backgrounds in any site.
WCAG 1 does not, in fact, provide any specific guidelines concerning color contrast. The formulas commonly used to judge this were specified in Techniques For Accessibility Evaluation And Repair Tools, published in 2000. The document is intended to help authors conform to WCAG, but is not actually part of the WCAG document.
The nature of the Web Content Accessibility Guidelines (WCAG) specifications of color contrast fairly well ensures that some colors in the middle range of the spectrum (in hexadecimal, generally between #666666 and #999999) simply won’t be compatible with any other color.
My first thought on this point was to create a chart of colors which simply couldn’t be used in these contexts. I decided against this, on the grounds that it didn’t really seem all that valuable to me. But the thought of viewing color contrast problems in a different way than most color contrast checkers stuck with me.
It seems that most color contrast checking tools work in one of two ways: they either take a webpage and check the contrast factors between text and background on that page, or they allow you to enter a pair of colors and find out how they mesh up. Since this article was authored, I’ve created this basic tool as well. Evaluate contrast between two colors.
What I’ve done instead is set up a color contrast checker which only requires you to enter one color, then displays a selection of possible color combinations using that color. It’s pretty straightforward: you can choose to view results ordered according to WCAG 1’s color brightness and color difference tests or according to WCAG 2’s contrast ratio algorithm. Either way, all three factors are displayed, providing a good sense for how the two systems differ.
The results can be quite interesting. Compare the results for #888888 under WCAG 1 and under WCAG 2, for example:
Altogether, I’m hoping that this tool provides an interesting way to approach color contrast issues and to view the differences between WCAG versions 1 and 2.
Resources:
Color Comparison Formulas
Color brightness formula: (must be greater than 125)
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
Color difference formula: (must be greater than 500)
(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))
Contrast Ratio with Relative Luminance formulas: (greater than 3:1 for print sizes over 14pt Bold equivalence or 18pt normal, greater than 5:1 for smaller text)
(L1 + 0.05) / (L2 + 0.05) where L1 = 0.2126 * R1 + 0.7152 * G1 + 0.0722 * B1 on the RGB values of the lighter color and L2 = 0.2126 * R2 + 0.7152 * G2 + 0.0722 * B2 on the RGB values of the darker color.
Thanks to an off-hand comment from Steve Green while discussing a forthcoming Accessites article, I’ve spent some time today thinking about what it takes to write for accessibility.
Most of the time, the primary focus of information about accessibility has to do with making non-text information available as text. Captioning and audio description for video, transcriptions for audio, simple text alternatives for static images. Next in the list tends to be availability of functionality: progressive enhancement for client-side scripting, ability to navigate the page via skip links or semantic HTML headings, and so on.
But what about the content itself?
Disregarding issues concerning the use of abbreviations, typography, headings, and other semantic structures in HTML, the simple use of punctuation can be a significant barrier. This is a problem which applies to all text content for any user of a screen reader, in particular, although following these suggestions will benefit any reader of your content.
The issue isn’t precisely correctness. A sentence can be punctuated with perfect correctness but still lose clarity when spoken by a screen reader. It’s a matter of the lack of refinement in screen reader voice interpretation.
As a human speaker or writer, aware of the meaning and context of a sentence, it’s easy to speak a sentence and convey the meaning you expect in that sentence. A slight emphasis on one word or another is highly significant. However, in HTML, as in normal writing, there’s no means to indicate this kind of special emphasis which is readily understood by current screen reader technology. As important as strong and emphasis are semantically, they are not interpreted meaningfully by screen readers.
Punctuation is left as the sole means to refine and polish the meaning of a sentence for screen readers.
How do screen readers use punctuation?
Screen readers read most punctuation by default, such as parentheses, dashes, asterisks, and so on, but not all screen readers choose to read the same pieces of punctuation. Some do not read asterisks by default, for example. Periods, commas, and colons are usually not read out loud, but screen readers generally pause after each. Users can set their preferences so that screen readers read every punctuation mark and character. Web AIM, “Designing for Screen Reader Compatibility”
So common sentence punctuation marks, such as periods and commas, are indicated by pauses. However, special punctuation, including dashes and parentheses, are read as characters. This should immediately tell you how difficult it could be to understand a sentence containing numerous subclauses or parenthetical statements!
Only a few years ago, it was common to see pages that explained quote this page best viewed in Internet Explorer quote left paren or Netscape right paren. Web AIM, “Designing for Screen Reader Compatibility”, as rendered by Fangs
Although this is a relatively simple example, containing a single quoted passage and a single parenthetical statement, it could readily be very confusing to follow a more convoluted sentence structure, regardless of the correctness of the sentence.
So what’s the solution? Simply speaking, to write simply. Keep your sentences on the short side, avoid excessive parenthetical statements, and avoid excessive subclauses. Above all, try reading the sentence without giving any particular emphasis to the terms and see how easy it is to understand the statement. It’s easy to write an ambiguous sentence if you’ve assumed it will be pronounced in a particular manner.
Ultimately, the expectations when writing with a screen reader in mind aren’t that hugely different than without. After all, it’s not as if you intend to write confusing and ambiguous statements. However, the line drawn between “confusing” and “clear” is not necessarily in the same place for a computerized reader.
“WebAnywhere” is a new screen reading product (available in May of 2008) from the University of Washington and the WebInSight project. The basic concept is simple: it’s a web-based service which provides a proxy service as a screen reader. Fantastic tool for anybody requiring a screen reader at a computer which they don’t control: at a public library, a friend’s house, or any imaginable situation where your normal setup isn’t available.
The project is designed with minimal requirements, and is supposed to be usable from any web-enabled device with a sound card.
On top of that, the software is open-source and available through Google Code.
It’s impossible to say at this point how the user interface and power available to the screen reader will compare to a mainstream screen reader. Will this be a usable tool for web developers to use as a testing device, for example?
The project information is available at the WebInsight project page. The principle feature is a demonstration video, showing the basic use and value of the service.
There’s no information available concerning the features of the service beyond a few comments during the video concerning keyboard shortcuts. I’m looking forward to seeing the service and discovering what tools and features it provides.
This new book from Packt Publishing & Nirav Mehta is a quick and effective introduction to developing websites specifically targeted at mobile device users. I say “users” for a reason — - one of the strongest advantages to the book is a strong focus on considering your user and their needs as a key element of mobile web development.
My overall reaction to this book was positive. It covers a wide variety of key issues for mobile web programming in an easily understood manner. The book is targeted primarily at developers who already have some experience at web development and design, so it doesn’t delve into any serious detail when it comes to server-side programming or HTML coding, but instead makes a point of emphasizing places where the mobile web is different from internet interaction on a desktop device.
Mehta goes out of his way on many occasions to emphasize the serious importance of considering who (and what!) will be using your mobile web application.
“Any website accessed from a mobile device is mobile web — - whether it’s been tailored to work on a mobile or not!” Mobile Web Development, Nirav Mehta, page 10
The book covers a wide range of issues — - from developing for mobile devices using a “lowest common denominator” plan to implementing highly dynamic mobile applications which adapt automatically to the device currently in use. The text is easy to understand and follows a logical progression, starting with the mobile web development practices which are most similar to the development of standard web applications before moving into the areas which are very specifically targeted towards mobile devices.
This isn’t to say that the book doesn’t have a few flaws. I identified three areas where I really would have liked to seen better work.
Editing
In general, the copy editing on this text was pretty poor. The editing improved as I got further into the book (or I became more oblivious to it), but the introductory chapters had a lot of problems. There weren’t a lot of typos — - but the grammar was noticeably lacking. The book is rife with sentences like this:
“We will need a recharge of patience if we wanted to watch a movie preview on low speed mobile networks.”
I’m not a member of the grammar police, but I’m certainly sympathetic. Professionally published books simply shouldn’t contain the kinds of errors found in this book.
Code Examples
The author talks about following web standards as a critical element of mobile web development. That’s great. It is, however, a serious pet peeve of mine to see code examples which don’t reflect the text of the book. The very first code example in the book is this:
<link rel="stylesheet" type="text/css" media="handheld" href="mobile.css">
The text preceding it states “Here’s how you can add an alternative stylesheet link in your XHTML page.” I see a problem here. Yes, the author does explain at a later point in the book that all XHTML elements must be closed: but it’s a simple fact of life that most people referencing this book will be far more likely to simply reference the code as is. This is simply a mistake; but it’s not one that should have made it through a review of the book.
I’ll admit that I haven’t gone through and checked the validation of every code example. Most of them seemed solid and accurate. There are definitely examples which wouldn’t be valid under the XHTML DocType, but I’m not adept enough with XHTML-MP to know off-hand if the same is true within the mobile profile DocType.
Appendices
Simply put, there aren’t any. There were numerous points in the book where I thought to myself that an appendix would be great. A list of resources cited by topic, a section summarizing the syntax of VXML, tables showing the differences between XHTML and XHTML-MP or between CSS and WCSS. These kinds of resources would have been tremendous benefits to the overall reference value of the text.
Overall
This is a worthwhile book. Even though I wouldn’t recommend trusting the code examples, the truth is that you should never simply take code examples as written — - you learn best by taking an example and re-purposing it for your own needs. Mobile Web Development will introduce you to the key issues for mobile web programming and design in a manner which can give you a quick start on mobile web application development.
Return to Top
