Prevent a11y Errors Through Post Locking

[troychaplin]

Making sure templates meet accessibility requirements is a great start, but not enough. We put a lot of trust and faith in content creators to ensure they are publishing accessible content, but what guidance do they have once a shiny new site is handed over to them? But what to do for users who are generally unaware of the do's and don'ts of accessibility? Working in a university environment and having to meet WCAG requirement this question goes through my head a lot during the week.

In this post I will provide an overview, complete with fully functioning code examples, of an idea on how to preventing publishing when a user is about to unknowingly publish inaccessible content and what we can do as developers to provide content creators more information around accessibility issue right there in the editor.

[bph]

Hi there @troychaplin. Thank you so much for your topic idea. I love the part where content creators can be educated about a11y issue they might cause and restrict publishing until those issues are resolved.

It would be helpful to get a better idea about the post, if you could list the a11y problems your code examples would check for and what third-party tools you might use, if at all. On the developer blog we have a rather restrictive external link policy we might bump against it, so more details would be beneficial also in that regard.

[troychaplin]

Hi @bph, this idea came from several conversations I had over 3 days at WordCamp Canada this past weekend and I was encouraged to consider contributing back via the dev blog.

People can easily cause a11y issues by publishing the heading block with an H1 or a table without a header row, and more. It is also very easy for a user to accidentally forget to add a link in a button, not only is that a usability issue, but also an a11y error.

My post would explore using registerPlugin to setup block checks that could do one of two things, lock the post from being published, or at a minimum giving them an obvious warning of an a11y issue in the editor and not being so heavy handed on locking the post.

Any links used would be to reference packages from WordPress, unless whoever would review it and approve it would agree that linking to references on why these items are a11y issues to help educate the reader, I'd be happy to add a "Additional Reading" section at the end.

Full disclosure: I just started working on a plugin to bring this functionality to anyone who wants it, but that will not be referenced in this post.

[bph]

• The example code can be referenced if it's on /wptrainingteam organization, and be an MVP of a later plugin.
• Links to https://www.w3.org/TR/WCAG21/ site should be fine

[troychaplin]

Hey @bph, I think it might be best for me to close this one out. While I'm pretty passionate about a11y and could talk about this in relation to core blocks at length, I don't feel now is the best time for me as I've started building this out as a plugin that I hope to publish in the plugin repo in the near future.

I'd be happy to write something in the future, but right now it might be a bit of a conflict while I build this as a plugin.

[bph]

Oh sorry, to read that you don't feel you have a bandwidth to write about your building process. I certainly understand. There is a world of difference between building something and writing about building something. Helping content creators to prevent a11y error is certainly a great endeavor! Thank you for still pursuing your other topic you submitted.

[bph]

Closed upon request from OP.