Yesterday on Twitter I outed seven Responsive Web Design Checkers that don’t really test #RWD:
- http://ipadpeek.com/
- http://juicecreative.co.uk/juicer/
- http://mattkersley.com/responsive/
- http://quirktools.com/screenfly/
- http://responsive.is/baloney.com
- http://theblogchecker.com/tbc-responsive/
- http://www.responsinator.com/
Shortly thereafter the dig me paper.li of a webdev wannabe named Simon Manning picked up my links but not my comments, leaving the impression I was praising rather than panning the posers who put them forward. This will correct young Simon’s error:
What most of the seven checkers above basically do is render your web page source in “iFrames” with widths set to match the screen resolutions of popular tablet and mobile devices such as the slave-produced Apple iPad and iPhone. That might show you how your media queries, fluid grids and flexible images render within a given iframe in a given browser of a given version, but that is not the same as showing you how your web pages will render on actual iOS, Android or other mobile devices. Why? Because…
iFrames are not iPhones!
#RWD testers that ignore things like device and capability detection via user agent strings and DDRs (device description repositories) give you virtual but not reality. We have website templates with fixed headers on standard browsers but not on tablet or mobile. None of the checkers above reflected that. We have web pages where the title text for standard and mobile browsers is not the same. None of these checkers reflected that. We have blogs which show the same content in different themes for standard versus smartphone browsers. None of these checkers reflected that. We have URLs which redirect not-so-smart phones from web page content they can’t handle to smaller W3C mobileOK pages they can. And none of these checkers reflected that, either.
I could go on, but do I need to?
Forget these charlatan checkers. If truly responsive web design is what you seek, then mobile friendly web 3.0 front-end development is what you need. If you want broad accessibility like this, your web page source will have to pass meaningful validations like these.











