Check out this SlideShare Presentation:

Understanding JavaScript Testing

View more presentations from jeresig.

Check out this SlideShare Presentation:

Django Testing

View more presentations from ericholscher.

Sometimes people ask me what's the point in creating a so huge collection of CSS tests. So here are some explanations. First of all, the tests I made are just the result of a good amount of spare time. Being unemployed for a long time forces you to do something with your time schedules. Usually I started wondering about some issues with CSS layouts, for example about floats, positioning and the like and then I used to create a test case that could show why something worked or not. These are basically how my first tests look like to a visitor stumbling for the first time on them. But then came the W3C CSS Test Suite, where I had to get rid of my bad coding habits and get used to code following certain rules.

These kind of CSS tests are rather cryptic, because you have to look at the meta information of the page to see how they should work. I think that these tests are not very useful for a casual reader. It's better to stick to complete layouts and demos to get an idea about how a certain combination of properties should work together. So you should make a choice: W3C testing style or your own testing style. Be aware, however, that your custom style should be self-explanatory or you'll probably end up with receiving mails from people saying "Man, I didn't understand how to do this and that.".

When you make a test, just simply ask yourself what you're going to demonstrate. If it's not clear in your mind what you're going to show to your visitors, it's more likely that you'll fail with your purpose. Second, be clear, Third, even with complex layouts, write a good explanation about how your page should look like and, if proper, provide some screenshots. Remember: if something is not clear to you, it's likely that even your readers will have problems with your tests. So theory first: read the CSS specifications, read tests made by other developers, read the most relevant tutorial on the topic of your choice and, finally, be creative. Further, be ready to update your tests when browser support changes or a new bug comes along. By doing so, your tests will be simply useful and your visitors will be happy.

I don’t follow the point of this post. Jaws is the only way that a developer has to surf the web as a visually-impaired user does. Other tools cannot mimic a real experience, the experience of listening to your content being read aloud by a syntethic voice. No online service can do this. I think that the reason should be found elsewhere. First, sighted people generally don’t take care too much of what other people experience, just because they see and they can’t imagine a world without colors and images. That’s a problem of sensitivity and need to experience (or try to experience) what other people feel when colors and images don’t exist. Second, the overwhelming majority of company websites don’t care about accessibility issues, just because accessibility doesn’t fall in their marketing strategy. We want an easy-going way to say “oh yes, I know what accessibility problems are and I’ve tested them!”. Be honest: accessibility arise problems that very few people want to face. First and over all, accessibility means looking at the world with the eyes of people who suffer from disabilities, so it’s a matter of how much we care about the problems of other persons. Are they important to us or are we forced to cope with them just because a law wants so? I’m not criticizing this post, but I’m simply saying that our motivations should be clear to ourselves. Everything else comes second.