[I had originally planned to just comment on my question, but what I wrote in a related email discussion sort of didn’t make sense. So let me write that down here too. So these really are just unorganized random thoughts.] Let me comment a bit on the question I posed near the end of the webinar, which ended up being literally the last question that got through: “What best practices would you recommend if the design had to work with a CMS hostile to doing things semantically?” This is, of course, a real example, one that I had already mentioned previously. In this particular case, which is a different case than what I had blogged about last time, what I found was that the CMS was so hostile to authors that I could not even get Microformat 1.0 content (dtstart and dtend specifically) to stick. Let us think a little bit here: Microformats are designed to work in pretty hostile environments. But in real-world environments that some designers have to work within, not even Microformat markup can survive. How can HTML structural elements survive? The answer is they don’t. I was not talking about environments where the the designer has the power to reconfigure the CMS (if so the question would have been moot); I was talking about situations where the designer is working with a non-technical client (with a CMS created by someone else) who has neither the technical skills to even go to the Administer screen nor the financial resources to hire someone to reconfigure their CMS. But they’ve already budgeted the money to redo their CMS—which you have no influence over either. I’m talking about a 100% hostile situation which you have no control over whatsoever. So what do we do in such cases? When people talk about making existing sites accessible this is the reality. Whether the CMS in question is WordPress or Drupal isn’t really relevant; in this particular case the hostile CMS is actually Drupal, but you can’t reconfigure it. In any case, I think the RGD is doing meaningful work in the accessibility area. A few days ago on an email discussion I actually cited RGD’s AccessAbility handbook because the RGD is actually one of the very few organizations that are not buying into the myth that print accessibility equals “large type size.” But someone disputed RGD’s ability to create accessible PDF files because the “accessible PDF” version of the handbook was not produced by the RGD but by an outside contractor. While the latter is true, I think, to be fair, this need to be put in some context. First of all, producing an accessible PDF from InDesign is not straightforward, and the steps Adobe documented (the same steps described by ADOD) do not actually work, and I can say this because I tried it when I did my issue of Cadmium (the OCAD SU zine that’s no longer being produced) and verified that the documented procedure did not in fact work. The other thing, which is quite tangential, is that (I might add having Accessibil-iT do the final work does not prove that RGD does not have the capability — it’s normal for graphic designers to contract out non-core tasks anyway —, but that’s not the point I’m trying to make) RGD has raised some points that do not seem to have been addressed by most other people talking about accessible print. So they are tackling a conceptual problem, with the appearance (let’s say this for the sake of argument) that they might not have the best practical skills (or craft). As our chatting at a pre-DesignThinkers student mixer two years ago showed, this is actually very “OCAD.”