OJS and screen readers

[bartek]

I was wondering if there's anyone who's had experience using OJS with screen readers such as JAWS. Does the OJS system work well with accessibility tools like that or have there been challenges?

Any tips or advice would be very appreciated. Thanks

[jmacgreg]

Hi Bartek,

Although as far as I know the PKP team itself hasn't tested any of our software against screen readers, we're working to be Section 508-compliant, and to meet similar standards as set by the Canadian Government. I believe we are almost entirely Section 508-compliant, but we have a way to go viz. Canada. If you or anyone else has any comments or feedback on these points, especially on usage results using screen readers, we would be very happy to hear them.

Cheers,
James

[windhover3]

The Canadian government should have different standards than "508" as this refers to an American statute, but meeting 508 standards (or w3c) would be tremendous. I just ran the demonstration journal toc through the WAVE checker (http://wave.webaim.org/) and it only identified three clear problems which would be very easy to correct: there were missing form labels for language and the two search fields. Other than that, there were a few warnings that need to be checked out (specifically the java scripts which might confound screen readers), and it warns against having links without meaningful labels (for html and pdf) which in the context of the tables it strikes me as OK. Event handling seems OK to me for Java enabled devices. "On click" will generally work with the enter button so long as it is used with links or controls, so I think those are OK.

Using dreamweaver gives similar warnings. The main problem is the use of java for devices which aren't java enabled.

Overall, OJS strikes me as pretty accessible. There are a few minor issues for 508, but a little bit of coding can fix these. Full WCAG accessibility would require a bit more work to address the Java reliance. I may return to this issue...

[jmacgreg]

Hi windhover3,

As luck would have it, I've recently been doing a fair bit of research into web accessibility for a project that PKP is working on. The closest Canada has to the US' 508 standard is probably the CCOP's list of technical requirements that those funded by them must adhere to. We aren't funded by CCOP ourselves, and while we've taken a look at their recommendations and draw from them, we probably wouldn't pass a stringent test. A previous look at Section 508 determined that we're probably pretty close at meeting it, and that it might be worthwhile to do so in order to publicly state that our software does, but we haven't spent much time since then determining exactly where we might be slack.

I've read Section 508, the w3 guidelines, the CCOP guidelines linked to above, and other assorted pages online, and have established a set of recommendations for the project we're working on, which I have included below. PKP hasn't had a substantial discussion about the specifics of these recommendations yet, but the general early consensus is that they are a good starting point, and that we'll aim to meet them in our software. One issue that has just popped up today and is not mentioned in the following recommendations is the use of frames (OJS uses them to display the Reading Tools).

I would greatly appreciate any comments you (or other community members) might have on this matter. I will definitely check out the WAVE results you reference and see what we need to do in order to avoid those errors. Any other advice you have would be most welcome.

Cheers,
James

1. Ensure validation (HTML, CSS, JavaScript, XML). Any HTML should be valid xHTML 1.0 Transitional and pass the W3 validation test . XML should validate against its relevant DTD/schema . CSS should pass the W3 validation test . Javascript should validate .
2. Develop for 1024x768 resolution. While screen size and resolutions are ever-increasing, there are still a number of older computers and monitors out in the world. 1024x768 dpi resolution is a reasonable target for Synergies to aim for. All core navigational elements should be viewable at this resolution. (Note: JM wants to check the SFU screen reader resolution.)
3. Ensure broad browser compatibility. All Web site functions should function equally well with prevailing Web browsers including at a minimum, the most recent two major releases (current release and one release prior) and all the associated subsets, e.g. IE 7/8, Firefox 2+, Safari 3+, Chrome 3+.
4. Use HTML tables appropriately. HTML tables should not be used for layout purposes, but for tabular data only. Tables should include Table Heading (“<th>…</th>”) elements for the top row of the table, with headings describing the nature and contents of the table columns.
5. Provide textual equivalents for non-textual data. Ensure that alternate text is available for non-text objects (images; video). (Note that video concerns don’t particularly apply to Synergies, at least to the Head Node.) However, purely graphical image elements should not include alt-text so that screen readers will not needlessly pick up on them.
6. Ensure device-independent access to all form elements. All form elements must be fully accessible and usable via both keyboard and mouse.
7. Develop Javascript gracefully. All core site features and content should be available if Javascript is disabled. Any functionality provided via Javascript should adhere to the device-independent access recommendation above (for example, any modal dialogue boxes must be keyboard- and mouse-accessible).

[kintopp]

Since there are a significant number of european installations of OJS it might be worth for the PKS developers to scan the relevant european national standards as well. For Germany, this is the Barrierefreie Informationstechnik-Verordnung or BITV. The text of the law and technical requirements are also available in English: http://www.einfach-fuer-alle.de/artikel/bitv_english/ Apparently these are more or less based on the WCAG 1.0 standard.