Slashdot Mirror


Do You Care if Your Website is W3C Compliant?

eldavojohn wonders: " Do W3C standards hold any importance to anyone and if so, why? When you finish a website, do you run it to the validator to laugh and take bets, or do you e-mail the results to the office intern and tell him/her to get to work? Since Opera 9 is the only browser to pass the ACID2 test, is strict compliance really necessary?" We all know that standards are important, but there has always been a distance between what is put forth by the W3C and what we get from our browsers. Microsoft has yet to release a browser that comes close to supporting standards (and it remains to be seen if IE7 will change this). Mozilla, although supportive, is still a ways from ACID2 compliance. Web developers are therefore faced with a difficult decision: do they develop their content to the standards, or to the browsers that will render it? As web developers (or the manager of web developers), what decisions did you made on your projects? Update: 05/20 by C : rgmisra provides a minor correction to the information provided. It is stated above that Opera9 is the only browser to pass the ACID2 test, however "This is not true - Safari was the first released publicly released browser to pass the ACID2 tests." -- Sorry about the mistake.

34 of 624 comments (clear)

  1. Safari 2 by m0rph3us0 · · Score: 5, Informative

    IIRC, Opera 9 is not the only compliant browser. I believe Safari 2 is also compliant.

    1. Re:Safari 2 by Ant+P. · · Score: 2, Informative

      And Konqueror (which Safari is based on), and iCab...

    2. Re:Safari 2 by Anonymous Coward · · Score: 2, Informative

      Safari and other webkit based browsers miss out one style on the acid2 test. Something to do with the scrollbars IIRC. So, although safari is extremely close to compliance, only Opera actually passes.

    3. Re:Safari 2 by chasingporsches · · Score: 5, Informative

      you do remember correctly. actually, safari passed it long before opera did.

  2. Acid2 is NOT A "Complaince" Test by mattdev121 · · Score: 3, Informative

    What people need to stop doing is comparing how a browser renders the Acid2 test to its compliance with web standards. If you bother to read the Acid2 page, you'll see that its purpose is to see how a browser renders INCORRECT code.
    To me, compliance is very important. Not only can you be sure that it will render properly in every proper, compliant browser, but it will also be easy to add on to and change stuff.
    Besides, as long as you aren't trying to jump through IE css-fix hoops, compliance is usually as easy as encasing all of your variables with quotes.

    --
    mattdev@server$ touch /dev/genitals
    cannot touch `/dev/genitals': Permission denied
    1. Re:Acid2 is NOT A "Complaince" Test by Bogtha · · Score: 5, Informative

      If you bother to read the Acid2 page, you'll see that its purpose is to see how a browser renders INCORRECT code.

      Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.

      There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?

      It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.

      Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?

      --
      Bogtha Bogtha Bogtha
  3. Reasons to validate by JimDabell · · Score: 5, Informative

    Reposted from something I wrote a while ago

    You cannot prove anything about the future... but you can identify trends.

    Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.

    Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.

    Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.

    Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.

    Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.

    More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.

    This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article). I'm sure similar things apply to other browsers.

    There is plenty of evidence that sticking with standard code results in forwards compatibility.

    There are really only two important properties of future browsers:

    • They are likely to support at least as much of the specifications as the current version
    • Nobody can test in them

    Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.

    There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.

  4. Anyone who answers "no" to this headline... by Dracos · · Score: 4, Informative

    Is a fool who doesn't deserve to be involved in web development.

    The Web would never have been much more than an academic experiment without web standards. Anything that has a sufficiently large group of people that use it at various levels needs standards. Think road traffic is bad now? Imagine if there were no lines on the roads, no standardised street signs, or even pavement. Getting anywhere would be total chaos, and most of us would be doing it on foot.

    Sure, Opera 9 is the only browser released for public use that passes acid2, but the Gecko codebase achieved this a few weeks ago. Unfortunately, we'll likely have to wait for Firefox 3 in order to experience it.

    IE7b2 is complete as far as standards compliance is concerned, so you might as well go ahead and test it now. It still has the worst compliance compared to all other non-MS browsers.

    The distance between any W3C recommendation and the browsers is a result of 2 things: vagueness in the document, and how any browser vendor decides to interpret it (if at all).

    The biggest threats to web standards aren't MS, WHATWG, Motorola, or any other entity.

    Number one: Quirks Mode. As long as browsers try to correct invalid documents, there is not real incentive for valid documents to be produced. Interoperability can't be fully achieved, and machine-to-machine exchange of data remains tenuous.

    Number two: Nomenclature and Authority. Part of the W3C's problem is the terms they use to identify the stages of a standard. "Draft" is understandable, but labeling a final document "Recommendation" almost begs people to ignore it at will. Furthermore, the W3C just produces documents, and there is no body anywhere to monitor and enforce standards compliance among browser vendors. I believe the W3C should be absorbed into an existing technical organization which people actually respect, probably IEEE.

    Anyone who doesn't care about web standards might as well go back to 1998-99 and try to keep riding the bubble.

  5. Re:do i care? by Ant+P. · · Score: 2, Informative

    I hate to point this out, but *both* of those are in the current CSS3 draft.

  6. table vs. div by Lauritz · · Score: 2, Informative

    I would like to ask a follow-up question: Do the replacement of tables with div-elements really help anybody (besides giving job security to web developers)?

    Note that I am not at all against css. But I just find the table-tag very usefull for layout. If you need to do a three-column layout it will be much easier and give cleaner code to just use a table, than to use one of the many css "hacks" needed to give the wanted result in most browsers. If you want the layout to do something "extra" (eg. "make the center column 400px wide, but allow it to grow if the cell contains a wide image, pushing the right column") it will (probably) be impossible using divs, but trivial using tables.

    One reason to not use tables, that is usally given, is that tables should only be used to tabular data and not for layout, as to not create problems for blind users. But just an empty alt-attribte on an image signals to the user-agent that the image is for layout only, a empty summary -attribute on a table could for example be used to signal that the table is for layout only. My guess is that, that convension would be much easier for user agent implementors to use that to parse through all of the css hacks. I also feel that it would be semanticly much cleaner to have a table with one row and three cells than to have three or four divs nested and floated in strange ways.

    1. Re:table vs. div by Bogtha · · Score: 5, Informative

      Do the replacement of tables with div-elements really help anybody

      You're asking the wrong question. It's not about replacing <table> elements with <div> elements. It's about using the most appropriate element type and leaving the presentation up to CSS. Sometimes that means using a <table> element, sometimes that means using a <div> element, and sometimes it means using something completely different, like <ul>.

      If you need to do a three-column layout it will be much easier and give cleaner code to just use a table

      The thing is, it's not easier or cleaner. In fact, it's usually the opposite. With CSS, you develop the layout code once, and apply it to all the pages on your site simultaneously. With tables, you have to hack up stupid <tr>s and <td>s for each and every page you do. Mindless, boring, repetitive work.

      I also feel that it would be semanticly much cleaner to have a table with one row and three cells than to have three or four divs nested and floated in strange ways.

      This sentence makes no sense. Semantics describe what individual parts of the page mean and are encoded with HTML elements. They have nothing to do with the layout or CSS. Why would "floating something in a strange way" be semantically wrong? Floating things happens on a completely different conceptual level to the semantics. On the other hand, describing something as a table, when it's really a heading or an image, is obviously semantically wrong.

      --
      Bogtha Bogtha Bogtha
    2. Re:table vs. div by Bogtha · · Score: 4, Informative

      The topic was html, not xml, so it is not about marking every bit of information up precisely.

      Actually, it's HTML that has semantics, XML is just a markup syntax, so it's definitely about marking information up precisely.

      It is about presenting a pice of information for easy consumsion for a human (blind or otherwise).

      Yes, and in order to decide upon the best presentation, a user-agent (e.g. a browser) needs to know what kind of information it is getting. Hence marking up tables as tables, headings as headings, and lists as lists, not marking up everything as tables.

      --
      Bogtha Bogtha Bogtha
    3. Re:table vs. div by Valacosa · · Score: 2, Informative
      "With tables, you have to hack up stupid s and s for each and every page you do."
      Not true, due to the magic of PHP and server side includes. Sure, the table may be ugly, but I still only have to hack it once.

      NOTE: I use CSS. However, I have found it's much easier to flog tables into doing what I want, DIV's have never been that co-operative for me. CSS beats <font> tags any day, though.
      --
      "Live as if you'll die tomorrow." Ridiculous. You could die later today.
  7. Re:Using Flash = Validation Fail by Bogtha · · Score: 4, Informative

    Last time I looked, there was no way of embedding Flash in a page that validates and actually works in most browsers.

    Look again.

    --
    Bogtha Bogtha Bogtha
  8. Re:A relevant quote by globalar · · Score: 5, Informative

    Aside from the all-important issue of "does it look right?", there is the professional issue of what sort of standards you should apply to your work. It's difficult to come close to a more extensive (and yet simple to implement) baseline metric of quality control with HTML/CSS than the W3C parser. Sure, I could go through and decide how I am going to do everything, but that's time-intensive and inflexible. Running something through the parser gives me a fast and consistent report. I can do whatever I want with the results, but they are there.

    It does not solve problems for you or guarantee much of anything, but it allows you to see your formatting code in a more objective way. As a bonus, it can help you spot potential problems, mistakes, and open your eyes to some of the structure you are relying upon.

    I always use the Tidy Firefox extension. It is a little friendlier than the online W3C parser interface. Disclaimer: not a professional web designer.

  9. Re:konqueror also passes by gdchinacat · · Score: 2, Informative

    So, I had to try this out and see it for myself. And, sure enough it rendered correctly. Then I started noticing the problems.

    Here is a screenshot after "scrolling" using either the scroll wheel or up/down keys (despite the fact — as you point out — that there are no scroll bars).

    And another one after a resize of the window. I restarted konq before doing the resize, so the issues aren't left over from the scrolling.

    Also, note in the resized screenshot that the progress bar is stuck at 37%.

    So, IMO, close, but not quite. However, close is better than most of the other browsers out there.

  10. Re:A relevant quote by ErisCalmsme · · Score: 2, Informative

    This is a Yogi Berra quote. "In theory there's no difference between theory and practice. In practice there is." ;)

    --
    Chaos is Divine *
  11. Re:That all depends... by soliptic · · Score: 2, Informative
    It's actually not as hard as many people make out to make a standards-compliant site that renders correctly in IE.

    First: this is assuming "correctly" is not defined as "pixel perfect", which was not and is not the point of the web. I concede that in many real world situations, the client expects a pixel perfect recreation of a PSD they give you, in which case you may run into problems. Things like the 3 pixel jog will screw you over. But if by correctly you just mean "looks exactly the same so long as you don't literally measure pixels", it rapidly gets easier.

    Broken box model? No problem. Just don't use padding, and use an extra internal div with margin instead. Yeah, the hardcore purists say will say "but that extra div isn't semantic". But... let's face it... your first div probably wasn't semantic, was it? Furthermore, what's better - one extra div, or an enormous maze of tables (the old school approach), or standards-busting deliberate CSS hackery (seemingly the preferred method of standards junkies, which always completely puzzled me. Let's just say I'm slightly smug now they're all sh*tting themselves trying to fix their deliberate CSS hacks in advance of IE7).

    I think one extra div is no small price to pay and voila, box model is sorted.

    I'd say there are pretty easy, non-standards-breaking workarounds for most of IE's quirks. If you MUST use alpha transparent PNGs then you'll be stuck. But if you're not bound by a designers' PSD it's not actually as bad as all that.

  12. Re:konqueror also passes by Mornelithe · · Score: 3, Informative
    From the Acid2 page:
    If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.

    Changing the size of the window has similar effects. Konqueror is exhibiting correct behavior; the test wasn't designed to keep the face constant after scrolling or forcing the browser to adjust the positioning by resizing the window. It's just supposed to display correctly after you click on the link that jumps you down to the face.
    --

    I've come for the woman, and your head.

  13. Opera 9 and Safari 2 are both beta by MojoStan · · Score: 2, Informative
    I don't know why the article submitter said Opera 9 was the only compliant browser when the ACID2 Buzz page clearly shows other browsers (at least in beta form) have passed the test.

    Anyhoo, the ACID2-compliant versions of Opera and Safari are beta releases and not displayed on their main download pages. Opera's download page displays Opera 8.5.4. Safari's download page displays Safari 1.2. IMO, I don't think ACID2 compliance is something to brag about if your compliant browser isn't stable enough for release.

    --
    TO START
    PRESS ANY KEY

    Where's the 'ANY' key? I see Esk, Kitarl, and Pig-Up...

    1. Re:Opera 9 and Safari 2 are both beta by allgood2 · · Score: 5, Informative

      The latest version of Safari is Safari 2.0.3. It's not in beta, and has been available to users since Mac OS X Tiger was released. It's not available for download from the Apple site, for the same reason many other Apple applications aren't available for download--current applications come as part of the operating system, and are automatically updated via Apple's Software Update. If a user needs to reinstall, they are suppose to go back to the OS disk.

      I should also mention that if you perform a search for Safari on the Apple Support website, you will also get a link to Safari 1.3.2 and Safari 2.0.1 both newer versions than the one you pointed to, which is legacy software.

  14. Re:Using Flash = Validation Fail by Stalin · · Score: 2, Informative

    There is the problem. You want the user to see what you see. The point of the web is to transfer information. It is possible to suggest how that information is presented, but, ultimately, the user decides how to "view" it. Fonts and moving pictures are pretty but they are distracting. I have a hard time reading unmoving text when there is something in view that is moving at all. So, your "right balance" is completely wrong for me.

    Back to the original point of this thread. Those two links where the site is nothing but Flash are exactly what I was talking about. I don't feel any desire to find or read the content because it is too difficult get to. No, it isn't hard to (for me) to see the image that says something akin to "click here," click the image, and get the content. The difficulty is that I had already asked for the content. I shouldn't have to start clicking more things to get to it unless there is more content that would make sense to be on another page (like the pages of a book). And then when I do have to navigate to a new page, I should have to wait for a bunch of animations and loading screens. I should be presented with the meat of the content (readable text) while any images load. That way I get what I am looking for and the pretty stuff fills in as my connection allows.

    Again, I'm not trying to attack you, but writing off validation because you don't understand its purpose is something that bugs me.

  15. Standards compliance by SlashBoot.org · · Score: 2, Informative

    Yes I care about W3C standards compliance. I take pride in my work and do not settle for bodges. There are also benefits to producing clean code, in bandwidth and processing savings. More sites and publishers should be making the effort to ensure that the pages they present are in compliance to accepted standards. My site http://slashboot.org/ is standards compliant and I take pride in that. I prefer XHTML Strict, as I see this becoming a future standard of choice for the majority of people who also take pride in their work

  16. Re:Standards by Xugumad · · Score: 2, Informative

    Specifying an alt tag of "" explicitely indicates the image has no content. Not including that alt tag could mean it has no content, or you just didn't think about it; as someone pointed out, Lynx specifically renders it is [IMAGE].

    And seriously, is alt="" that much bloat?

    Oh, it's also not the validator's fault, it is part of the HTML 4.01 standard. Argue with the W3C if you don't like it.

  17. Microsoft and web standards support by yoz · · Score: 4, Informative

    Microsoft has yet to release a browser that comes close to supporting standards

    This is often shouted and an easy way to bash MS. It's also completely wrong.

    Every web browser released by Microsoft from IE3 onwards has been more standards-compliant than any Netscape browser released around the same time. IE3 was the first major browser (outside of W3C testbeds) with CSS support. IE4 brought CSS-P support, while NS4 introduced the totally non-standard LAYER tag, then made a bad stab at implementing CSS-P under sufferance. IE5/Mac was easily the most standards-compliant browser on the Mac for years. The Mozilla project had been going for a while when IE6 came out, and Mozilla might be considered the better browser of the two if you rate standards compliance several miles above stability and speed.

    The reason IE6 is bashed so hard by designers these days is not that IE6 was a particularly bad release. It's that it's bad by today's standards, and nothing's been done to fix it. This is a different issue, and one that the IE7 team has been loudly busting a gut to address. (There is also the utterly shameful issue of IE6's many security problems, which is a different argument, but it's one of the main reasons I've been using Mozilla-based browsers since 1.0)

    And if you're still not convinced of anything other than Firefox's total superiority over IE in all standards-related matters, how about we dig up an issue of HTML4 compliance which IE's had right for years, and Mozilla/Firefox never has.

  18. Re:And besides... by Myen · · Score: 5, Informative

    Please, please *don't* write HTML as if it's XHTML. Self-closing tags in HTML is totally invalid and screws up the parsers. Pretend you're a HTML (not XML) parser and parse:

    <html><body><script src="..."/>Lots of stuff</body></html>

    Your <script> tag never gets closed (remember, this is *not* XML!). Wee, no content....

    If you are actually sending it with some sort of XML MIME type, yes, go ahead and do self-closing tags. Just don't pretend it works when you're being HTML.

  19. Theory and Practice by mysta · · Score: 2, Informative
    We're straying off-topic now, but that sounds a lot like this quote from the Danish computer scientist Jan L. A. Snepscheut (1953-1994):

    In theory, there is no difference between theory and practice. But, in practice, there is.

    --

    "Where is the wisdom we have lost in knowledge, and where is the knowledge we have lost in information?"-T.S.Eliot
  20. Browsers and Standards by pavera · · Score: 3, Informative

    I attempt to follow standards as much as possible, however because IE is so hideously broken, it almost doesn't matter. I recently developed a site, ran the validator on it, it passes fine, it all works in firefox and opera, displays how its supposed to, everything's great right? Open it in IE, totally broken, things don't line up, the spacing is wrong, everything looks like crap... go through everything to fix it, get it so it displays "right" in IE, run the validator again.... oops errors all over the place...

    In short I don't think its possible to write a standards compliant page and have it display in IE properly, as long as this situation persists, it will be impossible to push "standards" on the internet. If the standards don't display correctly on 90% of the computers, what are you supposed to do?

  21. Re:And besides... by hacker · · Score: 3, Informative

    The problem isn't HTML vs. XHTML and passing self-closing tags as HTML, the problem is that 99.999% of people using XHTML content in their pages, are not sending the proper XHTML Content-type for those pages.

    There is ONLY ONE valid Content-type for XHTML content, and that is application/xml+xhtml, not text/html.

    Thankfully, MSIE doesn't even support XHTML at all, so we're safe there... for now.

    This writeup is very clear on the matter.

  22. Re:And besides... by Enrico+Pulatzo · · Score: 2, Informative

    Actually, most tags can be closed in that way in HTML without problems. The script tag for some reason demands itself to be closed with an explicit end tag. img, object, br, hr all work fine with the XHTML style in HTML (they even validate). meta and link require exactly no end tag in HTML, and are invalid if you add it in.

  23. Re:FireBug by kadnan · · Score: 2, Informative

    FireBug is a good Firefox extension to catch evil tings in your page.It has a builtin validator as well.

  24. Re:And besides... by Bogtha · · Score: 2, Informative

    There is ONLY ONE valid Content-type for XHTML content, and that is application/xml+xhtml, not text/html.

    This is simply not true. RFC 2854, the definition of text/html, explicitly permits XHTML 1.0 documents that follow Appendix C to be transmitted as text/html.

    Doing so causes Mozilla and Opera to parse it as HTML and not XHTML, but that doesn't mean it's "invalid" or non-standard in any way.

    --
    Bogtha Bogtha Bogtha
  25. Re:Depends on Usage by RedSteve · · Score: 3, Informative

    They show up in search engines just fine, download speed is a matter of data size not standard compliance as is bandwidth and as well, you can follow all the standards and still not be usable and you can break all the standards and have a more usable site than others.

    I'm working on a redesign of a site that is a perfect example of what happens when you let developers write code that "just works". Our pages are served out of a CMS that is provided by a little company in the Pacific Northwest that you may or may not have heard of (the name starts with 'M' and ends with 'icrosoft'). The templates we currently use are the bastard child of using their out-of-the-box output methods combined with template designers who used every table and spacer widget trick in the box to deliver their templates in as short a time frame as possible.

    According to half the comments I've read in this thread, this is how it should be: we should be focused on the end result for the user, and to hell with standards; they're nothing but esoteric junk that waste back-end developers' precious time.

    Of course, this great time-saving philosophy has resulted in the following results:

    • Template modifications are ridiculously hard to make without breaking the output. Because our template developers nested table after table and inserted seemingly random spacer gifs in order to get the layout 'just right', and then we had to split our template into components to ensure that the right pieces get fed at the right point in the logic, making updates are a laborious, time-consuming chore that regularly break , requiring further break fixes.
    • Our pages are bloated and slow-loading. Our home page is our lightest page, and the HTML document itself weighs in at over 63K -- to present all of 500 words. The bulk of that HTML? Javascript to sniff for different kinds of browsers and to feed dropdown menus. With all the spacers and image widgets, the total page load is over 120K.
    • We have to re-code templates over and over. For every alternate use of the same set of content -- printer-friendly, handheld, audio, braille -- we have to write similar templates that exclude the cruft of the browser-based view. Given our audiences, we cannot ignore these uses.
    • We pay a shitload for traffic. In the case of our home page, we served that page -- and all 500+ words contained upon it -- 670,000 times in the last year. Multiply that by the number of overall pages we serve a year (8.6 million), and our bandwidth costs for serving pages weighing 120-200K each are enormous. Even with users caching previously visited pages in their browser, we still serve a ton of traffic.

    Now, as I said, we've been developing a redesign around standards that should improve our lot in life significantly, and our conclusions have been based on data, not a BS meme.

    • Fact: we will simplify our template files significantly. Without having to dig through partial tables and being able to store semantically significant chunks within the development environment, our developers have to spend less time reconstructing bad HTML to preserve a rickety template. Modification times in development have been easily cut in half.
    • Fact: we will serve less data to represent the same amount of content. Our html files are now up to 1/5 the size that they used to be, and the total size of all associated files for each page are now literally half of what they used to be. We don't sniff for different browsers, and our drop-down menus that once took hundreds of lines of javascript are accomplished with a few :hover declarations in the style sheet in the CSS and a 12-line javascript snippet to make IE behave correctly.
    • Fact: Our redevelopment time will take significantly less time in the future, and will not require us to re-code enti
  26. What about accessibility and disability by Information+Architec · · Score: 2, Informative

    The W3C initiative started out as a concern that geeky sites were fine for, well, geeks but there are a lot of people out there from blind and sight-limited users to more people who just can't stand or get their heads around the shoddy interfaces of poorly designed sites... Thee is nothing on this thread so far about how you address this. Yes many badly designed sites are popular but that doesn't make it right that a substantial proportion of users, or potential users, are effectively locked out because good, accessible design was never thought about at the beginning or, at best, was just a few tweaks bolted on at runtime. The big advantage for Microsoft over OSS is precisely that they can act as a single interlocutor with blind and disabled associations, something the OSS community cannot provide: to paraphrase Kissinger: I'll work with the OSS community if you can give me their phone number... Microsoft does actually test much of its software with such groups but I've yet to see anyone promoting OSS solutions to take that trouble. Call it a market grab if you will, but it seems to make good business sense as well as being "politically correct".