Refers to issues around PKP’s compliance with WCAG 2.0 and other accessibility issues.
Here’s a question… This call for comment just went out from the WAI group of the W3C. Is it on PKP’s radar?
Digital Publishing WAI-ARIA: Digital Publishing WAI-ARIA Module 1.0
It has to do with digital publishing and accessiblities. Seems most
applicable to Open Monograph Press. A reason it’s important for Ontario
university libraries hosting publishing is that we have a provincial
law that requires the public and private sectors to comply with WCAG 2.0
Level AA, which ARIA help.
Would PKP community consider responding to the to the W3C call?
1 Like
Hi @mark,
Thanks for the heads-up – I’ve passed it along to our UI/UX subgroup for consideration.
Regards,
Alec Smecher
Public Knowledge Project Team
Curious… has the PKP suite gone through WCAG accessibility testing (not just online WCAG validators but a more careful human assessment)?
Hi @mark,
Nothing formal, but see e.g. this report:
http://scholarworks.csun.edu/handle/10211.3/134103
Regards,
Alec Smecher
Public Knowledge Project Team
I’ve read this article and I’m wondering if OJS 3.0 will address some of the accessibility issues the authors address? We’ve had an editor that uses a screenreader and OJS has been unusable for them.
Hi @reneemc,
Do you have some specific feedback on the user’s experience? Our sense of OJS’s accessibility comes second-hand through reports like the above and a general knowledge of the WCAG standards. Based on those I had thought that OJS was not fully compliant but generally usable. I’d love to get some firsthand feedback.
OJS 3.0 will be quite different from OJS 2.x but hasn’t gone through a formal accessibility test. It will hopefully provide a better platform for accessibility improvements but those haven’t been done yet. Hopefully we’ll be able to do some specific testing between now (beta level) and the final release of OJS 3.0.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks. I’ll ask for some feedback and post back here when I have it.
Hi Alec,
I’ve spoken with the editor and he reported that his initial problem was that the captcha was not accessible (we’ve asked our hosting institution to evaluate that problem as I’m not sure where that lies.)
Once he was able to enter OJS with the help of a sighted person his screen reader read OJS from top to bottom (which is the form order problem I believe the article addresses.) He feels that this reading order problem renders OJS unusable for people using screenreaders and was quite outraged that he repeatedly required the assistance of a sighted person to use the system. Eventually he and his co-editor abandoned OJS in favor of a makeshift system (which obviously caused problems in the journal’s workflow.)
Part of the reason we are re-evaluating OJS as our system is because of this accessibility problem.
Thanks,
Renee
Hi @reneemc,
There are a few CAPTCHA options, one of them homebrew (and not accessible) and the other Google’s standard ReCAPTCHA. The latter is recommended and can be set up in the config.inc.php configuration file.
I suspect there are specific interactions the user was struggling with and would really appreciate anything we can get that would identify those. If not – if the overall page layout was the problem – that would be really valuable feedback too. If the user would be willing, I’d love to speak with them directly.
Thanks,
Alec Smecher
Public Knowledge Project Team
Hi @reneemc,
I’m working on the UI/UX for OJS 3.0b and I’d love to talk to your editor if they’d be willing to help us identify some pain points for people who use screen readers. 3.0b will be much better in many ways, with better heading structures for quick navigation, better keyboard navigation, sane document flow and use of screen-reader text in at least some of the places where it’s needed.
However, I suspect we still have many critical problems that will make it difficult for those with screen readers, particularly when it comes to how we load content in without page refreshes. It’d be really useful to have someone who relies on screen readers to give us specific feedback on what is and isn’t usable.
I’m really interested in pushing accessibility with this next version, and we’re already doing some things that a lot of websites aren’t. But figuring out the black holes that remain would be really helpful at this stage in the process.
1 Like
Good morning! One of our OJS journals has been asked to provide a Voluntary Product Accessibility Template (VPAT) form to a new institutional subscriber. Does anyone have a VPAT form that they’ve created for OJS?
Thanks,
Marianne
Hi @mreedks,
We’re mostly a Canadian group and not familiar with that process – but perhaps one of our US-based partners or users have some experience.
Regards,
Alec Smecher
Public Knowledge Project Team
We are look at using OJS and our prospective client requires a 508 assessment / Voluntary Product Accessibility Template (VPAT) to be filled out. I was wondering if the status has changed regarding anyone that has recently done a 508 assessment/VPAT for OJS v3.0 that they could share?
thanks.
Amy
Hi @aesau,
I’m not aware of a formal assessment, though we did recently get some informal feedback from a screen-reader user that OJS 3.x behaved reasonably well. We’re definitely open to feedback/contributions/assessments around this.
Regards,
Alec Smecher
Public Knowledge Project Team
This thread seems to have quieted down… if the conversation hasn’t moved elsewhere, let me suggest that preparing a VPAT could really help organizations that are considering adopting OJS. Templates are available here: VPAT - Information Technology Industry Council. I’d use the WCAG version, since that is emerging as a de facto international standard for web accessibility.
To the idea that this doesn’t apply in Canada, while there may be no requirement that s/w providers prepare a VPAT, Canada does certainly have some accessibility laws on the books! It’s a global issue.
Thanks for considering.
I think the biggest blocker to this happening is just having a volunteer to sit down and walk through the document(s). Perhaps this might be a good project for a future development sprint?
Thanks for the reply. I’m trying to round up the language that Cornell requires if we enter into a contract or MOU with a provider (as we might if we were to pursue journal hosting with PKP, for example), as well as a suitable substitute from our web accessibility coordinator were we to host our own instance of OJS (no contract required).
A colleague tells me they’ve seen providers/vendors focus on section 1194.22, some times exclusively, but it seems like other sections could also apply (with the exception of 1194.23, 1194.25, 1194.26).
Hi all,
PKP|PS is in the process of preparing a VPAT for our services and for OJS specifically, as we are indeed seeing an increase in clients requesting it. Once completed, it’ll be available from the main PKP website (and we’ll announce it via the PKP blog). We’ll also ideally include a reassessment as part of our software release plan. Gail (or others), if you are interested in this from a (prospective or current) client to development partner perspective, you can contact me here or at jbm9@sfu.ca. And thanks for the heads up re: using the WCAG version!
Cheers,
James
I am also interested in OJS’s implementation of accessible features (WCAG 3.0 standards), and not just the use of a screen reader? Are there options for changing background/foreground colours for better visibility, enlarging text, etc. within the existing themes? What screen reading programs do you recommend? Close captioning of videos? Thank-you in advance.