Summary

The validity of documents on the web is by no means an absolute measure of its accessibility. Validity does, however, provide a solid structure on which to build accessible content. With this in mind, why does the Web Content Accessibility Guidelines (WCAG) working group consider validity to be an ideal, rather than a fundamental principle to guide us to tomorrow's Web?

Author: Gez Lemon

Contents

WCAG Meeting in Brussels

The W3C's Web Content Accessibility Guidelines (WCAG) working group recently had a face-to-face meeting in Brussels. One of the topics under discussion was whether or not to keep Guideline 4.1: Use technologies according to specification. Currently, the level 1 success criteria for this guideline requires that content is valid according to its DTD, Schema, or other tests described in the specification, with a get out clause for backwards compatibility, or compatibility with assistive technology. Following a vote, they resolved to change the get out clause to the following:

Except where the author has documented that a specification was violated for user agent compatibility (including compatibility with assistive technology).

[Back to the contents]

Is Validity Important?

The working group have decided to keep the guideline, but have decided to move the success criteria to level 2, with the following rationale.

  • That well formedness and validity can benefit accessibility. However, forcing strict adherence to the specification can sometimes inhibit accessibility. (Also, validity of any declared specification in and of itself doesn't guarantee accessibility because you could create your own specification and be valid to it.)
  • If forced to strictly use specifications you might be restricted from doing things you want to do that would not be harmful to accessibility.
  • Current WYSIWYG and CMS tools do not necessarily generate valid code, making it difficult or impossible for many authors to meet this SC. (We cannot force authors to do manual coding to conform to WCAG.)
  • There are very strong commercial pressures for tools to include features that are not strictly part of public specifications.
  • We differentiate between well formedness and validity. Well formedness can benefit accessibility. Validity can benefit accessibility though there may be issues. Therefore, for now we have moved validity to level 2. We will also investigate well formedness and expand it at level 1.

How they intend to re-define well-formedness so that it applies to SGML languages like HTML remains to be seen. I've asked for clarification, but as yet I've only had a partial response (I will provide links when the W3C Mail Archives are updated). It's also strange that they're prepared to redefine a term like well-formed, which has an established meaning, but unable to use the word, 'semantic', because the word is used elsewhere in the W3C.

[Back to the contents]

Accessibility and Validity

I don't understand how a W3C recommendation could passively endorse the violation of other W3C recommendations, which is what they are doing by moving validation as a requirement with a get out clause to level 2. If there are supposedly valid reasons as to why a specification needs violating, there is a strong army of people who would be more than happy to find standards compliant methods to make it work. No one is claiming that valid documents guarantee accessibility, but it is definitely a step in the right direction. It is possible to create valid but inaccessible content, but there is a far greater risk that an invalid document will be inaccessible.

Testability is a fundamental software engineering principle. Invalid documents cannot be fully tested, as the output cannot possibly be known as it depends on the error correction capabilities of user-agents, which varies from user-agent to user-agent. We also need to consider user agents that aren't so widely used, and tomorrow's user agents. Almost all developers consider backwards compatibility, but forwards compatibility is often overlooked. Valid markup is just the foundation. Adding accessibility features to valid markup is likely to ensure that content is accessible on today's and tomorrow's web. Moving the success criteria for this guideline to level 2 means that vendors of content management systems that generate broken markup, can legitimately provide their goods claiming the generated markup conforms to WCAG 2 level 1. I don't follow this rationale, particularly as there are content management systems that do generate valid markup. There are also authoring tools that can be used to ensure content is valid, such as XStandard and eWebEditPro, along with tools like Tidy that can be used to clean up invalid markup. Even mainstream editors like Macromedia's Dreamweaver and Microsoft's Visual Studio 2005 can be configured to generate standards compliant markup.

[Back to the contents]

Dealing with Broken Markup

The reason the web is in the state it is at the moment is because browsers work incredibly hard to rectify markup mistakes. If Internet Explorer, still the most dominant browser on the web, suddenly rejected the rubbish that was thrown at it, would the majority of the web still be invalid? Occasionally, I can't help thinking that a lot of people in the web development industry are incredibly myopic. It works, so why does it need changing? It works to an extent on today's technologies, but broken markup is broken markup.

Assistive technology manufacturers would be able to provide much better tools if they were guaranteed that the underlying markup is valid. As they can't get this guarantee, they typically sit on top of browsers that have somehow managed to make sense of what was given to them, knowing that they're at least working with a structured document tree, even if it is slightly broken according to the relevant specification. Why would they do this? Because an incredible amount of work has to go into being able to parse content that is so unstructured, so it's worth riding on the back of browsers like Internet Explorer that is not only the most dominant browser on today's web, but also has adequate funding to be able to invest in parsing almost anything thrown at it to see its competitors off.

But what happens when Microsoft decides it no longer wants to invest in its browser? A year ago, that was the situation we were in. Today, Microsoft has made a commitment to make their browser more standards compliant. What that means in terms of existing content, and how much of a commitment they intend to make remains to be seen, but the point is we shouldn't be in a position that we're relying on one company's commitment to web standards. The whole point of the web was to make an interoperable system that made content available to everyone. The way forward is to demand valid markup, as although it offers no guarantee for accessibility, it's a far more solid foundation from which to build accessibility.

[Back to the contents]

Conclusion

By itself, no content management system will ever be able to create accessible markup, for the same reasons a validator could never ensure the accessibility of a document. The only way to ensure that content is accessible is to understand the underlying principles, and apply them sensibly. If we want a better web, which would be a web that was usable by people regardless of any disabilities they may or may not have, adding those principles on top of valid markup is fundamentally the most sensible way forward. To my mind, WAI should be advising on the way forward, not condoning and propagating the problems of today's web.

[Back to the contents]

UPDATE: WAI Summary

Following the discussions about the impact of validity on accessibility, the WCAG 2.0 Working Draft 30 June 2005 has no success criteria for guideline 4.1 until a consensus has been reached, and have summarised the issues for further debate.

[Back to the contents]

Further Reading

[Back to the contents]

Category: Accessibility.

Comments

  1. [validity-accessibility.php#comment1]

    A slippery slope, a "get out of jail free" card for companies whose products produce crap code. In the process of my work I regularly encounter sites whose invalid code cause issues for assistive technologies and display issues in browsers.
    Why is the WAI going backwards on this issue??

    Posted by steve faulkner on

  4. [validity-accessibility.php#comment4]

    HTML is a W3C recommendation. XHTML is a W3C recommendation. WCAG is a W3C recommendation. If HTML and XHTML are not important recommendations, then neither is WCAG, or any other W3C recommendation. If they want us to take them seriously, they need to take themselves seriously first.

    Posted by Shaun Morgan on

  5. [validity-accessibility.php#comment5]

    This one is a keeper - Testability is a fundamental software engineering principle.

    It's almost like the day that music died... and a step backwards in web standards terms. The dumbing down of guidelines just sends a message to the many teetering on moving forward that they don't have to change their ways because invalid code is good enough.

    Where will we be in five years time without validation? I suggest right here in a lot of ways drinking tag soup. WAI shoots web in the foot!

    Posted by nortypig on

  6. [validity-accessibility.php#comment6]

    steve faulkner says:

    In the process of my work I regularly encounter sites whose invalid code cause issues for assistive technologies and display issues in browsers.
    Why is the WAI going backwards on this issue??

    Great. You have real world examples of invalid markup causing problems with assistive technologies. Post them to the WCAG2.0 mailing list. That's the sort of evidence that will start to convince people of the need to have valid documents for the purpose of web accessibility.

    WAI isn't going backwards. WCAG1.0 had validation as a priority 2 requirement. WCAG2.0 looks to have validation as a second level conformance. Looks the same to me.

    Robert Wellock says:

    They appear to be pandering to shoddy software; it's not at all right.

    The purpose of WCAG isn't to dictate how software is written. Its to bring people with disabilities more equivalency on the Web. As Matt May correctly points out, software should be, and is currently being, tackled under the auspices of the Authoring Tool Accessibility Guidelines - that's the right place to tackle shoddy CMS and other web site authoring systems. ATAG is where you need to focus your attentions.

    Robert Nyman:

    We've gotten so far in promoting web standards, and then they open up for invalid code again. *sad*

    Nothing new has been opened here. Its already open, and has been from the start.

    Gez, I understand and agree with the arguments for requiring valid markup, but they are all from the context of the Web, rather than focused on the narrow confines of web accessibility (as defined by WAI). To be brutally honest, the only serious web accessibility related argument I've seen for valid markup is from Joe Clark who has talked to two screen reader vendors and they both say their screen readers work better with valid markup. But since they already deal with such crap markup anyway, making validity a requirement does not directly improve the accessibility of the web to people with disabilities. And I think that's the key point.

    Concerning the well-formedness versus validity argument, we had almost the same discussion regarding the Atom Format. well-formedness has a bigger positive impact on web accessibility than valid markup. So it makes sense rating well formedness higher up the priority list. As you correctly note well-formedness is a well understood requirement of XML, but not so formalised under HTML.

    Posted by Isofarro on

  7. [validity-accessibility.php#comment7]

    Here is a specific example of invalid markup that makes a page more accessible: http://www.mozilla.org/access/keyboard/tabindex

    Context here: http://www.mozilla.org/access/dhtml/

    It's being added to WHATWG: http://whatwg.org/specs/web-apps/current-work/#the-tabindex

    But as far as I know, this change is not planned to appear in any W3C specification, despite its obvious utility and wide support in existing user agents. To borrow and munge a phrase from the warbloggers, "why does the W3C hate cripples?"

    Posted by Mark on

  8. [validity-accessibility.php#comment8]

    WAI isn't going backwards. WCAG1.0 had validation as a priority 2 requirement. WCAG2.0 looks to have validation as a second level conformance. Looks the same to me.

    Six years ago, the Web was in a terrible state, and validity would have been an unreasonable requirement. Six years later, it's still in a terrible state; hence validity being an unreasonable requirement. When people consider this mess, how much of it is accessible but invalid? The majority of it is inaccessible, and invalid. If I was advising someone on how to make their website more accessible, validity would be the starting point, as you can't go wrong adding accessibility features to a solid foundation.

    The purpose of WCAG isn't to dictate how software is written. Its to bring people with disabilities more equivalency on the Web. As Matt May correctly points out, software should be, and is currently being, tackled under the auspices of the Authoring Tool Accessibility Guidelines - that's the right place to tackle shoddy CMS and other web site authoring systems. ATAG is where you need to focus your attentions.

    There is absolutely no point having tools that conform to ATAG if people aren't going to use them. The different recommendations from WAI should work together, otherwise they're not going to work at all, and surely everyone agrees that they don't work? If validity isn't a requirement of WCAG, developers have no reason to use tools that conform to ATAG.

    To be brutally honest, the only serious web accessibility related argument I've seen for valid markup is from Joe Clark who has talked to two screen reader vendors and they both say their screen readers work better with valid markup.

    It's blatantly obvious that it would be easier to build any user-agent (screen reader, or any other assistive device) if the markup was valid, as there would be no need for error correction. For some reason, people seem to think that error correction is easy. When you think of the permutations there could be, error correction is incredibly difficult, to the point that even the best get it wrong.

    But since they already deal with such crap markup anyway, making validity a requirement does not directly improve the accessibility of the web to people with disabilities. And I think that's the key point.

    What about new user agents? Suppose that tomorrow, you have a great idea for a user-agent that could greatly benefit accessibility. Building a parser that could interpret unambiguous markup is a doddle, but error correction is incredibly difficult. The chances are, you wouldn't be able to build your parser on your own. The way that some assistive technologies work is to sit on top of browsers that have managed to make sense of it, as at least they know they're working with a valid document tree, even if it doesn't necessarily conform to any published specification. The result is that certain browsers remain incredibly powerful, do not conform to UAAG by a long way, and are intrinsically broken. If we want user agents that conform to UAAG, then we need to make it easier to develop those tools. Tools that conform to ATAG, and developers who ensure that content is valid would be a start.

    well-formedness has a bigger positive impact on web accessibility than valid markup.

    Having multiple id values that are not unique is an example of something that could be well-formed, and a real show-stopper in terms of accessibility. The point is that without validity, you just don't know what you're dealing with. It's impossible to cater for every instance of error that could be made. And, of course, there's still the issue of how you apply well-formedness to non-XML languages like HTML.

    Posted by Gez on

  9. [validity-accessibility.php#comment9]

    Here is a specific example of invalid markup that makes a page more accessible: http://www.mozilla.org/access/keyboard/tabindex

    Thanks, Mark. The DHTML Roadmap has been put forward as an example of where breaking a specification can aid accessibility in the WCAG Working Group's discussion list. It's a good example of where the get out clause could be used as an explanation of why a standard was violated, as it's obviously beneficial for accessibility. Thank goodness for WHATWG, who will consider adding attributes that could obviously benefit accessibility.

    Posted by Gez on

  10. [validity-accessibility.php#comment10]

    Six years later, it's still in a terrible state; hence validity being an unreasonable requirement. When people consider this mess, how much of it is accessible but invalid? The majority of it is inaccessible, and invalid.

    How many of those sites are inaccessible _because_ of being invalid? Im my opinion, the number of practically accessible websites outweighs the number of valid websites.

    There is absolutely no point having tools that conform to ATAG if people aren't going to use them. The different recommendations from WAI should work together, otherwise they're not going to work at all, and surely everyone agrees that they don't work?

    No idea, what's the reason behind the belief that people won't use ATAG conformant tools?

    What about new user agents? Suppose that tomorrow, you have a great idea for a user-agent that could greatly benefit accessibility. Building a parser that could interpret unambiguous markup is a doddle, but error correction is incredibly difficult.

    This is a problem I'd be facing regardless if I were building an assistive technology or the next Internet Explorer killer. In this case invalid is indiscriminate, it affects both the non-disabled audience and the disabled audience.

    Posted by Isofarro on

  11. [validity-accessibility.php#comment11]

    Hi Mike,

    Sorry this is a bit rushed, I'm just on my way out to work. You've made some good points, which I'd like to respond to. If I've left anything out, I'll re-post when I get back from work.

    How many of those sites are inaccessible _because_ of being invalid?

    Whilst there's no guarantee that validity will result in accessible content, it contributes significantly, and provides a good foundation for ensuring that the website remains accessible.

    Im my opinion, the number of practically accessible websites outweighs the number of valid websites.

    I agree. And the number of websites that would not only reach a better level of accessibility, but remain accessible, would be higher again if validity was a consideration

    No idea, what's the reason behind the belief that people won't use ATAG conformant tools?

    If you're using a CMS that generates invalid markup, and your goal is conforming to priority 1 issues, there would be no reason to swicth to an ATAG compliant CMS. As invalid content can cause accessibility barriers, remaining accessible is far more difficult when you're not sure of what's coming out of the system.

    In this case invalid is indiscriminate, it affects both the non-disabled audience and the disabled audience.

    Invalid isn't always indiscriminate. There are cases where invalid has a significant effect on people with disabilities. The multiple id values that are not unique is a good example of this.

    Posted by Gez on

  13. [validity-accessibility.php#comment13]

    As I already stated several times, validity must be a P1 criterion. Well-formedness is wish-wash, and not only do we need to support other W3C standards by such a move, we also need to set a signal.

    Authoring tools and their users are an inevitable special case (it's an outlier where it's unrealistic to expect valid, semantic, and accessible code at all.)

    Posted by Jens Meiert on

  15. [validity-accessibility.php#comment15]

    Robert, you could create the same effects using valid markup. The problem isn't invalid markup

    Of course it is the markup that is causing the problem. If blinking content is added with CSS, it can either be overriden or disabled by the user if they prefer. If content moves with scripting, scripting can be disabled. Turn off scripting and CSS and look at the page Robert posted. See the problem?

    Posted by MJ on

  19. [validity-accessibility.php#comment19]

    Hi Gez,

    Whilst there's no guarantee that validity will result in accessible content, it contributes significantly, and provides a good foundation for ensuring that the website remains accessible.

    With my web standards hat on, I fully agree. I'm just not completely convinced it is required for basic web accessibility.

    If you're using a CMS that generates invalid markup, and your goal is conforming to priority 1 issues, there would be no reason to swicth to an ATAG compliant CMS.

    Fair point. Yet, if the CMS is generating accessible markup (albeit invalid), isn't that good enough for the purposes of basic web accessibility?

    There are cases where invalid has a significant effect on people with disabilities. The multiple id values that are not unique is a good example of this.

    Hmm, now that's interesting. Do you have references to more details on the multiple id problem that I can have a read of.

    Thanks - and have a great weekend.
    Mike

    Posted by Isofarro on

  20. [validity-accessibility.php#comment20]

    Of course it is the markup that is causing the problem. If blinking content is added with CSS, it can either be overriden or disabled by the user if they prefer. If content moves with scripting, scripting can be disabled. Turn off scripting and CSS and look at the page Robert posted. See the problem?

    No, I don't see the problem. You can turn off BLINK and MARQUEE aswell, so then that document would in fact be fairly accessible, with your reasoning. [http://www.mozilla.org/support/firefox/tips#lay_blink]

    Take this very document, and change the DOCTYPE declaration to: 

    <!DOCTYPE html[]>

    Would the document be valid? No. Does it hurt accessibility? No.

    Posted by zcorpan on

  21. [validity-accessibility.php#comment21]

    Hi Mike,

    Fair point. Yet, if the CMS is generating accessible markup (albeit invalid), isn't that good enough for the purposes of basic web accessibility?

    One of the worst examples of a CMS that I've encountered was ironically built to produce both valid and accessible content. The developers had a relatively good grasp on accessibility, but poor coding and testing skills. Whenever an image was loaded, the user was prompted for the alternative text. The users were entering things like: Interest Rate "24%". The CMS developers had forgotten to encode the attribute, and the result was something like: 

    <img src="/img/rate.gif" alt="Interest Rate "24%"">

    The result is that the most important information is lost, yet this passes most automated accessibility validators. If the output is invalid, it cannot be tested properly, as all of the outcomes are not known. This example isn't limited to bespoke CMSs; widely used CMSs generate output that is both invalid and inaccessible.

    If you could guarantee that invalid markup generated by a CMS was always accessible, or at the very least covered all of the priority 1 success criteria, then I would agree with your assertion. Priority 1 issues should be the things that are absolutely fundamental for accessibility. If they could be guaranteed with invalid markup, then I would support putting validity at priority 2, or at the point where it caused problems. If validity didn't cause any problems whatsoever, I wouldn't even see the need for adding validity at any level for accessibility. What I can't get to grips with is how anyone can guarantee something that they can't be sure of. The example here is an example of something that would pass most automated accessibility checkers, but fail a markup validator.

    Do you have references to more details on the multiple id problem that I can have a read of.

    Sailesh Panchang posted an example to the WCAG 2 mailing list. I've included his whole reply, as it's relevant to this discussion:

    Last week I gave an example of a complex data table marked up with headers and id- apparently OK at first sight. But as the values of id attribute were not unique on the page, the page failed validity test. Screen readers and self voicing browsers did not forgive this lapse and did not associate data cells and header cells as expected. How would one regard this problem? "A little problem" from a validity standpoint? Accessibility eval tools do not check for validity problems that result in accessibility problems. So if one does not validate the page before running it through an accessibility eval tool, the problem will go undetected. It is high time that validity be taken more seriously. It is only in authoring Web content invalid code or syntactically incorrect code is acceptable. Other programming languages do not allow even a missing comma or semi colon, etc. The same standards need to be enforced here now.

    As well as the problem outlined by Sailesh, it's also applicable to forms. If a label is associated ambiguously with a form control, which one should it be applied to? Practically, it tends to be associated with the one defined first. This type of error affects those using screen readers, and also people with mobility difficulties, as the target area for small form controls, such as checkboxes and radio buttons, isn't associated with the correct prompt.

    Anyway, I'd better stop rambling as it's getting late :-) Have a great weekend.

    Cheers,

    Posted by Gez on

  22. [validity-accessibility.php#comment22]

    Hi ZCorpan,

    No, I don't see the problem. You can turn off BLINK and MARQUEE aswell, so then that document would in fact be fairly accessible, with your reasoning.

    I'm sorry, but MJ's comment is a valid comment. Being able to turn it off in a particular browser isn't a case for invalid markup.

    Take this very document, and change the DOCTYPE declaration to: 

    
<!DOCTYPE html[]>

    Would the document be valid? No. Does it hurt accessibility? No.

    This is exactly the type of argument that's been put forward on the WCAG mailing list. There are countless validity errors that would not have any impact whatsoever on accessibility. If all of them didn't have an impact on accessibility, I would never have made this post in the first place. The fact is that you cannot be sure what you are dealing with if the content is invalid, and some issues do cause real accessibility barriers. To put this in context, do you think WCAG should have dropped a requirement for equivalent text for images if someone presented an image that was purely decorative?

    The problem here is that unlike images, where authors can discriminate between images that are decorative and those that aren't, it's not possible with validity, as you couldn't possibly cater for all the possible permutations. Validity errors are typically compounded.

    Posted by Gez on

  23. [validity-accessibility.php#comment23]

    As someone who daily develops content to be accessible by a wide array of users, validation of code is esstional. The problems is that so many non-developers are delegated the job of using tools like Frontpage and Dreamweaver to build sites without knowing the fundimentals of core code. I work for a state rehab agency and so much of the content is developed this way that it is very disturbing.

    Accessibility is an afterthought to many of these people so they have no reason to understand the importance of validating code.

    True, validating code does not mean it is accessible, but try making it accessible WITHOUT validating it.

    Posted by Jess on

  24. [validity-accessibility.php#comment24]

    I'm sorry, but MJ's comment is a valid comment. Being able to turn it off in a particular browser isn't a case for invalid markup.

    So how do you turn off CSS in Internet Explorer? Yes, you can override it with a user stylesheet, but does the general user know how to do that? Does the general user know how to disable scripts?

    If I write a DTD for that document so it validates, does it improve accessibility?

    Posted by zcorpan on

  25. [validity-accessibility.php#comment25]

    If I write a DTD for that document so it validates, does it improve accessibility?

    I didn't think I could have made my position on this issue clearer, but comments like this make me realise that I've failed by a long way. If you write a custom DTD, at the very least it will be well-formed; it won't necessarily aid accessibility (but you could add accessibility features if you felt so inclined), and you could potentially harm accessibility, but that's what the other guidelines are supposed to safeguard against. Just to clarify my position on this issue, so that I don't end up with 1,001 examples of where validity has no impact on accessibility:

    1. Validity does not guarantee accessibility, but it does offer a solid base upon which to build accessibility.
    2. Not all validity errors will result in an accessibility barrier.
    3. Some validity errors can and do result in accessibility barriers (this point is very important).
    4. Being valid and semantically correct in and of itself does not cause an accessibility barrier.
    5. Being valid and non-semantic may cause accessibility barriers, but are not fixed when the document is invalid.
    6. If we want accessibility to be considered from the ground up, rather than as an after-thought, validity should be a consideration. When validity is an issue, it has to be considered in stages, because developers are quickly aware that these issues become compounded, and difficult to rectify in retrospect.
    7. If validity is not an issue, it can encourage accessibility to be considered as an after thought. When accessibility is added as an after thought, it's typically accessible for a short while, and broken quickly as the site is maintained. If no one has ever come across this situation, and has worked in this industry for more than a year, I will eat Matt's hat, and both of his shoes (providing he's finished with them and in agreement).
    8. Testability is impossible when the output is unknown.

    I'm interested in ensuring that accessibility is as easy as possible to implement and maintain. Anyone with a background in software engineering will appreciate that maintenance is the lengthiest, and most difficult part of the software lifecycle to control. If accessibility is important, it's important all the time, not just when someone highlights another error that's got through and someone finds the time to fix it. I don't have a vested interest or ulterior motive, other than in the interest of accessibility. If anyone has valid arguments as to why validity is harmful to accessibility in a way that an invalid document isn't, please share your thoughts. I've read and am familiar with the counter-arguments, and I just don't buy them. Not only do I not buy them, I've attempted to include them here and provide rational and reasoned arguments as to why I don't buy them. Rather than picking away at the edges, I would really appreciate reasoned arguments as to why I'm mistaken in my beliefs.

    Posted by Gez on

  26. [validity-accessibility.php#comment26]

    You suggest that developers are myopic... and perhaps a lot of those who don't make their living at this ARE myopic.

    But in the end, I have to ask... where's the money? The answer to that question tells me where the myopia's at, in descending order of influence:

    - Typical stakeholders. Faster, better, cheaper, pick two, and "better" gets left out every damn time.
    - Code investments. Remember that system your client or employer spent thousands of man hours and hundreds of thousands of dollars putting together? The RP doesn't ****ing CARE if a properly built system only has a fraction of the TCO of the one that's already in place, because by commissioning a new project he's losing face.
    - The vicious cycle between WYSIWYG environments and crap browsers. The word from Macrodobe is that they're working hard, but the fact remains that they're working from a source repository containing code that was originally meant to deal with the likes of Netscape 4. As in the case of Netscape 4 itself, I'm not convinced that "newer" will always mean "better."
    - Standards awareness, which is a lot better than it used to be. I don't recall finding (much less looking at) any standards docs until I'd been churning out markup for at least six weeks, and my first response was to start following them in spirit as best I could. Where does this leave a schlemiel who lives in a bubble, or a schmuck who takes the path of least resistance toward a fat paycheck?

    That means a lot of leaps need to be made with client education, the dev community needs to become a lot more politically savvy, and Microsoft (as worst offender) needs to get their act together, one way or another.

    Posted by ben on

  27. [validity-accessibility.php#comment27]

    Yea Ben Microsoft needs to get there act together but alot of companies are willing to spend that extra buck now adays when it comes to thier internet website and presence.Now back in the 90's making a great website was no less than $200,000 and ateam of people to get behind it but now one person can create a great and validated website with ease.

    Posted by Ashley Bowers on

Comments are closed for this entry.