I have to admit: I didn't know what an accessibility statement was until I read Ethan's post 🙋‍♂️ That's not great. Now I do, so hopefully, in the near future, I'll get around to adding one here. That will need a little bit more thoughtfulness than I can currently give, though, so for now I just want to record the key points:

First and foremost, an accessibility statement’s meant to help the reader. Put another way, it’s a document that helps them better understand the accessibility features of the website they’re using.

Ethan specifically mentions elements like the focus styles he's designed and how he's tested his colour palette.

For someone visiting my site—whether it’s the first time or the fiftieth—my accessibility statement hopefully provides them with the information they need to better navigate my site.

He also makes a point of having a "not great" section of known accessibility issues or areas which are planned for improvement. That makes the statement a living document, which feels right. Inclusion requirements will shift with technological change; accessibility is never "finished". I'm a fan of using GitHub issues, a la Eric Bailey, as a way to allow users to flag these as well.

The Known Issues section is an attempt tried to acknowledge that my site has plenty of flaws—not unlike myself—and that I’m working to fix them.

Ethan's post also contains numerous links to other worthy examples (like Eric's) that are all well worth visiting and considering. I'll definitely be coming back to this in the – hopefully near – future.