Accessibility Checker

[isuscott]

I appreciate all of the ongoing accessibility development, https://github.com/openlibhums/janeway/issues?q=is%3Aissue%20state%3Aopen%20label%3Aa11y.

We find journal editors and authors are inexperienced when it comes to making their galley files digitally accessible. Would it be possible to integrate an accessibility checker within the Typesetting plugin or during Preproduction? Integrating something like https://editoria11y.princeton.edu/ would decrease the barrier for authors’ and editors’ involvement in producing accessible publications.

[StephDriver]

We've been looking into Editoria11y but it fits into Phase 3 which is still some time away:

• Phase 1 - janeway front of house accessibility (aka 1.9, which entered testing today)
• Phase 2 - janeway back office (coming next)
• Phase 3 - make it easier for user content to be accessible. (a year or two away).

If lots of people want it, we'll look at reprioritising - but currently this a little way off.

I'm not sure how it could assist with typesetting of articles - perhaps you could elaborate? I was thinking of it more for the static pages, e.g. journal policies. Places were users are entering html (albeit through a wysiwyg editor).

Meanwhile, may I also suggest pointing your editors and authors towards Sa11y (Editoria11y began as a fork Sa11y) which runs as a bookmarklet and so doesn't need developer support from us?

[isuscott]

I mention typesetting as a stopgap check to ensure galley files (PDF, HTML, XML) are accessible. Sa11y would be helpful for WYSIWYG editors but does not support PDFs in webpage views. We want to ensure out PDF galley files are also accessible. It could be nice having a built-in solution to check PDF accessibility without downloading and checking locally.

I had forgotten about Sa11y for web accessibility, thanks for the recommendation!