To-do list for the WaSP ATF

The recently formed and announced Web Standards Project Accessibility Task Force will work with accessibility organizations, technology vendors and others to help promote Web accessibility. An excellent initiative that I hope will turn out well.

The Task Force members also want suggestions on what they should accomplish, and I’ve been thinking a bit about this for a couple of days now. Joe Clark has already posted ATF: Not ‘Alcohol, Tobacco & Firearms’, a comprehensive list of areas to work on. I’ve tried to avoid repeating what he has already said, so here’s my slightly shortened to-do list for the WaSP ATF:

Unite the people

If you’ve been following some of the recent discussions on accessibility, web standards, and validation, like me you probably feel that there is a bit of tension within the fields of web accessibility and web standards. There are several reasons for that tension:

  • Many screen readers users are stuck with old versions because they are too expensive to upgrade and don’t benefit much from semantics and structure.

  • Labels that certify web sites as being “blind friendly” can give the wrong people the impression that web standards are unimportant when certification is given to sites that do not follow best practices in modern web development, accessibility, and usability.

  • Standardistas that want to promote both web standards and accessibility sometimes forget (or don’t realise) that validity alone is no guarantee for accessibility.

  • Some accessibility evangelists focus more on specifically supporting people with disabilities than device independence and accessibility interpreted as “for anyone, regardless of any disabilities they might have and no matter which device they use to access the web”.

All of these views, needs and opinions have to be taken into account and made to work together. Fighting each other won’t improve things. The WaSP ATG could help here.

Make CMS vendors fix their software

Really heavy pressure needs to be put on CMS vendors. Most (nearly all) CMSs are lagging way behind and need to be brought into the 21st century. We need content management systems that produce valid, well-structured, and strict-flavoured markup instead of presentational tag soup that only IE/Win can eat without getting sick.

CMSs should also make it impossible for content authors to enter markup that is not well-formed and warn authors of any validation problems. See XStandard for a good example.

And then there’s the backend: CMSs should be able to run on servers other than Microsoft IIS, and their administrative interfaces need to start working in other browsers than Internet Explorer for Windows. Come on now, it’s not that hard.

Educate content authors and editors

We need to make content authors and editors aware of and understand web accessibility. Putting pressure on CMS vendors to improve their tools is important, and better tools will help but won’t be enough. Content management software should assist and guide authors as much as possible, but by itself it won’t be able to make content accessible.

The humans entering content into a CMS need to understand what they are doing and why. The same goes for those who actually write the content. Writing text that everybody can understand is no easy thing, and very few content authors even know that it’s something they need to think about.

Posted on June 26, 2005 in Accessibility


  1. Roger,

    …their administrative interfaces need to start working in other browsers than Internet Explorer for Windows.

    Definitely. I can’t belive that they’re not doing that already.

    In my job, the CMSs are the major reason holding me back from delivering both accessible and valid web sites (and it’s good that you point out that those to aren’t the same thing, nor does valid web sites automically become accessible).

  2. Your’s is another good list of issues that need to be looked at by the task force. I don’t envy their job though as it’s going to be hard to satisfy all people. But I think there needs at this point in time to be an ititiative like the ATF.

    I think there needs to be clarification and demystification of accessibility myths, too. Identify them and move on. It’s not about moral high grounds in the trenches but about having a workable set of guides and supportive information that work in real life. It’s also about direction. I generally merge the web standards and accessibility under best practises - but they seem to be in some ways not necessarily compatible. If my CSS doesn’t work in assistive technology I really need to know and be able to make informed decisions.

    My recent concerns about the state of accessibility guideline changes was less about the issue itself, validation, and more about the message that is being sent that bad practise sites are as good or better than best practise sites. Also, that if industry holds off then the guidelines will dumb back to their level anyway. Unfounded or not.

    But yes a lot of this is probably over my head and I can only comment in generalities. I agree, if XStandard can do it why can’t the others? And education is the key. We need to identify what the best practise is and make entities aware of it on all levels.

    And a good definition of what accessibility is would be nice as there seem to be numerous interpretations. If I don’t know the goal to kick to then how can I score?

    Great article, Roger. Cheers.

  3. Just to offer some insight: XStandard solves the problem through a browser plugin. Something which is just not very practical in some organizations. Think of the installation and maintenance costs on top of the licensing costs.

    The reason a number of CMS’s are IE/Win only is because of the DEC/MSHTML. It’s functionality that has been around since IE4. It’s already built into the browser and offers scripting possibilities that can mimic most desktop tools (I should know because I’ve developed such tools). That type of functionality has only recently been available via Mozilla and Firefox’s technology called Midas.

    Therefore, it takes time to A) realize that the technology even exists and B) to implement it.

    Having developed for IE, I find that the Midas engine is just not as good as MSHTML. The Mozilla team also could have done a much better job at mimicing IE to make it easier for developers.

    In any case, there’s certainly a potential for a CMS vendor to enter the market, focused on these types of issues and come out as a market leader.

  4. Browsers other than IE I understand, but where does the choice in web server come into it? I can’t see where that is an accessibility issue.

  5. “CMSs should also make it impossible […] to enter markup that is not well-formed and warn authors of any validation problems.”

    Warnings would be great. You might annoy some people into learning enough to not cause the warning again. Impossible will just plain piss them off. The first result of that will be a rapidly-adopted plugin or hack that cripples the function.

    Wouldn’t it be more appropriate to start a campaign targetting publishers instead? I don’t think it’s correct to essentially make CMS vendors enforce editorial policy, which is the actual problem here. I believe there’s a law about applying technological solutions to social(/people) problems. Can’t remember the name right now. Anyway, the issue seems to me more that many publishers are in denial of the fact that their writers are not only writing for, but in many cases on the web, ie: when they hit “Publish” it actually goes public without any review of markup(and sometimes content, for that matter). And if an editorial process does exist but doesn’t check markup, there’s no excuse. The content management—not validation—system shouldn’t be responsible for this. It shouldn’t even care. It just has to keep track of the content and juggle it around, not judge whether it’s any good. Of course, lobbying vendors for development of a standard configurable plugin or extension to the same effect, sure.

    Also: What if the ill-formed/invalid markup is an example? Are you going to additionally require vendors to implement some special “overlook this” tag to be used within content(something that not all CMSs do or necessarily should support), and then require their users to learn it?
    Yes, those things should probably go in a PRE tag, but even if you teach the CMS to recognize “stuff that looks like markup,” for it to make that suggestion, you’re starting to wander into the land of Clippy, which brings us back to pissing people off.

  6. Su - don’t confuse “not well-formed” with “invalid”.

    Well-formed markup (assuming we’re talking XHTML) is things like closing all elements, uses & instead of &, enclosing attribute values in quotes, nesting elemets properly, etc. Such technicalities should be invisible to most CMS users if they’re using some kind of WYSIWYG interface, and can thus be vigourously enforced.

    Valid markup includes considerations such as which elements can go inside which others, and require more awareness on the part of the user. Warnings may be more appropriate for validation failures than outright rejection.

  7. June 27, 2005 by Roger Johansson (Author comment)

    Jonathan: Yes, I realise a plugin can be a problem. I mentioned XStandard as an example to show that it is possible.

    The IE functionality is nearly always used for WYSIWYG editors, but why not let other browsers do everything else? If you can’t make a WYSIWYG that works everywhere, how about offering a fallback to Markdown or something similar? Much better than requiring a specific browser on a specific OS.

    Richard: Well, no, the server side stuff doesn’t really affect accessibility. It sort of slipped in when I was arguing for cross-browser functionality.

    Su: Chris explained my standpoint. Require well-formedness, warn about invalidity. Offer to correct both if possible, similar to what HTML Tidy does.

  8. I just wanted to add my pain to everybody elses. I am just finishing work on a huge CMS job with over 5000 pages which I have lovingly crafted to validate and conform (as much as is ever possible) to WAI guidelines. However I feel like I have wasted my time as I know the minute the client starts editing it with the CMS WYSIWYG editor it will turn into HTML soup. XStandards is great but it doesnt fit every situation (for example shared hosting environments) and there should really be more than a choice of one! Please somebody take my money and give me a web standards, accessible friendly WYSIWYG editor!

  9. June 27, 2005 by Anonymous

    I really hope this initative will create more accessible web sites. Regarding CMS manufacturers my hope is that more of them start looking at the ATAG 2 recommendation.

    The problem is that there are accessibility consultants that have advised CMS manufacturers against following the ATAG recommendation. I guess they are afraid that it will ruin their market…

    How can you help? One way is to contact your government representative and ask them to make sure that the government requires ATAG 2 compliancy when buying CMS tools.

    Or, adopt your open source CMS tool of choice and start submitting patches.

    Or, send an email to your CMS manufacturer and ask them why the hell their tool prevents you from building web sites properly.

    I guess if we all did this at the same time we could at least make a dent in some beard room agenda.

    This isn’t rocket science, but I choose to post anonymously to keep my employer’s CMS partnerships out of harm.

  10. I hate it when arguments end up being based in grammar. My personal punctuation would’ve put a comma before the and in this: “[…]to enter markup that is not well-formed and warn authors[…]” which read like a single statement to me, as no validator I’ve ever encountered actually points out the distinction between the two when yelling at me.
    Suffice to say it looks better to me now, although I still think the aim should be placed directly on publishers, also. It’s nice to make the programs able to deal with whatever gets thrown at them(part of the reason we’re talking about this is that’s exactly what browser writers did), but the fundamental goal should be to not have garbage going in in the first place.

  11. Roger: the problem in offering a fall back to HTML or Markdown code is that it is entirely unintuitive to the average user. We, as developers, can jump into some HTML or markdown code with ease. I couldn’t imagine trying to explain any of it to my mother! In addition to that is the training issues: “This is how it works…well, except if you’re not using Browser X, then it does this.”

    In any case, I’m not trying to defend CMS developers, just merely trying to shed some insight on the subject. There are now a number of editors on the market like htmlArea and FCKEditor that should certainly make things easier for CMS developers.

  12. June 28, 2005 by Roger Johansson (Author comment)

    Anonymous: I think very few CMS vendors have even skimmed through any ATAG document, so that would be a good start.

    Accessibility consultants advising against following ATAG… after thinking about it for a while I’m not all that surprised. After all, there are plenty of Accessibility charlatans out there.

    Good suggestions on what we can do.

    Su: Maybe there should have been a comma there. Sorry ;-)

    And educating publishers is the way to go. The tools should be there as support and backup.

    Jonathan: Yes, I know what you mean. I still think a fallback is better than not being able to use the CMS at all.

  13. I’ve been having a look at ATAG 2 this morning. I must say that I am far from keen (might be down to lack of coffee), it looks more like a description of a tool than a set of guidelines from which tools can be built in all shapes and sizes.

  14. Richard: ATAG 2 looks like a vague specification at first. But, if you have an ATAG 2 compliant CMS it will (among other things):

    2.1 Support formats that enable the creation of Web content that conforms to WCAG.

    2.3 Ensure that when the tool automatically generates content it conforms to WCAG.

    3.1 Prompt and assist the author to create content that conforms to WCAG.

    This would help the accessible web become a reality and transfer knowledge of accessibility features from forums like this into the hands of content editors. I am all for that.

  15. Don’t get me wrong, I believe any steps towards accessibility are worthwhile. Just wasn’t sure about some elements of ATAG2 pre-coffee this morning.

    I have set myself 30 mins or so sitting in the sunshine this afternoon to go through the proposed standard properly.

  16. June 28, 2005 by Andrea Martines

    My personal contribute to the to-do list: promote and give support to accessibility integration in the Asinchronous web applications community. Ajax accessibility is a real emergence the ATF should face, before vendors switch from an accessibility fixable (in many cases already fixed) CMS generation towards a forthcoming structurally unfixable new CMS generation of Asinchronous tools. Libraries and best practices are to be discussed and established right now, when frameworks are still young and fluid, or the gap between the two worlds will rapidly grow, forking the paths of usability and accessibility.

  17. Agreed, ajax developers need to consider graceful failover in the like of accessibility issues.

  18. June 29, 2005 by Marcus Maher

    To this day the best CMS I’ve seen is well written PHP. A good developer can build a better CMS than any 3rd party system tried and failed in the office.

    The same way we have chunks of code for complient front ends we have the same in PHP and like the front end code it’s in chunks, cut, changed and used again. The same attention we give to the front end standards should go for back ends too.

    We’ve moved from front end (on)WYSIWYG sites to easily written/updatable, working sites used the world over as valid templates, why not the same with web languages other than XHTML and CSS?

    They’re languages for a reason, surely?

  19. June 29, 2005 by Kalle Wibeck

    Actually there great initiatives on the .Net platform as well.

    Read this blog entry from Umbraco’s Architect, Niels Hartvig: Getting your priorities right

  20. “Make CMS vendors fix their software”

    Why not better

    HELP CMS vendors to fix their software”

    Check a similar discussion, see last comment Posted by: Franck at June 20, 2005 04:25 PM

  21. Using eZ Publish, or Drupal it’s pretty easy to make sure that valid XHTML is outputted.

    I disagree that you should enforce compliance above all else, as not all CMS solutions are designed just for web publication. Only web CMS solutions are — many Enterprise CMS solutions publish to many output formats. Major changes to these systems is more gradual.

    Still I have to admit that change has been too slow in the Enterprise CMS space.

    There are a myriad of systems that already do what you’re asking for however.

    Check out:

    With most CMS systems, it’s merely a matter of workflow to attach an XHTML validation to the submission action (or similar action). It’s generally similar in enterprise CMS solutions. Unfortunately, even though the source code is available, a validator is not built into any system I can think of.

    What would be more helpful is for people in the respective user communities to embrace educating the user base on these issues, and how to implement foolproof solutions for web standards compliance.

    Perhaps it’s time to start an effort to rate CMS solutions on their ability to generate web standards code. In fact, if this was done, it might turn standards compliance into a competative advantage — it’s not even listed on, the list, or oscom’s list (

    Seems like there is a need for a little deeper digging. Get in touch if you want to build something — I’d like to.


Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.