Plone accessibility support

Development Accessibility
1

I am looking for information on the state of accessibility for the Plone CMS. Whereas historically Plone used to be considered the most accessible CMS around, it is difficult to get a precise picture of where this CMS is at today in terms of accessibility support. The Plone website is woefully missing basic information about the accessibility standards it supports and the accessibility statement is shockingly out of date[1]. If I were to believe what it says, Plone has not heard of WCAG 2.0...

Further research has yielded little more, aside from a few Pen State powerpoint presentations[2] from 2011-2012 that discuss WCAG 2.0 and Aria but it is difficult to know what exactly is supported or not and where this work is at.

So, any information at this point would be appreciated.

Best regards,

Catherine

[1] http://plone.org/accessibility-info
[2] http://weblion.psu.edu/symposium/2011/2011-talks/plone-accessibility (there was another presentation but unfortunately, as a new user, I am only allowed two links in my post...)

1 Like
2

Hi Catherine,

let me try to answer some of the questions:

  • Plone has most certainly heard of WCAG 2.0 and ARIA, and is using those as the yardstick for all our development.
  • Lots of progress has already been made on WCAG 2.0, and version 4.3 is supporting this to a very large extent. However, there are some technical issues (we are using <dl> <dt> structures in portlets and messages, which we cannot change within a minor release upgrade, because that would break a lot of backward compatibility).
  • These are not major stumbling blocks for accessibility, but are technically incorrect and will be addressed. For the overall picture, we're doing well on WCAG 2.0 (level AA), at least for site visitors.
  • The story for site contributors and editors is, to be honest, not so rosy, since the current version of our WYSIWYG editor is not compliant.
  • For Plone5, full support for WCAG 2.0, ARIA and, much more excitedly, ATAG 2.0 support are planned, and are well under way. All new themes, widgets, and editors are strictly checked against those guidelines.
  • That includes checks on contrast, colour-blindness, widgets and navigation for the mobility-challenged, people using screenreaders, and other issues.
  • The new version of our WYSIWYG editor has a much improved accessibility story, and it is also easy to include add-ons that will ensure the content in your site will remain accessible. Note that this is technically out of the responsibility of Plone but rather should be done by the organization deploying Plone, but site administrators will be able to enforce guidelines, like making sure all images have an alt tag.

So, in short: on version 4.3, we've done pretty much all we can to improve accessibility and compliance with WCAG 2.0 that is possible without breaking backward compatibility. So, for instance, ARIA roles were added because that is progressive enhancement and can be done without risks, but the erroneous <dt><dl> tags couldn't be taken out.

For Plone 5, we can re-define portlets, so WCAG 2.0 for site visitors and ATAG 2.0 for site contributors are the solid benchmarks that we use.

Hope that helps.

Paul Roeland

2 Likes
3

Thanks for the detail response Paul.

Where can we detail this on plone.org so others looking for this info will also find it?

Would it be okay if I placed it here? http://plone.org/documentation/faq

We could use an "About" section instead of having to dig through the documentation section for info on features for plone. Now I've gotten on a tangent...

4

Yes, that would be a good place. As soon as I get a spare moment, I'll also put it on docs.plone.org.

5

This is a great reply, forgive me for bringing it up again, but can anyone comment on how easy it is to break (or keep) the above accessibility support when using Diazo?

cheers,
Daniel

6

Diazo does not change much in this regard; of course you could break accessibility by using Diazo, you could (if you were evil) filter out any WAI-ARIA roles for instance, which would be bad.

But on the other hand, Diazo makes it easy also to insert said roles into custom portlets or views that don't have them (yet) without touching the source code of those custom portlets or views. Just adding some role=aside to older portlets already improves navigation a lot.

(in theory you could also fix some a11y errors by sticking for instance an extra ALT tag on images, but really that should be caught much earlier in the content creation process. Tools like https://pypi.python.org/pypi/collective.jekyll are much more appropriate for that

So I'd say Diazo is a handy tool to plug in some extra a11y where needed, but yes of course if you go for a custom theme it's your responsibility to make sure you haven't accidentally removed accessibility features.

The default theme for Plone 5 is delivered with Diazo, and should serve as a good place to start. Just make sure when for instance you start moving the navbar around, you move it completely, including all those nice a11y classes and roles that Plone sticks on it.

As for CSS and colors, it's up to you to do contrast checking, obviously. But that hasn't changed with the method of theming.

Paul

1 Like