Review process accessibility

[amyjko]

From Stefik:

1. The whole process from ACM was RIDICULOUSLY --- all caps needed --- inaccessible and just didn't need to be. This isn't anyone's fault, but it's true.

2. The authors had a lot of trouble making their PDF accessible. Part of the problem was they didn't know how, which TOCE could help with in our guidance to authors. The reviewer couldn't even read their paper. I couldn't contact them directly, so Chris basically had to play the role of harry potter owl, funneling feedback anonymously. We eventually got versions sent to the reviewer by straight up email (through chris, hence the owl), because there was no other choice.

3. The ACM's system, so far as I could tell, basically blows away accessibility information when it gives the paper to authors. It adds overlays and numbers and stuff, which I don't think many reviewers even really care about, but then kills accessibility.

Overall, I don't know "exactly" what would need to change, but reviewing, authoring, and perhaps especially issues with PDFs, could all be much more accessible. It's at least "plausible" that ditching PDF entirely for a different format might help, but also we should at least consider nudging the ACM to fix their stuff.

[amyjko]

For now, I've updated the author guide and reviewer guide with workarounds, where the EiC requests an accessible version from authors.

[amyjko]

Asked Laura Lander about this and she said she'd write another time.

[amyjko]

Here's what ScholarOne shared:

One of the focus areas for the UI/UX redesign efforts will be maximizing accessibility for visual impairments ScholarOne users aiming to achieving full accessibility (WCAG 2.0 compliance) while advancing in the accomplishment of the sustainable goals set by the United Nations and the International Publishers Association (IPA).

Right now, we are in the process of collecting data and feedback from users and organizations. I’m already under discussions with the AFB (American Foundation for the Blind) and University of London, GDI Hub (Global Disability Innovation Hub) with some innovation managers (fully blind Academic Researchers, ScholarOne and EndNote end users), of which part of their remit is to push for accessibility in scientific software.

Tentative timeline: Phase 1 Q3-Q4 2022 approx.: we will be synthetizing & analyzing all this research data mentioned above, Present & Research finding recs, final business plan adjustment and undertaking early inputs for Phase 2, 2023. Phase 2 Q2 2023 will be starting the ideation phase and we will conclude the prototyping phase (MVP) among other things.

We will be socializing and providing more information as we move forward with the entire UX/UI redesign project.

[amyjko]

Got the ear of the person leading the accessibility redesign at ScholarOne. Stefik will help develop a wish list over email.

[amyjko]

A breakdown from Stefik of core issues:

1. A massive issue is that many of the papers that ultimately get published are not accessible. Why is a deep and complicated question involving many moving parts. I have lots of thoughts on this, but they're too extensive to write in a bulleted list.
   2. In MC itself, so far as I can tell, what really needs to be done is a full accessibility audit. Every button, on every screen, needs to be checked by an expert (or a company). It's not one thing.
   3. One critical issue is that MC replaces the PDF (already a problematic format) with these visual overlays (e.g., the little numbers on the side). I haven't investigated this closely for accessibility, but that this doesn't break anything needs to be checked. I'm pretty sure it does and reviewers have reported it in the past.
   4. Part of the issue with MC is that it's hard to use in general. It's "especially" hard to use if you have a disability, but there are a series of lingering usability issues in the system. What it "really" needs is to be redesigned from the ground up with accessibility in mind from the beginning, but that's easy for me to say when I don't have to budget for it.

[amyjko]

Amy is meeting with the ScholarOne person on July 1st.

[amyjko]

Met with Soraya, product manager, kicked off UX redesign. She's a product manager at Clarivate, a consulting firm ScholarOne is working with. Has already talked to some blind European researchers and their pain points. Recently kicked off redesign project; main focus is on simplifying, modernize, reduce steps, and as part of it, to target accessibility. Not sure they'll reach 100% compliance. Looking for quick wins and then reaching compliance eventually. Also mobile experience; younger generation using scholar one. UX research lasts until the end of the year. Already analyzing data; targeting first the dashboard. They have a list of publishers who want to be involved. Want to be customer-centric. Prototyping and MVPs will come next year, vetted with customers and feedback. Early next year there will be a SE and UX conversations. Also working with American Foundation for the Blind. I relayed all of the feedback above. She's going to be a strong advocate. She has a bias toward focusing on visual impairment.

[amyjko]

I sent this list of requirements to Soraya:

• Requirement. All functionality must be WCAG 2.0 compliant. Rationale: Authors, reviewers, and editors who have impaired vision, motor disabilities, dyslexia, or temporary injuries often rely on input and output devices other than mice, keyboards, and screens. WCAG 2.0 compliance guarantees that everyone will be able to read and operate the site.
• Requirement. All functionality must be accessible via keyboard. Rationale: Authors, reviewers, and editors who have impaired vision, motor disabilities, dyslexia, or temporary injuries often cannot use a mouse to interact with the website. Full keyboard access is essential to using the platform.
• Requirement. Any PDF metadata required for screen reading must be preserved when a PDF is transformed in any way. Rationale: This ensures that authors, reviewers, and editors who rely on screen readers to read PDF content can still read the documents after Manuscript Central modifies the document. The current implementation strips this information, requiring anyone who relies on a screen reader to someone obtain a clean accessible PDF from the authors to participate in review.
• Requirement. Any content added to PDFs must not interfere with screen readability of documents. Rationale: many of the annotations currently added by Manuscript Central, such as line numbers and watermarks, make it impossible to read the document without the constant interruption of line number reading.

[amyjko]

Summaries of additional thoughts from the board:

• Consider strongly whether interactivity is allowed in HTML. (ACM isn't set up for it, so probably not in archiving).
• Consider whether printing matters. (ACM has already solved this with their XML/HTML/PDF pipeline).
• Think about what tools we might reuse. ArXiv, for example, is working to implement an HTML pipeline.

[amyjko]

Spoke again to Soraya at ScholarOne:

• Now imperative at Clarivate, acquired Proquest, which is very much not accessible
• New Clarivate accessibility council, and ScholarOne is a high priority, especially via inclusive publishing laws
• Contracting a third party vendor to work on accessibility training
• Aiming to have vpad requirements done by end of calendar year, but lots of pages to review
• Auditing ScholarOne as it is now, but already doing a redesign with Angular, so they'll shift to that
• Looking for level AA accessibility, but may only reach A at first
• Invited me to join their advisory committee to track progress

[amyjko]

No updates from Soraya on this; she invited me to their advisory committee and I agreed, but there's been no communication.

[amyjko]

Still no updates on this; it seems to have just disappeared (or maybe just happened). ScholarOne certainly hasn't been updated yet.