Accessibility improvement suggestions

Hi, I'm on developing an add-on with the noble goal to be as accessible as possible[1], including fallbacks, if JS is disabled or cannot be used, and stumbled over a few points, which I would like to address, as Plone is advertising itself to be very accessible and used by a lot universities and other public insstitutions, which are besides striving to be noble, luckily also juridically obliged to regard it:

1.) The new keyword-widget is not usable at all, if JS is disabled. Would it be a lot of work to provide a fallback (maybe to the old widget)?

2.) Same goes for @@manage-portlets.

3.) When the focus is in a TinyMCE's text-field, respectively the transformation of it, in its IFRAME, one cannot use the TAB-key to set the focus on the next available field or input-button. There is a plugin out there addressing that[2]. Would it be a lot of work to implement it?

Regards, Ida

[1] I mainly follow the advices given on, as an orientation.

@polyester: Pinging you as the expert for accessibility-matters: Isn't the new keyword-widget breaking accessibility in a non-acceptable way, in your point of view?

No, I don't think so. Basically: you seem to be targeting the group of users that do not want to use JavaScript. Now, the great great majority of people needing AT (Assistive Technologies) have JavaScript enabled, and it's far more important to write accessible JavaScript. Which is a hard enough problem on its own, but has much greater benefits.

There is a group of people not using JS: those who have the NoScript plugin enabled, usually because they (falsely!) assume it will protect their privacy, and those who (partially correct) assume it will make them safer from malicious sites. That, however, has virtually no overlap with the demographic of people needing AT's.
And since you are mentioning the editing-environment, you are really targeting the demographic of "non-disabled people that are suspicious enough of you to keep JS disabled on your site, yet you trust enough to give them editor rights on your site".

Now, I don't know your usecase. Maybe that is a significant demographic for your site, and then you should provide a fallback. Use diazo to do so, would be my suggestion. That is, however, not related to any classical definition of accessibility.

Luckily, since WCAG 2.0, the outdated and counter-productive tick-box of "you have to provide a non-JS fallback for everything" is no longer a requirement. We've moved on from supporting IE6, and we have moved on from following US 508 to the letter where it actually hindered most people it aimed to help.

Now, point 3 in your original question (the TAB plugin) is a great suggestion. Didn't even know it existed. Will look at it once I have a bit more time.


Hi Paul,

thank you very much for taking the time to explain the subject in depth and sharing your knowledge on that matter.

Assistive-device-users who are not using JS are a significant demographic to me, because especially when you're not as mobile as the average, the web can be an important window to the world.

A progressively enhanced widget would satisfy all demographics without compromises.

Another advantage of providing non-JS-fallbacks to me is, that in case JS-bugs occur, a site can still remain usable.
And that happens quite often with JS, probably because where Python-Errors usually force you to fix them before to continue doing anything else, JS-errors are sometimes not even detectable with a debug-tool like Firebug. With increasing complexity comes increasing fragility.

So, to provide the old widget, I could use the schema-extender for Archetypes, unfortunately not with Dexterity, unless that changed in the meanwhile(?).

I wonder what you mean with a Diazo solution, because I need to create a new field, that's not what Diazo is for, non? Or did I misunderstand something.

Regards, Ida

hi Ida,

Without a doubt we all share the idea of supporting accessibility as well as we can; it's the implementation that can be tricky.

Many of the widgets used in the logged-in interface of Plone4 were not accessible at the best of times, and according to WCAG 2.0 it is actually against the guidelines to supply a seemingly-functional, but not really accessible fallback. It's considered better to not provide a fallback in those cases. So, when you want to provide a non-JS fallback, you would have to ascertain that the one you are providing is actually accessible. Otherwise you could be making it worse, not better. I think the German language has the best word ever for that: verschlimmbessern

So 'progressively enhanced' is not necessarily true, as the fallback widget may be inaccessible to start with.

And JS widgets can be a real help to accessibility: predictive ones, like the keyword widget, can help users with conditions ranging from fine-motor difficulties to dyslexia and other cognitive issues.

But if you do want to provide a fallback widget (and again: you would have to make certain that that is actually accessible, I couldn't vouch for our old keywordwidget as it was never properly validated, we only properly tested the anonymous view in Plone 4 and below) you can use Diazo to target it quite precisely and feed in a plain HTML snippet, or could probably use jbot to override the template. Or, provide an alternative widget and specify it in the XML definition of the content-types (for dexterity types).

The field of accessibility is constantly evolving, and I would be interested to see what kind of solutions you come up with; I just want to state that the traditional idea of "JS is problematic, non-JS is accessible" has been proven wrong many times. Of course that does not mean that the opposite is automatically true, just that it is wise to concentrate efforts on what provides the greatest benefits to the largest possible audiences.


Hello Paul, thanks a lot for the helpful pointers, I should be able to get along with them, when coming back to this and will certainly share results.
All the best, Ida

Hi Paul, despite of me having no time to continue on this soon, it would be interesting to know, in what terms the old widget isn't accessible of your point of view, or better where can one read about, what needs to be regarded. Is there a secion about a11y in the docs, so devs can have a guideline? The tests you mentioned would be interesting to see, also, if you'd had a pointer, that'll be great, thanks! But as said, you can haste slowly, of my side there's no current urgency. Regards, Ida

Update: M. v. Rees, recently wrote a summary of a keynote held in Bucharest of M. Nakane, with very good informations and personal insights:
I coudn't find a chapter for a11y in the docs. Hope to come back to it, soon.
And actually there is already an existing post here about a11y, with more helpful insights of Paul:
Cheers, Ida