This helped, thanks!

In this post, you have come to recognize a different aspect of accessibility—the issues of accessibility we encounter when we deal with authoring tools.

From the standpoint of the developer, there are two issues:

How can I make this tool accessible to everyone?
And how can I help the people who use this tool create accessible content?

On a small scale, this is about a module that does one thing well. For the sake of having something simple to discuss, let’s say our module can be used to add images to a blog.

So first we would ask whether our module is accessible. It might call for the user to make a number of choices—what types of images they want to be accepted, image size, file size, and many other factors. To make these choices, the user would have to complete a number of form fields. Can the user reach each field with the tab key? Can screen readers recognize and announce each field’s label and, if it’s a list, the contents of that list?

To achieve these aspects of accessibility, we would refer to and try to conform with the Web Content Accessibility Guidelines (WCAG), which currently are in version 2.0. (I hope all your readers know of WCAG 2.0.)

Then we would have to ask whether our module helps all users create accessible content. If the user is placing images in a blog, those images might need captions, descriptions, and alt text.

“Might” is an important word here. There’s no way we can tell whether a given image needs to have a caption, a description, or alt text. It all depends on the context of its use. So we have to make it possible for our blogger to give each image a caption, description, and alt text—but we can’t force them to do so. By giving bloggers these choices, our module would help people create accessible content.

“But wait!” some readers are saying, “For accessibility, doesn’t every image need alt text?”

No, not alt text—but every image does need an alt attribute. So when the blogger leaves the field for entering alt text blank, our module should make sure that the image tag has an empty alt attribute: alt=”".

That might not be right for a chosen image. But the error would be the blogger’s. Our module would have responded correctly to the information given by the blogger.

So the best our module or any other authoring tool can do is to produce the right output for the information a user enters. It can’t force the user to give it the right information.

WCAG 2.0 does not address this aspect of accessibility and authoring tools. For that, you have to go to a different set of guidelines—the Authoring Tool Accessibility Guidelines (ATAG). These guidelines call for an authoring tool to, first, be accessible and, second, as much as possible support authors in creating accessible content.

ATAG 2.0 is currently in development, and you can actually help move it along. The W3C Web Accessibility Initiative working group that is developing these guidelines needs examples of two successful implementations of each guideline. You don’t have to prove successful implementation of all of ATAG 2.0—just of any guideline that you feel your authoring tool implements successfully.

And they’re pretty flexible about the concept of an authoring tool. It could be WordPress alone, or WordPress plus your plug-in, or WordPress plus your plug-in plus two other plug-ins, and so on—whatever combination it takes to meet that guideline.

And you know what? Even if you fall short of meeting any of the guidelines in ATAG 2.0, testing your plug-in against those guidelines would give you clear goals for improving its behavior and performance with respect to accessibility. And it would help you document specific cases where WordPress (or another plug-in) is falling short of all you would like it to be as an authoring tool.

Good work—and good luck!