- take input?
- return response?
- generate content?
If so, it will need to be tested for accessibility.
When you’re analyzing a plugin, you have to look for the structure, the content, and the response conditions that this plugin uses. The structure is pretty straightforward. Once you found what it does, are all of the controls actually using a button, or an anchor to trigger? Is all of the HTML semantic and well-structured? Are they using headings? Are they organizing things in paragraphs and lists? Or is it just a bunch of GIFs? Are all of the input fields clearly labeled? If this is true, that’s a good start.
Now you have to look at the content. Are the labels for those inputs actually reasonable? Are they clear and make sense? Does the links actually have a target? Do they go somewhere? Or is it actually omitting the href attribute? Which can break, whether or not that link is even accessible to the keyboard. Do images used in this content or on this plugin have alt attributes? This is an important second step. And then you have to look at what this plugin does when you use it.
Does it announce the response that it has? Is it clearly visible what it’s done? And is it dependent on color? Is it only showing its response by coloring something red or green or yellow? Or is it actually giving you reasonable text and visual icons to represent that? With all of these things covered, then you have a good confidence that the plugin you’re looking at is actually accessible. But the first challenge with any WordPress plugin is figuring out what it’s doing and how to test it.