When I started to write WordPress plugins, I had the idea that I could expect my users to know how to write HTML (HyperText Markup Language). I made no effort to provide any kind of visual editing experience. Over time, my expectations and the audience have changed, and I do routinely incorporate the WordPress visual editor into plugins.
I still can’t stand visual editors; they make the whole authoring experience immensely slower and more complex, from my experience. But that’s just me – and as long as I can disable them for myself, I don’t want to control what people do with their editing experiences.
But a prevailing idea for WordPress plugins and themes is the expectation that a person should not need to know any code at all to create a web site. I don’t think that my early ideas expecting HTML knowledge are valid, but the idea that any editing tool can completely substitute for some basic knowledge about coding feels unrealistic.
Accessibility suffers if there’s no expectation that the person publishing content needs to know some underlying characteristics of the code.
Tools provide methods, not reasons
Even if your editing tool provides the possibility that you can create accessible content – videos with captions, images with alternative text, or tables with appropriate column and row headings, it adds an enormously more complicated problem for it to also explain why to make your content accessible and when it is appropriate.
A table management tool can allow you to define a cell as a heading, and it can allow you to indicate whether that heading references a row or a column. But if it starts to get into the position of also explaining what your reasoning should be in making that decision, you’ve got a problem interface. The more rules and explanations you add, the more likely you’ll have problems. Verbosity is not a solution.
You can’t solve this with defaults – you can set defaults, but it’s not an improvement for a table to have a heading row of column headers if the actual content requires row headers. An automated tool might then identify your table as correctly marked up, but it’s actually making the content more confusing to assistive technology.
Alt attributes for images are an example of an edit that requires knowledge. In a visual editing experience, you can add alt text. Once completed, you don’t see any evidence of your change. If you don’t know what alt text is, you might decide this isn’t a needed task.
Writing correct code is hard
Using a tool to write code can make certain that your code is consistent and correct. If the tools are adequate, you can be certain that you’ll never miss key elements.
So those tools that I was just condemning also have great value – even to people who have a lot of experience. I have absolutely created tables that had an accidental extra cell in some rows, just because I wasn’t typing carefully. A tool that generates the code for you can ensure precision.
From the perspective of somebody who passionately cares whether or not the content you write is marked up correctly, this is a difficult situation. Given an ideal scenario, I want a tool that provides the complete spectrum of options for generating code patterns and an author who knows how to make the best choices using that tool.
I know that this is not a truly reasonable thing to expect, however. This is where I hope a tool like Access Monitor can help fill in gaps. A forward-thinking plug-in that analyzes the code created can potentially help less experienced authors fix errors, as long as the editor generates editable code.
A new editor for WordPress
The whole process of looking at Gutenberg, the proposed new editor experience for WordPress, raises a lot of questions for me. You can certainly switch between Gutenberg and a text editor – but if you’re using Gutenberg, it’s going to add a lot of new clutter to your code. You get a decreased need to know code in Gutenberg, but an increased level of challenge without it.
There are a number of outstanding concerns with Gutenberg, but this isn’t really a post about Gutenberg – it’s really about the entire concept of editing designs and content without needing to know code. (I’ll write a post more specifically about Gutenberg later.)
The democratization of publishing is one of the fundamental concepts driving WordPress. Anybody should be able to publish content using WordPress. Everybody should be able to author good content even if they don’t know how to code. They should also be able to author good content if they can’t see. Or if they can’t use a mouse.
What about the readers?
The democratization of publishing doesn’t matter to me in any way if the content produced can’t be consumed by everybody. This is why I care about whether the tools provide the ability to create accessible content effectively.
- Video: Upload a caption file with your video. When you upload a video, the editor should prompt you to add your caption file.
- Images: The editor should prompt you to add alternative text with your image.
- Tables: The editor should prompt you to define either a row or a column as headings and set a caption.
- Headings: The editor’s heading prompts should encourage the most appropriate heading for the content you’ve already written.
There are many ways that an editor rewrite can potentially lead to a vastly improved experience. There are many ways, similarly, that an editor rewrite could result in increased problems. I’m generally in favor of rebuilding the editor, and am optimistic that it could be great. Let’s team together and try to make sure that these issues are resolved in a great way. Editor tools shape the code created in significant ways – if good options are available and promoted, the output is improved. If the tools in the editor don’t promote best practices, the output probably won’t be good.