According to Peter Abrahams, Section 508:

only considers the accessibility of the product and not the accessibility of any outputs of the product. This means that website development tools, Content Management tools, document creation tools or any other tool that produces output that may be viewed electronically can conform to section 508 but none of their outputs do.

A few years ago most CMS products were atrocious both front and back end, providing hard-coded tag-soup and inaccessible interfaces. (From a personal point of view, that is what lead to the development of Defacto, consider that my bias.)

However, most CMSs have improved on the front-end, allowing developers to create websites that don’t break all the WCAG guidelines. (Although often they put a lot of obstacles in the way, and developers don’t always manage to get around them.)

What is almost a universal failure in the CMS market is the authoring interfaces. I’ve tested many, and the bigger the name, the worse the accessibility of the back-end is.

Maybe things are different in the US market, but somehow I doubt it. CMS vendors have conglomerated quickly in the last few years, and interface quality does not seem to be the deciding factor in which survive. Generally the accessibility of the authoring interface is overlooked by almost every buyer, except the more stringent Government or Disability Charities, who then discover they have no choice but to buy inaccessible software.

Perhaps there is a hole in the Section 508 laws, but the result isn’t what Mr Abrahams has suggested, and I’d recommend checking into the lesser know but just as important Authoring Tools Guidelines.

The article implies that CMS vendors have no need to worry about the websites that are produced by their product. However, what has been effective is the commercial pressure of their clients demanding the ability to create accessible websites. Publicly facing websites are highly visible, if only that sort of pressure could be applied to the back-end interfaces, we’d have many better CMS products.

'str' object has no attribute '_default_manager'

On my local development server it was working fine, when the payment was confirmed the event saved the relation to each member.

The relevant bits of the models were:

class Event(models.Model):
   ...
   entrants = models.ManyToManyField("members.Member", blank=True, null=True)

class Payment(models.Model):
   ...
   events = models.ManyToManyField("events.event", blank=True, null=True)

Can you see the error? The views worked fine locally on the development server, saving the payment and adding the members to the entrants list of the event.

However, on the live site (Apache & mod_python), it would give a type error:

'str' object has no attribute '_default_manager'

Confused, I asked on IRC, but apparently this sort of error is usually from having different code between local and live. I’m running from an SVN repository, this didn’t seem likely.

The other clue I had was that the admin area would give me an error when trying to look at payments. So, looking carefully at the model I spotted my mistake:

events = models.ManyToManyField("events.event", blank=True, null=True)

Capitalisation! The ‘Event’ is the model name, and should be capitalised.

It’s just strange that the local server didn’t pick up the same issue?